bokand
commented
9 months ago The example given is meant as a warning that the UA shouldn't just blindly tack the text onto an existing fragment id.
Generating the fallback id automatically is indeed difficult to do well. This (non-normative) section is admittedly less prescriptive than event the surrounding sections. I think it boils down to: when generating a text directive, strip out the fragment-id unless you're sure it's what the user wants. (though it seems in Chrome we didn't follow our own advice...)
I think there's some potentially useful heuristics that might work reasonably. E.g. look at the first ancestor that's a section-like element (<h1>, <h2>, <h#>, <section>, <details>, etc.) and if it has an id, use that. Otherwise use no id. Maybe something along those lines would be better?
zcorpan
From how I understand the mentioned section, the User Agent may arbitrarily provide a fallback element-id in case the document changed and the text directive is not found on the page anymore. However, there is an example which should explain which fallback id is appropriate and which isn't.
It is unclear to me how that should work. Given that a page may have element-ids for every HTML element (as an extreme case), how should the User Agent decide which id to use as a fallback? Should it be an element which is in the same viewport (then the link would depend on the resolution / size of the window at creation time)? Or should it be the next id when traversing backwards?
To me this imposes the risk that an id is picked which is misleading and unless specified in more detail I would propose to remove this section from the spec.
CC @zcorpan