Skip to content


Subversion checkout URL

You can clone with
Download ZIP


checkbox inputs should not be nested inside their labels #60

activestylus opened this Issue · 15 comments

3 participants


In my humble experience, this is just asking for trouble. It's the cheap way to link a label to the input, which is already taken care of by the "for" attribute. You don;t wrap text inputs, why should checks get special treatment? It also makes for styling hell in IE6 (your *html hacks wont always save you)

Right now I'm working on a styling framework built around formtastic and have almost all browsers behaving nice - except you-know-who. IncompetentExploder makes the checkboxes look all hurt up, and struggling to align. It works MUCH better when those inputs are not nested.

Standards FTW


the checkbox inputs are inside the labels not because it's "cheap" (we already have the "for" attribute) but because it's a common markup pattern. I don't have a strong opinion either way, but i'll have a think about it and maybe some others can chime in.

in the meantime i'll re-label your issue to "checkbox inputs should not be nested inside their labels (maybe)"

very keen to hear more about what you're building!

personally, I've found life much more enjoyable when all the IE6 quirks are tackled in an IE6-only stylesheet.


I got to agree with Justin: IE-hacks should not belong to the core "formtastic.css" - rather a "formtastic_ie.css". Actually, it seems developers care less about IE for every day now it seems - at least in Europe. Maybe because of this:


...oh btw, I'm still thinking of spending an hour or two on a fromtastic_blueprint.css - or even Compass + SASS-based. My guess would be that it'll look better in all browsers, and be a fraction in size and complexity in compare to the current one. Much happened on the CSS framework side since it was made I guess.


Grimen, I have already built exactly what you describe using Compass, you can plug Blueprint, 960 or whatever right in.

I didnt want to push this up so quick (still looks like ASS on IE6), but take a peek and let me know what you guys think.


OK, cool - will try it out some day when I get time. Note though that not everyone uses Compass - as far as I know, many don't. So maybe there should be hardcoded ones (easy to generate based on your templates with Compass though).


...and yea, I wouldn't bother about IE6 at all - even Google officially dropped support for it, among some of the worlds biggest websites.


I leave CSS generation up to Sass. You don't really need compass, but this framework is included in my _base.sass


Thanks for the link grimen - will definitely give it a whirl when I have time


Respected proposers of (non-label-wrapped checkboxes)

Dan Cederholm - Mr. semantics himself I would say

HTML Dog - usually very good on semantics

Also after asking myself why checkbox should be treated differently - really, and seeing what the pros say by doing some research, I think I just switched side: My vote is on non-label-wrapped inputs.


I think I got a scalable win-win solution on this one: Adding an option :wrapped => true/false. It'll be easy to style both cases with help of a class on the LI-element that tells what style is used. Yes/No/Maybe? =)


I don't like indifference and preferences ;)

If we decide it needs to be the author's choice instead of mine, then it should be a preference, because I can't imagine people wanting the choice on each and every input.


True, I just had a feeling this is the type of thing that will never have consensus - I wish W3C did this for us, they so slow in the turns. =P


+1 for setting a global preference - good idea grimen!


I'm closing this for now, as I don't want to change this prior to 1.0, nor anytime soon thereafter. There are thousands of Formtastic users, and only a few care about this. In reality, this will go away when we have partials for rendering, and everyone can choose their own markup ;)

@zuf zuf referenced this issue from a commit in zuf/formtastic
@justinfrench Resolves issue #87 (a bug introduced in d8290cf), in which two labels…
… were being rendered in boolean inputs.

* input_spec.rb changed to ensure only one label rendered, exposing the bug
* boolean_input now inserts the checkbox input into the options hash to pass to the label()
* label() now knows what to do with the special key in the options hash, inserting the input into the label at the last minute (after i18n, etc)

This will all probably be undone when/if we move the input outside the label (issue #60) :)
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.