4 ms·

Can we please come up with a better markup for form element grouping than "div.control-group"? Specifically, HTML has always allowed nesting an <input> inside

Can we please come up with a better markup for form element grouping than "div.control-group"? Specifically, HTML has always allowed nesting an <input> inside <label> - and that's more than enough to create either a horizontal or stacked layout. No <div>s needed. And no "for" attribute needed with an unnecessary input ID.

orky56 13y ago
That's a fair point. Although div's are not completely necessary for this purpose from a functional perspective, the standard definitely allows one to understand/create the layout of the page more efficiently.
lewisflude 13y ago
Sometimes introducing more markup can be better architecturally. I agree, .control-group isn't the nicest way of doing things but I don't think nesting an input inside a label is any better.
- mmatants 13y ago
  I do not see any disadvantages to nesting inputs inside labels - and it's actually quite semantic and maintainable (in part because inputs no longer need auto-generated IDs). This approach has been part of the HTML standard pretty much always, as well. It doesn't matter much if forms are generated using a builder like Formtastic, etc. But even then less custom CSS classes is usually better. This way I have been able to write CSS for fairly complex forms using just standard tag selectors, with just one class on the root form container to separate multiple form styles.
  - tracker1 13y ago
    When you put a label with text and the input inside, how would you get the text to take up 150px and the input to be to the right of that consistently across a large form? Such as here: https://www.roadreadycertified.com/order/begin/ https://www.roadreadycertified.com/order/begin/ Note: It's just an example, not promoting the site.
    - mmatants 13y ago
      It's possible to do by adding a padding-right as well as position:relative on the label, and then position:absolute on the input to place it over the padded area. Not the easiest CSS to write, but I strongly prefer clean markup (at a cost of hackish CSS) to hackish markup.
      - tracker1 13y ago
        I don't really consider that cleaner markup... Now you have a single element containing a text now and another element that can not be transverse independently... As opposed to an e extra tag. You could do the label with a span and the input y though, and then mark your CSS that way as a convention... But then you aren't using a bad framework meant to have broader interoperability in mind.
nerdbites 13y ago
To my knowledge this is incorrect. Assistive technologies don't recognize input names when nested inside of label elements, and as a result is frowned upon by the W3C. Unless you meant something else by, "...HTML has always allowed nesting an <input> inside <label>..." Source: http://www.w3.org/TR/WCAG20-TECHS/F68.html http://www.w3.org/TR/WCAG20-TECHS/F68.html
- mmatants 13y ago
  The results on that page puzzle me for the nested input/label case - this is news to me. Given how browsers already forward focus for clicks on a label to the nested input, I always assumed that this takes care of programmatic association between label and input. Maybe an aria-labelledby attribute would fix this? Heck, could still use a label "for" attribute and keep the input nested. Either way, I meant that it is legal HTML to do that kind of nesting. Did not know that it was frowned upon, as far as standards are concerned, even assistive.

orky56 13y ago

That's a fair point. Although div's are not completely necessary for this purpose from a functional perspective, the standard definitely allows one to understand/create the layout of the page more efficiently.

lewisflude 13y ago

Sometimes introducing more markup can be better architecturally. I agree, .control-group isn't the nicest way of doing things but I don't think nesting an input inside a label is any better.

mmatants 13y ago
I do not see any disadvantages to nesting inputs inside labels - and it's actually quite semantic and maintainable (in part because inputs no longer need auto-generated IDs). This approach has been part of the HTML standard pretty much always, as well. It doesn't matter much if forms are generated using a builder like Formtastic, etc. But even then less custom CSS classes is usually better. This way I have been able to write CSS for fairly complex forms using just standard tag selectors, with just one class on the root form container to separate multiple form styles.
- tracker1 13y ago
  When you put a label with text and the input inside, how would you get the text to take up 150px and the input to be to the right of that consistently across a large form? Such as here: https://www.roadreadycertified.com/order/begin/ https://www.roadreadycertified.com/order/begin/ Note: It's just an example, not promoting the site.
  - mmatants 13y ago
    It's possible to do by adding a padding-right as well as position:relative on the label, and then position:absolute on the input to place it over the padded area. Not the easiest CSS to write, but I strongly prefer clean markup (at a cost of hackish CSS) to hackish markup.
    - tracker1 13y ago
      I don't really consider that cleaner markup... Now you have a single element containing a text now and another element that can not be transverse independently... As opposed to an e extra tag. You could do the label with a span and the input y though, and then mark your CSS that way as a convention... But then you aren't using a bad framework meant to have broader interoperability in mind.

nerdbites 13y ago

To my knowledge this is incorrect. Assistive technologies don't recognize input names when nested inside of label elements, and as a result is frowned upon by the W3C. Unless you meant something else by, "...HTML has always allowed nesting an <input> inside <label>..." Source: http://www.w3.org/TR/WCAG20-TECHS/F68.html http://www.w3.org/TR/WCAG20-TECHS/F68.html

mmatants 13y ago
The results on that page puzzle me for the nested input/label case - this is news to me. Given how browsers already forward focus for clicks on a label to the nested input, I always assumed that this takes care of programmatic association between label and input. Maybe an aria-labelledby attribute would fix this? Heck, could still use a label "for" attribute and keep the input nested. Either way, I meant that it is legal HTML to do that kind of nesting. Did not know that it was frowned upon, as far as standards are concerned, even assistive.