SimpleQuiz › Part VI › Form(atting)

Let’s talk forms. A lot my web design headaches are caused while formatting form items. This quiz question comes to us from MikeyC:

Q: When marking up forms, which is more semantically correct when separating form items?

  1. <form>
    <p><label for="name">Name:</label>
    <input type="text" id="name" /></p>
  2. <form>
    <label for="name">Name:</label>
    <input type="text" id="name" />
  3. <form>
    <label for="name">Name:</label>
    <input type="text" id="name" /><br /><br />

See all previous quiz questions and wrap-ups.


  1. Mike says:

    Hmm… toughest one yet is for sure ;)
    I’m going to have to go with A.
    Because you can address the Name field by its id, there really isn’t a need to clog up the code more by wrapping it in a div.
    The third one isn’t so bad, however the non-semantic line breaks kinda kill the idea of uber-accessibility with the label tag.
    The first one does a nice job of splitting up the Name field from (the eventual) rest of the fields, and by using the paragraph tag, it keeps the separation in line with the rest of the text on a semantically-pure page, namely, by using <p> tags like normal paragraphs would use.

  2. Keith says:

    Good question. Another sticky one, ok, here goes:
    I think if you remove the break tags from answer C you have the best solution. They’re presentational effect could be handled elsewhere. The break tags are not needed here.
    As far as A goes, I don’t really consider a form label and text field a paragraph so that’s out. Again the p tag isn’t really needed anyway.
    B is pretty good, and would work, but I question the need for a div tag there. For presentational purposes you could just style the form, the label and/or the input. Once again, the div tag doesn’t seem to be needed.

  3. It’s a toss up between A and B for me. I generally go with B, because although paragraphs have more implied meaning than divs a field and its label aren’t “a paragraph of text”. When an HTML page incorporates forms it starts to move away from being a “structural document” and towards being a “logical interface” instead – once I start working with forms I switch my focus from semantics to accessibility and usability. Since these share many of the same requriements as semantics (use proper header tags etc) I don’t feel too guilty about using divs instead of paragraphs.

  4. MikeyC says:

    “I don’t really consider a form label and text field a paragraph so that’s out…B is pretty good, and would work, but I question the need for a div tag there.”
    Keith, this is *exactly* what I’m talking about. It doesn’t seem semantically correct to mark-it-up as a paragraph, while wrapping it in a DIV tag pair feels unnecessary…but according to the validator:
    “document type does not allow element “label” here; missing one of “p”, “h1″, “h2″, “h3″, “h4″, “h5″, “h6″, “div”, “pre”, “address”, “fieldset”, “ins”, “del” start-tag”

  5. Matt says:

    Well C is illegal XHTML 1.1, so out of the running for me. Between A and B, A is probably the better choice. In my mind I could make a case for the DIV, but I try to avoid ambiguous elements wherever possible. You could do some nice formatting with the label element through CSS as well.

  6. MikeyC says:

    “I think if you remove the break tags from answer C you have the best solution.”
    Except C doesn’t actually validate ;)

  7. Brian S says:

    I like A with a couple of changes…remove the p tags and add the id attribute.

    <form id="nameform">
    <label for="name">Name:</label>
    <input type="text" id="name" />

    The p tags aren’t encapsulating a paragraph, so it doesn’t seem to be very semantically correct. If they are there simply for the purpose of applying css rules to the elements, they serve no more purpose than a div tag would.
    Of course the id attribute is needed to make the form valid and for using javascript to perform things like validation functions, but it also is needed so you can apply styles specifically to that form.

  8. Shaun Inman says:

    Why not nest the input within the label tag? It is valid and while it may not be entirely semantically correct, it does provides a semi-semantic container element with which to apply style and divvy up the areas of the form. On a larger form thing of k you’ll save without all those superfluous “for” attributes and block level elements.
    So my vote rolls in for D:
    <label>Name: <input type=”text” id=”name” /></label>

  9. Dave S. says:

    I was going to go and suggest using <fieldset> in there somewhere, but I took a look at the spec and it seems even that still requires a surrounding block-level tag. So.
    b) it is. <p> doesn’t make much sense in the context of a form; I’d assume it’s better to go with an empty element rather than go with a non-sensical one.

  10. Dave S. says:

    Er. Read the comments before commenting next time, Dave S.
    “document type does not allow element “label” here; missing one of “p”, “h1″… “fieldset”, “ins” …”
    So what does that mean then? Drop the <div> in favour of a <fieldset>?

  11. Paul G says:

    Not to completely derail the discussion, but I think a better question would be: Is it semantically okay to use a table to do basic layout for a multi-part form? I find this to be the last area that I have held out on converting my code to pure CSS for positioning, mainly because it’s generally a lot of code (not that a table isn’t a lot of code) and the fact that the form is almost so ugly as to be unusable when CSS is turned off.
    I think you could argue that a form could be considered tablular data, you have two columns: “Label” and “Value”, and each row is a pair of related elements, a label and an input. Also, it ensures that labels and inputs maintain a logical visual order and layout when CSS is off. That’s my justification, anyway : ). What do you guys think?
    Oh, and for the record, for such a simple form, I’d go with something like what Brian S proposed. Option A is a bit overkill with the <p>, B is moreso with the <div>, and I generally try to avoid <br> tags altogether if I can, so C is out as well. Brian’s method is by far the cleanest and most accessible.

  12. Pete says:

    If I could propose a “D” option…
    This idea comes from the HTML4 specification for the label tag, that allows for the form control to be inside the label tag. By combining this with a fieldset and legend we can eliminate the validation problem MikeC mentioned and have a valid and semantically correct XHTML form.

    <form action="#" method="post" ID=Form1>
    <fieldset><legend>My Fields</legend>
    First Name
    <input type="text" name="firstname" ID=Text1/>
    Last Name
    <input type="text" name="lastname" ID=Text2/>
    <input type="submit" name="submit" ID=Submit1/></fieldset>

    The added bonus is that with CSS you make the labels blocks, position the controls and produce tableless forms.

  13. Pete says:

    Ooops Shaun Inman got in with the D option before I finished writing my comment.
    Check out my text page using the fieldset option which validates as XHTML 1.1.

  14. MikeyC says:

    Fieldset seems to be rather presentational. Does it actually have semantic meaning, or is it simply a way of drawing a border around a form?
    Paul G: “the fact that the form is almost so ugly as to be unusable when CSS is turned off”
    Perhaps a reason why <br> tags may not be completely evil, at least in terms of useability–proper semantics should not trump useability.
    Paul G: “I think you could argue that a form could be considered tablular data”
    I think you could argue that practically anything is tabular data, quite frankly ;)

  15. “So what does that mean then? Drop the <div> in favour of a <fieldset>?”
    I’d use B, replacing <div> with <fieldset> (and making use of <legend>, of course), which I guess turns out to be the same as Pete’s D option.
    So, I choose D, as it turns out.

  16. “Fieldset seems to be rather presentational. Does it actually have semantic meaning, or is it simply a way of drawing a border around a form?”
    MikeyC: The purpose of <fieldset> is to group related form controls, making a form more manageable and, theoretically at least, more accessible to assistive devices like screenreaders.

  17. Dan says:

    I like Shaun Inman and Pete’s example. Although, I seem to remember having mixed results when trying to style <label> elements. For instance, I recall trying to floating them to mimic Mark Newhouse’s tableless form layout (replacing <span class="label"> with <label>). It didn’t work out exactly.
    I suppose I should work up some sort of live example. It’s getting late… In general though, has anyone else run into problems with CSS and <label>?

  18. talon says:

    I last used option A. While I agree that labels and associated field values are not necessarily a paragraph, I couldn’t really think of anything more appropriate. I do believe, however, that there should be some separation of fields from each other (unless they are specifically grouped, which would best be done using a fieldset).
    The case for A and B can both be argued equally well, and I think that either one is semantically appropriate. The key is that they both contain labels to give meaning to the form structure. Option C, however – despite not validating, which is beside the point – could easily be used as an equivalent of B, where the “meaningless” divider is between elements, rather than around them.
    In trying to improve on these options I considered fieldset, but there is such a thing as fieldset overload. Write a non-trivial form and you will find that a method of breaking up form elements as above is still necessary. Finally, as someone commented on a previous quiz, it’s possible to see web pages as lists of lists. While it might not be good to make your entire page a horrible nested list structure, isn’t a list of form fields just a list after all?

  19. MikeyC says:

    talon: “but there is such a thing as fieldset overload”
    Yeah, I think you’re right there.
    Would it be inappropriate to use fieldset, for the sake of validation, when you only have a single field?
    Fieldsets may appear sexy and semantic but if its merely being used for validation is it really any better than a div or a couple of superfluous <br>s?

  20. Jason Grigsby says:

    MikeyC: “Would it be inappropriate to use fieldset, for the sake of validation, when you only have a single field? Fieldsets may appear sexy and semantic but if its merely being used for validation is it really any better than a div or a couple of superfluous
    I believe fieldsets are a much more attractive option than working with the extra <br /> tags. With regards to <div>, it may not provide much more meaning depending on how it is implemented. However, if used in conjunction with legend, a lot of semantic meaning can be added.
    According to the W3C, grouping fields makes documents more accessible. I can’t vouch for that, but the fact that fieldset may make pages more accessible and can have semantic meaning if combined with legend is good enough reason for me to favor it instead of div.
    Regarding the use of fieldset for a single field, it is entirely appropriate. In fact, fieldset is often used for scenarios like:
    <legend>Choose your favorite color:</legend>
    <label for=”blue”>Blue</label><input type=”radio” name=”blue” value=”blue” />
    <label for=”red”>Red</label><input type=”radio” name=”red” value=’red” />
    Regarding the comments about CSS formatting of forms using fieldset, form and input in an attempt to replace table-based forms, I’ve been spending a bit of time on this lately. I still don’t have it working to my satisfaction, but I haven’t yet tried to surround the input with the label tag. Pixy has a great example page of css-formatting using <br /> tags. I think something similar, but using a surrounding label tag would be possible.

  21. TOOLman says:

    I’d use a <fieldset> and nest the input field within the <label>.
    Of these three choices, I’d say B. I don’t understand why some of you are against the <div> because it’s “unnecessary”, while accepting an inaccurate <p> tag instead. This is not a paragraph.
    Yes, excessive use of non-semantic <div>s is bad, but don’t let that lead to some kind of divphobia. Use the <div> when you need a block-level element and there’s no other semantically appropriate element available. Add an id or a class if you want to provide some pseudo-semantics.
    My problem is this: I want to nest the <input> inside the <label> but I want the label to appear above the input field. Is there any way to do that without resorting to a <br />?

  22. ‘When an HTML page incorporates forms it starts to move away from being a “structural document” and towards being a “logical interface” instead’
    I agree, I’m glad XForms is almost ready. Personally I use the p element, since it makes the styling easier. I also use the fieldset element for grouping a set of p elements sometimes.

  23. Raena says:

    ‘My problem is this: I want to nest the input inside the label but I want the label to appear above the input field. Is there any way to do that without resorting to a br?’
    You should just be able to display the input and the label as block elements, using CSS. Do the same with that input, and whack on a bottom margin to space the next field away without the use of a

    form label
    display: block;
    form label input
    display: block;
    margin-bottom: 1em;

    In Safari and Firebird it works exactly as expected.

  24. Raena says:

    hm. I meant to say ‘…to space the next field away without the use of a br.’ Oops.
    I don’t have a Windows box available right now to see how IE/Win copes, but I’d love to know how it goes. IE5/Mac is happy with it.

  25. plasticlab says:

    I have to with Pete on this one: D is the way to go!

  26. ok, it’s already been mentioned, but: none of them are “perfect”. go with
    and use css if you need to have more than one label/input pair on separate lines…

  27. Kris says:

    C doesn’t count for me. It is not valid Strict.
    The deal is between A and B. While I still markup my form sections as in answer A, I am currently moving towards B in my beliefs; the question is, is it a paragraph? If not, then the P element is unappropriate here.
    I too have trouble cluttering up my markup with DIVs, but avoiding them should not be solved by adding markup that reflects the content even less.

  28. Andrew B says:

    I always use A – partly because I don’t see a sensible alternative that actually comes close to being correct (sorry FIELDSET in my mind is not appropiate in this case as other people have mentioned) but partly because in A there is a structural link between the label text and the text box.
    The label text could easily be classed as being a paragraph, and the text box relates to the label.
    Ergo a DIV would not be appropiate.
    It’s also worth thinking of the context of the form in this case. Is it standalone or part of a text based document – the answer people come up with could depend on that context. If a form standsalone on it’s page, maybe B is more appropiate. But if it sits amidst a lot of text, could it not be classed as a paragraph? In my mind, quite easily.

  29. Seb says:

    My usual method for forms is to use a definition list:
    <dt><label for=”name”>Name:</label></dt>
    <dd><input type=”text” id=”name” /></dd>
    It’s then easy to use CSS to format the various parts, lining up labels with input boxes, etc.
    And I believe it conforms to the semantic rules for a definition list – the defined term is the field label, and the definition data is the field to be entered…

  30. Paul G says:

    Oh, now that’s an intriguing idea, Seb. It doesn’t look the best (when compared with what most people expect a form to look like) with CSS turned off, but at least it maintains a logical visual order instead of turning into one long inline string of labels and inputs.
    However, I think that I will continue to use tables to lay out forms, it still seems (to me) to be the best way to convey visual relationship regardless of whether CSS is on or off.

  31. Jai says:

    I’m going with B, definitly. A form element, such “name” is not a paragraph, no matter how you slice it. It makes more sense semantically that it be considered a Div(ision). If the form had more elements in it, the double <BR /> would make sense, because all elements in the form ar part of the same div(ision). I may even go so far as to say %lt;div id=”this_form”> would be appropriate, identifying the whole div(ision) as one containing the whole form.

  32. Andrew B says:

    I think you might be being swayed a bit by the briefness of the sample text supplied.
    The label might not always be one letter long. It might be “Explain what you found to be disagreable” which of course is more paragraph like

  33. Jai says:

    Re: Andrew
    The label a label, not a paragraph, even if it’s written in paragraph form. Otherwise, why would it be under the label tag?

  34. Luke Redpath says:

    I agree that none of the three presented options are acceptable, and that fieldset should be used. I would also avoid using a definition list because in terms of semantics, a list to me implies a list of data or information, not a list of controls.
    I would opt for either:

    <legend>Personal Details</legend>
    <label>First Name:</label>
    <input type="text" />
    <input type="text" />


    <legend>Personal Details</legend>
    <label>First Name: <input type="text" /></label>
    <label>Surname: <input type="text" /></label>

    depending on whether you want your label/input on the same line or not.

  35. Nick says:

    based on the wording of the question and the choices given, i’d have to say b.
    but as is with most of these questions, the discussion that has been generated has provided some thought provoking answers.

  36. brianp says:

    i typically end up with tables for forms for a few reasons, the main one being that i think its tabular information. if i’m laying out the same info on a piece of paper i’ll likely draw a grid in. stylistic, maybe, but tables and forms go together like rice and soy sauce.

  37. I have to agree with Andrew B. I think A is the only way to go here. You could argue either way about the semantics of using form elements within paragraphs, but B and D do not look good unstyled, and C does not validate. Therefore A seems to be the best option.
    I would be tempted to still use tables for forms, as it’s easy to organize the elements and looks good with or without styles. I haven’t done too many forms using strictly CSS yet, but I can’t think of a quick way off the top of my head to have the labels right-aligned on the same row as the text input without resorting to tables. Ideas?

  38. Luke Redpath says:

    Why not:

    <label><input type="text" /> First Name</label>

    All though I’m not sure why you would want to right-align them.

  39. No, what I was getting at was:

    <tr><td align="right"><label>First Name: </label></td><td>&ltinput type="text"></td></tr>

    Is there a simple way to duplicate that using CSS?

  40. Dan says:

    Mike – There is. Altough, it’s not so simple and requires the use of extra span tags. I’m actually using it on my contact page.
    Getting rid of the spans and replacing with label unfortunately didn’t work out as well.

  41. Paul G says:

    Dan, I had forgotten that article, but as soon as I looked at the code again, I remembered my first thought: “That’s nice, but it’s still a table, just with <div> instead of <tr> and <span> instead of <td>.”
    Why wrangle all that code and css to simulate the effect of a set of tags that already exist? You gain nothing in semantics (<div class="row"> doesn’t convey any more information than <tr>), and you lose a lot of your layout when CSS is off. I’m all for validity and proper semantics, but sometimes you have to forego your idealistic purity (I’ve found that mine is often misdirected anyway…) and just use what works ;)

  42. Dan says:

    Paul G. – Agreed. It’s more of a proof of concept, than an ideal solution.
    Certainly in a complex form, with multiple controls, fields, etc. it’s very difficult to structure it without using a table and still have it be usable for all audiences.

  43. Shaun Inman says:

    Mike (& Dan): How about this?

  44. Ed Sharrer says:

    I’ve used A extensively, and found it to be a decent solution. Form fiels aren’t paragraphs, but marking them up with <p>s gives you the best results styled and unstyled.
    Doug, I’ve applied formatting to labels with decent results. There is a bit of odd behavior in some older standards-compliant browsers (NN6 Mac especially), but the latest releases work fine.

  45. Loic M says:

    I used to create forms with the ALA technique but since i read this quizz and comments of people, i thought on formatting forms.
    Here they are my tests, what do you think about that ?

  46. Jason Grigsby says:

    Loic M: I like your tests. That looks promising.
    I pointed to this website earlier. It is still a good alternative the ALA article.

  47. Loic M says:

    thanks Jason.
    i manage to improve them for various browsers (mozilla1.4/win, IE6, Netscape7, firebird0.6, still have a pb with opera7)
    How do they work with a mac please ?
    something else to tell ?

  48. Hi all, OT, but is there an email discsussion group flaoting around dealing directly with semantics and the like? I think it’s one of the most important topics out there right now (since we now all have a decent grip on CSS). I’m happy to set one up if one doesn’t exist right now.

  49. Dan & Shaun, thanks for the demos! Seems simple enough. However, as Paul G pointed out, using a table seems to be a better solution for some forms.

  50. aleck says:

    I think that question is rather inappropriate.
    Forms with just one element are quite rare, i.e. often you have several elements.
    And that’s when fieldset comes to play: to group associated elements.
    In such case, this is the way to go:

    Personally, I often use input outside of label, and separate with BRs. Until I come up with good CSS styling for above markup…

  51. Valera Selev says:

    I guess this is the most correct variant:

    <label for="name">Name:</label><input id="name" type="text"><br>
    <label for="mail">E-mail:</label><input id="mail" type="text"><br>
    <label for="subs">Subscribe:</label><input id="subs" type="checkbox"><br>

  52. feha says:

    Hi i like this discussion.
    Is there any way to get unique id’s if form name-eaxmple:
    id=”files[]” won’t validate in XHTML …
    Same is with checkbox list or radiolist etc …
    I use Erics method for styling forms.
    Buts some of my forms are still tables.

  53. Ken says:

    How about this.
    I am having trouble posting the code in my comment, so here is a link to the form test.
    If anyone could explain how they are getting code to show up in comments, that would be great to!
    Nesting the LABEL tags inside of a H(eader) tag creates an automatic line break. This causes the input field to drop down under its respective label even when CSS is turned off. So it degrades well and remains quite readable. I am not sure, but the use of an H tag also seems to make some semantic sense here.
    In addition,
    The use of the FOR attribute creates the necessary semantic relationship between the label and its respective input field. From what I understand, this makes nesting the INPUT field inside of the LABEL tags unnecessary.
    Does anyone have any thoughts on this?