If you’re looking for XHTML 1.1 compatibility, then only minor changes are needed to your default Movable Type templates. I had the most difficulty with the comments form on the individual entry archive.
The first thing that got me was the form itself. The form tags need to be outside of your block – for instance, form, then div. Close your /div, then close the /form. If you don’t do this, then the validator won’t read your block correctly – it will throw all sorts of errors, mostly having to do with disallowed elements.
It will also make you think that “name” isn’t a valid attribute. Indeed, you can see in this reference that name is a valid attribute for the input element. But it has to be inside that block, so get the container tags correct!
The second thing that got me was that name is not a valid attribute for the form element. Change that to “id”. Important tip: do not change any other elements from name to id – just leave ’em alone or you’ll break something else.
The final piece of the puzzle was the Javascript that handles the setting of the cookie. Because name is not a valid attribute for the form element, the default Javascript code won’t work, since it references the form by it’s name. Instead, you need to go after the elements in the form by their id instead. The id attribute must be unique in the document, so this should be fine.
I found a piece of code from the Plat that did the job. Here it is in case you’re in need.
<script type=”text/javascript”>
<!–
document.getElementById(’email’).value = getCookie(“mtcmtmail”);
document.getElementById(‘author’).value = getCookie(“mtcmtauth”);
document.getElementById(‘url’).value = getCookie(“mtcmthome”);
if (getCookie(“mtcmtauth”)) {
document.getElementById(‘remember’).checked = true;
} else {
document.getElementById(‘forget’).checked = true;
}
//–>
</script>
One note about this code that could trip you up. The “remember” function is looking for an element with an id of “remember”. This is a problem because the default id of that element is “bakecookie”. I changed that value in the Javascript to “bakecookie” and it seems to work fine.
This reminds me of another potential issue – if you change (or remove) the name value on the radio buttons, they might not work as a team. If the radio buttons do not share the same “name”, they won’t work in conjunction with one another, so you can’t select the “yes” value, which pretty much defeats the purpose of having the whole “remember me” function.
If your form suddenly stops responding on one of the radio buttons, this is the place to check – make sure that all of your “joined” buttons share the same name attribute. They should have different id attributes, but the name should be the same!
So, just change the id of the “remember” function in the code to match the id of the button, and you should be set. Recompile your templates and you should have a functional comments form that validates as XHTML 1.1.
Comments
40 responses to “Forms in XHTML 1.1”
Thanks jayseae,
If I try that it still won’t validate:
Line 65, column 32: there is no attribute “name”
<form action=”” id=”form1″ name=”form1″>
Try using id and name, not just one or the other.
Hi, I’ve tried changing name to id, but I can’t get my XHTML 1.1 page to work when I change it. I’m sure it’s a syntax issue – any help would be appreciated 🙂
<script type=”text/javascript” >
<!– hide
function straightto(x){
if (document.form1.jumpmenu.value != “null”) {
document.location.href = x
}
}
// end hide –>
</script>
<form action=”” name=”form1″>
<p style=”text-align: center;”>
<select name=”jumpmenu” onchange=”straightto(document.form1.jumpmenu.options[document.form1.jumpmenu.options.selectedIndex].value)”>
<option value=”index.htm”>Go straight to…</option>
<option value=”help/help.htm”>Help Centre</option>
<option value=”faqs.htm”>FAQs</option>
<option value=”downloads.htm”>Downloads</option>
<option value=”linktext.htm”>Link to us</option>
<option value=”about.html”>About Us</option>
</select>
</p>
</form>
Chris, that was an excellent explanation. Thanks so much for posting it. One other tag that gets me pretty much constantly is the <img> tag. For whatever reason, I always forget to close it. So if you’re using this tag in your documents, make sure to use:
<img /> and not <img>
Or you’ll cause fits for those browsers trying to process well-formed data!
jeff-
You say you’re confused about the placement (or relation to each other) of the form and div tags and what was changed/why.
In XML all documents must be ‘well formed’. If not the browser will typically throw an error, and it will obviously not be valid. My understanding of the term ‘well formed’ means that all tags which have opened inside of TAG, must close before TAG is allowed to close. All tags which did not open inside of TAG, are not allowed to close inside of TAG.
Here is what you can NOT do:
<div>
<form>
</div>
</form>
As you can see, the div opened outside of the form tag, and then closed INSIDE it, which is a no-no. If you opened outside, it must close outside, likewise for if it opened inside, it must close inside. There may NOT be a single instance of the above rule being broken in a document between ANY tags.
So when he said he had to change his document, he changed it to this:
<div>
<form>
</form>
</div>
The div opens and closes OUTSIDE of the form, likewise the form opens and closes INSIDE the div. This is ok too:
<div>
<form>
<div><p></p></div>
</form>
</div>
Another way to explain it would be to say all tags must close in the exact opposite order that they opened. if there was a tag that opened after it/inside of it, then that tag must close before it is allowed to close.
The only exception to this rule is for elements which are allowed a shorthand version of thier tags, for example:
<br></br> may be written as <br />
<input></input> may be written as as <input />
This is true because these elements effectively ‘close’ themselves upon opening(or never even open depending on how you look at it).
<div>
<span>
<p><br /></p>
</span>
<div>
<p><a></a></p>
</div>
</div>
That was well formed, but the next one….
<div>
<span>
<p><br /></p>
<div>
</span>
<p><a></a></p>
</div>
</div>
The span will cause an error because it has closed, and has an OPEN div tag inside of it. Just remember, no tag can close until all other tags inside of it have closed first.
Just write the open and close tags for each element at the same time, you’ll never have a problem. ex:
<div> </div>
Then:
<div>
<span></span>
</div>
And so on….
It makes perfect sense if think you about it, we are creating a 2D document, not 3D. With only 2 dimensions (L x W), it is impossible to make a tag go through another tag.
Imagine many peices of cardboard on a flat table, different sizes, but all rectangular. Each repesents an element. To stack one on top of another or ‘lay’ it partially on top of another (like the planks on a wooden rooftop), would be adding a 3rd dimension-we can’t do that.
You can put one inside another, but anything else would require cutting one of the sides, which breaks the box and thus breaks the markup language.
Note that layers are not a 3rd dimension, they are a stacking order or things which are infinitely flat. Until we able to set a "depth" attribute, we’re 2D and z-index is again, a stacking order, which would actually be of little use if we could specify depth.
I hope that gives everyone a good understanding of it. If the 2D/3D part confused you, ignore it.
Jeff, that’s exactly what I did – edited Context.pm to remove the references to the target=_blank. Hopefully 6A will update the code in the next release so that such steps aren’t necessary!
Re: Comment author links: Do you mean that you edited Context.pm? That’s what I did (I took out two references to -target=>’_blank’, one in a subroutine for creating author’s comments, and one for creating visitor’s comments). I wonder if you did something different.
Thanks for the note Jeff – those Trackbacks will get you! I simply updated the trackback itself to use entities instead of actual characters that were failing. Then I found I had another problem – apparently Movable Type spits out invalid XHTML when it writes comment author links. Don’t know how I had missed that. I simply updated the code to not add the target attribute, and now everything looks okay. Thanks again!
Thanks! (I think…I’ve not actually implemented your suggestions yet, but the editor is open and waiting for me to start as soon as I click the submit button on this comment.)
If you’re open to suggestions, may I contribute that it might be helpful to further explain what you mean by:
“The first thing that got me was the form itself. The form tags need to be outside of your block – for instance, form, then div. Close your /div, then close the /form.”
The only difference that I notice between the original MT code and yours is that you have ALL of your form elements inside the inner div block, whereas the original code only has some elements inside, while some of its elements are outside of the div block; so MT closed their /div, then later on – as you suggested – they close their /form. So, at this point, I’m mostly just confused.
Also, this page does not validate XHTML 1.1 – instead it throws the error, “Sorry, I am unable to validate this document because on line 317 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.” The problem, of course, is the trackback data below. Do you know how to prevent characters which would fail to validate from showing up in posts?
Well, it depends on what you’re asking, and that’s not clear from the comment. For a form, you’ll need an action and a method. You should probably have an ID, but I don’t know off the top of my head if it’s required for XHTML or not. Mailto, on the other hand, is contained in the href attribute of an anchor (a) tag.
You may have a form-to-mail feature, and in that case the form will have an action that points to the script that does the conversion, and the method will indicate what sort of processing to use. Mailto will likely never enter into the equation.