5 ms·
I don't like that this relies on globally unique ids to link elements. I would prefer the ability to specify some kind of relative path instead. (there are simi
by CodesInChaos 5y ago
I don't like that this relies on globally unique ids to link elements. I would prefer the ability to specify some kind of relative path instead. (there are similar problems in other areas, like aria)
- whoisthemachine 5y agoYeah it's kind of awkward. My first assumption would have been that it would have had semantic similarities to a `<select>`, ie <input type="datalist"> <option>a</option> </input>
- CodesInChaos 5y agoAFAIK <input> is hardcoded as self-closing in the html5 parser.
- whoisthemachine 5y agoHm interesting... presumably this could be changed though? We aren't locked to <input> following one convention, are we?
- chrismorgan 5y ago<input> has been an empty element right from the start, meaning it mustn’t have any children. (And the HTML syntax enforces this.)
- AbsoluteDestiny 5y agoEvery linked element relies on ids: anchors, the label for attribute, all of the aria-labelledby, controls, describedby etc. Sure a full selector would be better but what level of css selectors do you support when writing the spec for user agents to know that can support the element?
- earthboundkid 5y agoThis is a general problem with HTML5. I end up having to write some kind of autoincrementIdCounter function in every frontend templating language I use to work around it. I wish it was on W3C's radar as a thing that makes life harder for developers.