Hacker News Reader

Comment by CodesInChaos | Hacker News Reader

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)

View on HN

Every 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?

This 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.

Yeah 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>

AFAIK <input> is hardcoded as self-closing in the html5 parser.

Hm interesting... presumably this could be changed though? We aren't locked to <input> following one convention, are we?

<input> has been an empty element right from the start, meaning it mustn’t have any children. (And the HTML syntax enforces this.)

Reply on news.ycombinator.com