Comments on: Forms Markup and CSS http://nidahas.com/2006/01/12/forms-markup-and-css/ Musings on design, web standards and free software from a Sri Lankan geek Sat, 20 Mar 2010 05:42:26 +0000 http://wordpress.org/?v=2.1 By: Maaike http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-273 Maaike Thu, 12 Jan 2006 12:41:20 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-273 Well... I'm not quite a standardista, but I do have an opinion. I think using unordered lists for radio buttons and checkboxes is a good and sensible decision. After all, they really are lists of options. However, I disagree about setting the width of input elements in the html. I don't see how the sizing of boxes, fonts etc is semantically any different from sizing form elements. The maxlength is indeed a programmatical decision (after all, you can't actually *see* it), but sizing is about looks, not content. Well… I’m not quite a standardista, but I do have an opinion.
I think using unordered lists for radio buttons and checkboxes is a good and sensible decision. After all, they really are lists of options.
However, I disagree about setting the width of input elements in the html. I don’t see how the sizing of boxes, fonts etc is semantically any different from sizing form elements. The maxlength is indeed a programmatical decision (after all, you can’t actually *see* it), but sizing is about looks, not content.

]]> By: Mats Lindblad http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-274 Mats Lindblad Thu, 12 Jan 2006 12:47:53 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-274 I agree that the size of a input field isn't a presentational one. Although it's alway good to have a fallback plan. I was reading Roger Johanssons recent post on <a href="http://www.456bereastreet.com/archive/200601/css_3_selectors_explained/" rel="nofollow">CSS 3 selectors explained</a> and didn't get the point of using <code>:not()</code> so I checked the spec to see if they had a better explanation. Their example gave the idea for this snippet: <code>input[type="text"]:not([size]) {width: 15em}</code> This works in Firefox and gives any text input field which is missing the size attribute a width of 15em, like I said, this is just a fallback in case you missed one field. I think the Sahana form looked good and thanks for the link to Simply Accessible. Hope I've been helpful. :) I agree that the size of a input field isn’t a presentational one. Although it’s alway good to have a fallback plan.

I was reading Roger Johanssons recent post on CSS 3 selectors explained and didn’t get the point of using :not() so I checked the spec to see if they had a better explanation. Their example gave the idea for this snippet:
input[type="text"]:not([size]) {width: 15em}
This works in Firefox and gives any text input field which is missing the size attribute a width of 15em, like I said, this is just a fallback in case you missed one field.

I think the Sahana form looked good and thanks for the link to Simply Accessible.

Hope I’ve been helpful. :)

]]> By: Rob Wilmshurst http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-275 Rob Wilmshurst Thu, 12 Jan 2006 13:05:58 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-275 I pretty much agree with Maaike. However, I usually use defenition lists rather than a simple unordered list because they give more control over the <label> element (and are ever-so slightly more samtically correct) <code> <dl> <dt><label for="field1">field 1 Label</dt> <dd><input type="whatever" id="field1" /></dd> </dl> </code> I'd define width in the CSS using EMs - it gives a very similar width to using the "size" attribute. I see Maxlength as programatical, so leave it in the markup. But the size attribute is a presentational thing, showing the visible width of the input. In my book at least that makes it the responsibility of the CSS. My two pennies :) I pretty much agree with Maaike. However, I usually use defenition lists rather than a simple unordered list because they give more control over the <label> element (and are ever-so slightly more samtically correct)

<dl>
<dt><label for="field1">field 1 Label</dt>
<dd><input type="whatever" id="field1" /></dd>
</dl>

I’d define width in the CSS using EMs - it gives a very similar width to using the “size” attribute.
I see Maxlength as programatical, so leave it in the markup. But the size attribute is a presentational thing, showing the visible width of the input. In my book at least that makes it the responsibility of the CSS.

My two pennies :)

]]> By: Prabhath http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-276 Prabhath Thu, 12 Jan 2006 13:19:09 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-276 The "size" attribute <em>is</em> a tricky issue, and I think the decision depends a lot on the context. For web based applications, the size of the input fields could be seen as a programmatical decision because it provides an important cue as to the type of input expected. Unlike the font declarations and colours, it seems more closely linked to the application logic. Anyways, we haven't really finalized anything so your input is much appreciated. The “size” attribute is a tricky issue, and I think the decision depends a lot on the context. For web based applications, the size of the input fields could be seen as a programmatical decision because it provides an important cue as to the type of input expected. Unlike the font declarations and colours, it seems more closely linked to the application logic. Anyways, we haven’t really finalized anything so your input is much appreciated.

]]> By: trovster http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-277 trovster Thu, 12 Jan 2006 13:36:22 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-277 Rob: That's exactly how I setup my forms. Adds a stronger association between the elements, and continuity when styling. I like the idea of the unordered list for radio/checkboxes. Rob: That’s exactly how I setup my forms. Adds a stronger association between the elements, and continuity when styling.

I like the idea of the unordered list for radio/checkboxes.

]]> By: ismael http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-278 ismael Thu, 12 Jan 2006 14:21:53 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-278 Hi. Over the time I've come to use the following structure for my forms: My form my field my field 2 This gives me enough control over the layout ('s generally are rows) and fexibility. Hi.
Over the time I’ve come to use the following structure for my forms:

My form

my field

my field 2

This gives me enough control over the layout (’s generally are rows) and fexibility.

]]> By: Matt Wilcox http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-279 Matt Wilcox Thu, 12 Jan 2006 20:06:51 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-279 There's sometimes a danger of going overboard with semantics. I can, for example, define almost anything as being a list. A webpage might be seen as a list of ordered paragraphs, and even a paragraph is just an ordered list of words, and if I were to mark them up as such, well, it's valid and correct. Just a bit obtuse. The question that I try to remember to ask myself when I'm getting carried away is this: If I were to use this markup I am adding additional meaning (e.g. 'this paragraph consists of an ordered list of words') - but to what end? What does it gain anyone in their understanding of the content? (Isn't it already implied that a paragraph is an ordered list of words? Does it need spelling out semantically?) In a similar way I often find the normal form elements offer sufficient semantics and layout potential to not need additional semantic support in the markup. Take the radio options as an example: yes, they are a list of options, and would belong in a ul, or an ol, maybe even a dl. But a radioset is by it's very nature a list of choices, the meaning is already inherent in and of itself. Wrap each input in it's own label, wrap the lot in a fieldset with a legend and you're done. Less HTML to contend with, still very semantic - but less verbose about it. Of course, some occassions demand the extra clarity, or increased styling potential, of different mark-up... Using ul's for forms isn't wrong, but it's not neccesarily any better than not using a ul. Whether or not that is the case will depend on their context within the form and the page. There’s sometimes a danger of going overboard with semantics. I can, for example, define almost anything as being a list. A webpage might be seen as a list of ordered paragraphs, and even a paragraph is just an ordered list of words, and if I were to mark them up as such, well, it’s valid and correct. Just a bit obtuse. The question that I try to remember to ask myself when I’m getting carried away is this: If I were to use this markup I am adding additional meaning (e.g. ‘this paragraph consists of an ordered list of words’) - but to what end? What does it gain anyone in their understanding of the content? (Isn’t it already implied that a paragraph is an ordered list of words? Does it need spelling out semantically?)
In a similar way I often find the normal form elements offer sufficient semantics and layout potential to not need additional semantic support in the markup. Take the radio options as an example: yes, they are a list of options, and would belong in a ul, or an ol, maybe even a dl. But a radioset is by it’s very nature a list of choices, the meaning is already inherent in and of itself. Wrap each input in it’s own label, wrap the lot in a fieldset with a legend and you’re done. Less HTML to contend with, still very semantic - but less verbose about it. Of course, some occassions demand the extra clarity, or increased styling potential, of different mark-up…

Using ul’s for forms isn’t wrong, but it’s not neccesarily any better than not using a ul. Whether or not that is the case will depend on their context within the form and the page.

]]> By: ismael http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-281 ismael Thu, 12 Jan 2006 23:02:10 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-281 Sorry i didn't use html entities, my example was lost. Sorry i didn’t use html entities, my example was lost.

]]> By: Prabhath http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-282 Prabhath Fri, 13 Jan 2006 02:49:41 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-282 <strong>ismael</strong>: Could you point us to a sample page? <strong>Matt</strong>: More than anything else the main reason for using a list for radio controls was the ease of automating the form generation. The programmers will not be marking up their own forms but will be using a general script to create them for their modules within the system. In such instances where we don't have direct control over how the form will be marked up, and we need to create a script that handles any kind of form without a hitch, lists give a nice way to distinguish radio buttons and checkboxes from other form controls. And the nice part is, even if it's not the best way, it's still semantically not incorrect (ooo, double negative ;-) ). ismael: Could you point us to a sample page?

Matt: More than anything else the main reason for using a list for radio controls was the ease of automating the form generation. The programmers will not be marking up their own forms but will be using a general script to create them for their modules within the system. In such instances where we don’t have direct control over how the form will be marked up, and we need to create a script that handles any kind of form without a hitch, lists give a nice way to distinguish radio buttons and checkboxes from other form controls. And the nice part is, even if it’s not the best way, it’s still semantically not incorrect (ooo, double negative ;-) ).

]]> By: Bramus! http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-283 Bramus! Fri, 13 Jan 2006 07:35:49 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-283 Most of the time, I use this: form ___fieldset ______legend - /legend ______ ______label ______input ______ ______label ______input ______ ___/fieldset ___ ___fieldset ______ ... ___/fieldset /form That's how a form should be ... not need of adding any type of list. A form is a form, not a list. --> In a form, things are grouped with a fieldset. --> In a form, fields are described with a label. Those 2 together : that's more than enough and provides plenty of options. Most of the time, I use this:

form
___fieldset
______legend - /legend
______
______label
______input
______
______label
______input
______
___/fieldset
___
___fieldset
______
…
___/fieldset
/form

That’s how a form should be … not need of adding any type of list. A form is a form, not a list.
–> In a form, things are grouped with a fieldset.
–> In a form, fields are described with a label.
Those 2 together : that’s more than enough and provides plenty of options.

]]> By: Prabhath http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-284 Prabhath Fri, 13 Jan 2006 13:34:02 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-284 <strong>Bramus</strong>: Sahana forms <em>are</em> marked up like that. Lists are used for radio buttons and checkboxes only. Bramus: Sahana forms are marked up like that. Lists are used for radio buttons and checkboxes only.

]]> By: Kim Siever http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-285 Kim Siever Fri, 13 Jan 2006 17:05:11 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-285 I stay away from using lists form form controls. An unstyled page looks unweidly with a bunch of radio buttons each preceded by a bullet. I stay away from using lists form form controls. An unstyled page looks unweidly with a bunch of radio buttons each preceded by a bullet.

]]> By: Bramus! http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-286 Bramus! Sat, 14 Jan 2006 01:28:03 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-286 <b>Prabhath</b> I should have expressed the <i>"A form is a form, not a list."</i> a bit more ... see Matt Wilcox' reply I have the same opinion as him: there's no need to add extra markup for an option list. Besides, radiobuttons already are grouped by their name attribute. The structural code I posted is one that I use, and I think it offers more than enough option to play with. The thing you actually are proposing seems more like an extension to the current form standards ... you kinda imply to add sth like an optgroup for option elements, but then for radiobuttons and checkboxes. But unfortunately this does not look to happen since I don't see it anywhere in the <a href="http://whatwg.org/specs/web-forms/current-work/" rel="nofollow"> Web forms 2.0 Working Draft</a> ... maybe it's an idea to notify the creators of the draft of? Best regards, Bram Prabhath I should have expressed the “A form is a form, not a list.” a bit more … see Matt Wilcox’ reply I have the same opinion as him: there’s no need to add extra markup for an option list. Besides, radiobuttons already are grouped by their name attribute.
The structural code I posted is one that I use, and I think it offers more than enough option to play with.
The thing you actually are proposing seems more like an extension to the current form standards … you kinda imply to add sth like an optgroup for option elements, but then for radiobuttons and checkboxes. But unfortunately this does not look to happen since I don’t see it anywhere in the Web forms 2.0 Working Draft … maybe it’s an idea to notify the creators of the draft of?

Best regards,
Bram

]]> By: Bramus! http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-287 Bramus! Sat, 14 Jan 2006 01:37:23 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-287 Some more W3-site-digging ... most likely the <a href="http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-xforms.html#XForms_Group">group element</a> will become available in the XForms module of XHTML 2.0, but that's still a long way to go... Above that they haven't described it yet (only thing up there is "group elements can freely nest."), so there's only to guess what it will be(come). Some more W3-site-digging … most likely the group element will become available in the XForms module of XHTML 2.0, but that’s still a long way to go… Above that they haven’t described it yet (only thing up there is “group elements can freely nest.”), so there’s only to guess what it will be(come).

]]> By: Prabhath http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-289 Prabhath Sat, 14 Jan 2006 04:50:05 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-289 Thanks Bramus. I guess using lists is a questionable idea afterall. Then we'll have to resort to the <br /> to stop radios and checkboxes appearing inline. Giving them a <strong>display: block</strong> and/or floating is an option, but then you need to give them a separate class due to poor browser support for attribute selectors (i.e. IE). Thanks Bramus. I guess using lists is a questionable idea afterall.

Then we’ll have to resort to the <br /> to stop radios and checkboxes appearing inline. Giving them a display: block and/or floating is an option, but then you need to give them a separate class due to poor browser support for attribute selectors (i.e. IE).

]]> By: ismael http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-291 ismael Thu, 26 Jan 2006 14:57:54 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-291 What I meant was: fieldset --legend --p ----label ----input --p ----label ----textarea etc What I meant was:
fieldset
–legend
–p
—-label
—-input
–p
—-label
—-textarea
etc

]]> By: Ben Boyle http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-852 Ben Boyle Mon, 24 Apr 2006 00:32:29 +0000 http://nidahas.com/2006/01/12/forms-markup-and-css/#comment-852 That's a nice form design Prabhath :) I like the error summary presented at the top, and I'd like it even more if each message linked to the relevant field. I can't take credit for that suggestion though, I read about it at <a href="http://www.standards-schmandards.com/index.php?2005/06/25/21-accessible-errors" rel="nofollow">Communicating error messages accessibly</a>. The issues with grouping radio buttons are frustrating. The problem I find is that HTML forces us to treat each choice as a separate control, and there is no clear element for the entire group. In XForms this is completely different - the <a href="http://www.w3.org/TR/2006/REC-xforms-20060314/slice8.html#ui-selectOne" rel="nofollow">xforms:select1</a> element represents the group and each choice is an item within the group. The entire group is represented by one control, which will be much easier to deal with, very similar to select lists in HTML (and makes sense, they are essentially different presentations of the same functionality). The best suggestion I have come across for dealing with this in HTML, and someone posted this above, is to use <a href="http://www.webaim.org/techniques/forms/4#radio" rel="nofollow">fieldset for grouping radio buttons</a>. I confess I haven't tried this in practice myself (yet). Thanks for sharing your insights! :) That’s a nice form design Prabhath :)

I like the error summary presented at the top, and I’d like it even more if each message linked to the relevant field. I can’t take credit for that suggestion though, I read about it at Communicating error messages accessibly.

The issues with grouping radio buttons are frustrating. The problem I find is that HTML forces us to treat each choice as a separate control, and there is no clear element for the entire group. In XForms this is completely different - the xforms:select1 element represents the group and each choice is an item within the group. The entire group is represented by one control, which will be much easier to deal with, very similar to select lists in HTML (and makes sense, they are essentially different presentations of the same functionality).

The best suggestion I have come across for dealing with this in HTML, and someone posted this above, is to use fieldset for grouping radio buttons. I confess I haven’t tried this in practice myself (yet).

Thanks for sharing your insights! :)

]]>