Well, I think the win is it's easier if you hand code a lot. If you're using a framework to do this for you, it should be semantically correct out of the box without you needing to think about it.
So, this is handy for folks like me who make a lot of web based tools just for my use or those in my immediate internal group.
<philosophyzimigating>
To your point, though, one could argue semantics are misconceived in the case of labels and controls. The label is the meaning, the control is meaningless outside of the context of the label. So while convention is focused on a semantic that supports a legacy hierarchy where controls are often thought of first by the developer and the label secondarily, to the user, the label is the meaning and it might be worth while to revise semantics in that direction. What meaning has a control apart from its label? One label can be applied to any number of controls and still have meaning.... but a control with no label is meaningless.
Well, I think the win is it's easier if you hand code a lot. If you're using a framework to do this for you, it should be semantically correct out of the box without you needing to think about it.
So, this is handy for folks like me who make a lot of web based tools just for my use or those in my immediate internal group.
<philosophyzimigating>
To your point, though, one could argue semantics are misconceived in the case of labels and controls. The label is the meaning, the control is meaningless outside of the context of the label. So while convention is focused on a semantic that supports a legacy hierarchy where controls are often thought of first by the developer and the label secondarily, to the user, the label is the meaning and it might be worth while to revise semantics in that direction. What meaning has a control apart from its label? One label can be applied to any number of controls and still have meaning.... but a control with no label is meaningless.
</philosophyzimigating>