To me that's conceptually as well as semantically broken, the two are separate things why is the input inside the label? He's saying make everything semantic, and then semantically breaking forms.
Also if you have any inputs that don't have a label for whatever reason you either have to wrap them in them any way to get CSS to work or make sure you never rely on the input being nested in the label in your CSS.
And having them apart also makes it easier to design responsively if you want a side-by-side design for desktop vs a stacked design for mobile.
Saves having to add a for tag I guess.
I guess a lot of that article is opinion though, so you're always going to get people objecting to one point or another, though a lot of it seems sensible advice.
I don't think the article is even advocating for nested vs. not-nested inputs with labels, the author just picked nested to use in the example. The point of the example was to have a <label>. There's no reason to go to war over nested vs. not-nested.
The only exceptions to "each input must have a label" are inputs of type "hidden" and ones that make button controls so the value attribute effectively labels the control.
But that means there may be an area between the label and the input element (depending on margins and so forth) which is not clickable. Having the label separate makes sense if it's all in a table-like structure, though.
> Is it common these days to nest inputs in labels?
Been developing websites for almost 15 years now, and I recall this always being a common thing to do.
> To me that's conceptually as well as semantically broken, the two are separate things why is the input inside the label?
I agree that it's conceptually broken, but it is not semantically broken -- since the HTML5 spec and screen readers all recognize this as an equally valid way to define a label on an input.
So they're both equally "correct", just a trade-off of ease-of-styling (for some designs) vs. saving a few bytes and mental overhead of assigning for/id attributes to them.
I would call it pragmatic, as it makes the CSS easier when you want to put a custom checkbox design. Either way, it doesn't seem to be doing them any harm.
I'd thought that was the only way to get clicking on a checkbox label to trigger the checkbox click (unlike other inputs where you could simply use a for label).
To me that's conceptually as well as semantically broken, the two are separate things why is the input inside the label? He's saying make everything semantic, and then semantically breaking forms.
Also if you have any inputs that don't have a label for whatever reason you either have to wrap them in them any way to get CSS to work or make sure you never rely on the input being nested in the label in your CSS.
And having them apart also makes it easier to design responsively if you want a side-by-side design for desktop vs a stacked design for mobile.
Saves having to add a for tag I guess.
I guess a lot of that article is opinion though, so you're always going to get people objecting to one point or another, though a lot of it seems sensible advice.