HTML has a few kludges here and there that seem questionable on close inspection. Sure, having the "id" attribute and then referring to this id from anywhere el

HTML has a few kludges here and there that seem questionable on close inspection. Sure, having the "id" attribute and then referring to this id from anywhere else allows you to build an arbitrary directed graph of relationships independent of the DOM tree. And that's useful in CSS selectors and from JS and so on. Within HTML itself, the "for" attribute on a label has two behaviors... One is to read out the label for a given input for visually impaired users, and the other is to focus the input when you click the label. The focus behavior is kinda useless, most people click the input, not the label. But OK, it's harmless, and nice to have. The accessibility feature makes more sense but also highlights the fact that a control and its label are intrinsically one unit. And in many UI frameworks they are one unit. So why aren't they in HTML? Because INPUT existed in HTML far before accessibility was a concern, and people were writing out labels outside the inputs. So later versions of HTML had to deal with the status quo, and added LABEL to "patch" the problem without disrupting the existing form control behavior. So this particular case is a historical quirk. Would HTML be redesigned, the label would be in the input, and you'd probably be styling it with a pseudo-selector, like you do :placeholder etc.