Adding <p> or <li> semantics to forms
What is the most standard way of adding semantics to forms as I am torn between using cleaner looking <p>'s with both cleaner HTML and output without CSS or using <li>'s after all it is list (or is it?). Are there disadvantage or advantages to either? Anything in the HTML5 specification about what to use to aid next generation coders?
eg:
| Code: |
| <form id="contact-form" action="script.php" method="post">
<fieldset> <legend>Contact Us:</legend> <p> <label for="name">Name:</label> <input type="text" name="name" id="name" value="" /> </p> <p> <label for="email">Email:</label> <input type="text" name="email" id="email" value="" /> </p> <p> <label for="email">Comments:</label> <textarea name="comments" id="comments" cols="25" rows="3"></textarea> </p> <p> <label for="mailing-list">Would you like to sign up for our mailing list?</label> <input type="checkbox" checked="checked" id="mailing-list" value="Yes, sign me up!" /> </p> <p> <input type="submit" value="submit" /> <input type="reset" value="reset" /> </p> </fieldset> </form> |
Or
| Code: |
| <form id="contact-form" action="script.php" method="post">
<fieldset> <legend>Contact Us:</legend> <ul> <li> <label for="name">Name:</label> <input type="text" name="name" id="name" value="" /> </li> <li> <label for="email">Email:</label> <input type="text" name="email" id="email" value="" /> </li> <li> <label for="email">Comments:</label> <textarea name="comments" id="comments" cols="25" rows="3"></textarea> </li> <li> <label for="mailing-list">Would you like to sign up for our mailing list?</label> <input type="checkbox" checked="checked" id="mailing-list" value="Yes, sign me up!" /> </li> <li> <input type="submit" value="submit" /> <input type="reset" value="reset" /> </li> </ul> </fieldset> </form> |
Johan De Silva / Portfolio
Last edited by Johan007 on 16 Jul 2008 11:06 am; edited 1 time in total
Share: 
I've heard the arguments favouring ol/li elements, but I'm not swayed.
As far as p elements go, I've not heard anything remotely convincing for such use in forms.
For me, I tend to go with adding display: block; to label elements and then nesting the input elements within. (I know the input is not semantically a child of the input, but it's the least convoluted of the options I know of, whilst providing the floatable/clearable layout hook we like.
Share:
Bill. Not only is your form layout destroyed for users without CSS, if a programmer is doing the back end without access to the style sheet (maybe because CSS is still being built) they will start inventing a way around this such as including <br>'s that will get in the way of styling for front end developers.
There is another reason. <fieldset> is completely optional to group related content. Without a <fieldset> or <p> or <li> or something block level the form would fail validation.
Johan De Silva / Portfolio
Share:
| Johan007 wrote: |
| Bill. Not only is your form layout destroyed for users without CSS |
I know. Layout = presentation.
I consider it apt separation of structure and presentation not to implement additional elements (largely) for their presentational effects.
If, for whatever reason, a user is viewing the page without the presentation layer enabled, is it really sound logic to attempt to inject presentation into what remains?
I personally think not.
| Quote: |
| if a programmer is doing the back end without access to the style sheet (maybe because CSS is still being built) they will start inventing a way around this such as including <br>'s that will get in the way of styling for front end developers. |
I don't see why that would be the case. If I'm lead front-end for a project, then any other developers will be following my instructions.
| Quote: |
| There is another reason. <fieldset> is completely optional to group related content. Without a <fieldset> or <p> or <li> or something block level the form would fail validation. |
I know. Fieldset, whilst optional, is logical and semantic.
I certainly won't use fieldset on individual inputs merely to trigger a clear, but for wrapping the entire collection of inputs or sub-sets, it's logical and semantic; and there's going to be no validation issue.
Share:
| Bill Posters wrote: |
| If, for whatever reason, a user is viewing the page without the presentation layer enabled, is it really sound logic to attempt to inject presentation into what remains? |
The distinction between block-level and inline-level elements is primarily about the content model. The level of an element defines the basic type of group it indicates. You can think of them as implying either a break or a continuation of the theme in that part of the document.
Bill, we agree that form inputs are usually an illogical child of their <label>. Yay! I say usually because sometimes it makes sense for a control's current value to be part of its label. You should avoid implicit association of <label> elements because the label will usually be illogical.
Johan, this topic has cropped up before. Several times, probably! I'm still pretty sure <div> is the best element to group form controls with their associated <label>. Grouping controls with each other is best handled with <fieldset> and <legend>.
Share:
| Cerbera wrote: |
| The default presentation of elements is not "injected" by an author; it is native to the browser. |
I understand that, but when some developers appear to be scrabbling around for an element for its presentational consequences, because the native presentational outcomes don't suit their desired presentational outcome, I'd lay the charge of 'injecting' at the foot of those developers.
| Quote: |
| Documents tend to be usable without the author style when elements are both a logical type and a logical level. |
Tend, but not invariably. Form controls and labels are an example where the 'default' UA stylesheet has not been developed with implied presentational outcomes - relating to structural relativity - in mind.
The other default stylesheet inclusions tend to reflect their structural relativity, but there is no clear semantic reason for input controls (and their respective labels) to default to a 'one per line' 'structure' - which is to say that it's harder to justify than some other default stylesheet inclusions.
There is no implicit notion of how a sequence of input controls relate to each (in that they might individuate as block-level elements), only that the relationship be clear between a control and its respective label.
| Quote: |
| Bill, we agree that form inputs are usually an illogical child of their <label>. Yay! I say usually because sometimes it makes sense for a control's current value to be part of its label. You should avoid implicit association of <label> elements because the label will usually be illogical. |
I see your point, but I'm not convinced that the typical use of implicit labels could be considered illogical. A little punctuation can typically impart the logical relationship between the label text and the (textual) value of the input control.
e.g.
| Code: |
| <label for="…">First Name:
<input type="text" id="…" name="…" /> <label> |
The linearized output being…
First Name: Ben
…which I feel communicates sufficiently well.
| Quote: |
| I'm still pretty sure <div> is the best element to group form controls with their associated <label>. Grouping controls with each other is best handled with <fieldset> and <legend>. |
I'd certainly agree that it's the most easily 'pardonable' option, if absolutely set on having a clearing element in there.
However, as said, it's still being driven by the want of a presentational outcome… …imo.
All that said, as you say, it's almost certainly all been said before here.
Share:
The reasons I brought up this topic again was because I was interested to see a new angle due to developments in HTML5 or to see if common trend was taking place before I standardise a practice company wide.
I think both your views are excellent and agree with it all. While understand the benefits of all including <div> I will however be sticking with <p> for the reason that programmers will understand that they clear and the HTML is easier and smaller to read (generally less divitis).
Johan De Silva / Portfolio
Share:
| Johan007 wrote: |
| I will however be sticking with <p> for the reason that programmers will understand that they clear |
If your programmers don't understand that divs clear, then you're working with some pretty shoddy developers.
| Quote: |
| and the HTML is easier and smaller to read (generally less divitis). |
I think you may be missing the point of 'divitis'. I certainly wouldn't start feeling you'd avoided divitis simply because you've used p elements in their place.
Of course, you're free to use whatever you wish, but I don't think the reasons you've chosen to use p over div (or either over the alternatives) stand up too well.
Share:
| Bill Posters wrote: |
| Of course, you're free to use whatever you wish, but I don't think the reasons you've chosen to use p over div (or either over the alternatives) stand up too well. |
Johan De Silva / Portfolio
Share:
| Johan007 wrote: |
| Ok what if a form has two or more <feilsets>, you would then need to place the submit buttons outside the <feilsets> to be logical. This would not validate in xHTML without a block level container |
(Fwiw, it's valid to nest fieldsets.)
| Johan007 wrote: |
| choosing <p> simply look cleaner than any other without any real world drawbacks. |
I still don't see what the drawback is with using a div which isn't also there when using p?
Share:
Sure I could warm to the idea of <div>'s.
Share:
If you use a device which lets you skip between paragraphs, it usually does this by skipping between <p> elements. If you use <p> for things which aren't really paragraphs (such as a form control with a label) then users get a weird experience. Imagine: "I asked for the next paragraph, not the next form field. What's going on?"
The same applies to list items, table cells, headings and so forth. Using elements whose semantics aren't quite right is best avoided when there is a more suitable choice. Sometimes, the more suitable choice is a neutral grouping element such as <div> or <span>.
The type of element affects features which make use of document semantics, so it's worth using a logical type. The level of an element affects the default presentation in a similar way, so it's worth using a logical level. I actually agree with Bill that the type is more important than the level. But if there's a reasonable match for both, use that.
The content model in HTML5 was significantly loosened in late 2007 to remove some unhelpful restrictions on markup. Maybe form controls as direct children of <form> will become valid? How authors write forms is an area I intend to study this year. Current form development still seems deadlocked at W3C, AFAICT.
Share:
I'm not convinced yet that <div>s are the way to go with form fields. Mainly, the arguments against paragraphs (and even items in an ordered list—I've been meaning to get back to you on that, Cerbera! 
) remind me uncomfortably of a debate I had with someone who insisted on using semantically neutral elements for everything:
| Quote: |
| Me: Why are you using a <div> for the heading? Why not use a heading?
Him: Because it's not a heading. It's a logo image and the name of the site. Me: …OK, but it's pretty close to being a heading for the site, don't you think? Him: But not exactly. Which is why I'm using a <div> with a class. … Me: Why isn't that bit of text a paragraph? Him: Because it's a tagline. Me: But it's also a paragraph of text. Him: Yes, but not exactly. [Repeat <div> with class justification.] … Me: Why do you use <i> instead of <em> here? Him: Because I want it to be in italics, not emphasised. Me: But you're italicising it in order to emphasise it, because it's important. Him: No, I'm just italicising this bit of text for visual contrast. |
I'm quoting that mostly for humour and a little to illustrate the point, and emphatically not to imply that anyone here is being this awkward.
But you see what I mean. I'd say that these groups of form items are pretty close to being paragraphs:
| Quote: |
| Full name (as given on your bank card): [__________________]
Date of birth—day: [__], month: [__] and year: [____] What type of card are you using? Mastercard [X], Visa [ ], Switch [ ] |
Perhaps they are a little short, but there is no absolute minimum limit on paragraph length; and off-hand, I have not heard of any word more suited to describe the conjunction of a form label and the area in which data is provided—in web design, or in real life.
Certainly, most forms I fill out in real life are (to my recollection) presented as ordered lists. Occasionally, the layout implies a table, with each form label serving as a row heading of sorts, and occasionally they are presented as plain paragraphs.
Actually, that suggests an interesting experiment. I just fished my passport form from my bag, and it is presented in various parts—apparently divided by headings, not into items. Intuitively, it looks like the sort of thing I would expect to see if elements were actually just one after the other, in sequence (as suggested by Bill), but with occasional line breaks for structure.
A second form I've located is very definitely in paragraphs, with full and natural descriptions serving as labels.
Anyone care to look out some more real-life forms? How do you think they would be marked up?
Share:
... I am getting used to DIV's now 
but agree this is always going to be subjective unless a authoritative validators flag it up. I kind of agree with "him" regarding the logo being purely informative/decorative and not a heading about the the content section, however I can see the other side of the argument especially as W3C's own site is inconsistent often placing both the logo and the document title inside the same <h1> 
Unfortunately I can not find any web forms on the W3C website that could give us a clue as to best practice...anyone?Johan De Silva / Portfolio
Share:
| Johan007 wrote: |
| Unfortunately I can not find any web forms on the W3C website that could give us a clue as to best practice...anyone? |
Johan, can't find anything at W3C either...but I did find an interesting article by Roger Hudson about designing forms for WCAG 2.0. It may help, then again, you've probably read it already.
Share: