This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/multipage/dom.html Multipage: https://html.spec.whatwg.org/multipage/#the-id-attribute Complete: https://html.spec.whatwg.org/#the-id-attribute Referrer: https://rawgit.com/whatwg/html-differences/master/Overview.html Comment: Allowing "any" content of id attributes is greedy. Sure relax the HTML4 rule they had to be ASCII, but anynthing???? How would you standardize state information passing in fragment identifiers, e.g #key-name=keyvalue, if this perfectly legal id value? Suggest at least reserving some start characters (alphabetic or non ASCII for example Posted from: 14.203.4.38 User agent: Mozilla/5.0 (Windows NT 6.1; rv:32.0) Gecko/20100101 Firefox/32.0
You can't standardise information passing in fragment identifiers, because there might be an ID with the value "key-name=keyvalue" already today, whether it's valid or not.
Though spaces are not allowed so if you don't care about invalid you could use #key-name%20keyvalue or so.
that will actually match id="key-name%20keyvalue" in some browsers (and the spec, modulo bug 26988).
HTML 5 refers conversion of id string values to URL fragments to some "URL Parser" and "URL Serializer" defined in "http://www.w3.org/TR/url/". Another resource is at https://url.spec.whatwg.org/ I was unable to locate in HTML5 or either of these standard a process whereby US-ASCII characters which are not URL-Code points (curly braces and the like), or which have reserved usage under RFC3986, are percent encoded. Both standards appear to assume this occurs before URL component values are passed to them. Hence encoding of version 5 id value strings into URL hash fragment strings is missing a step. So I would amend my original comment to suggest id value strings must be percent encoded for a range or ranges of US-ASCII characters enumerated in the HTML standard. Please include "#" and "?" in the list. Somehow I won't, at this point, go into "!" :D
When would they need to be encoded? I'm not sure I follow.
Oh I see it now - the reserved character concept of the RFCs is not being carried forward. The question underlying this comment was how to separate document references from script data in a URI fragment when both might be present. My conclusion is to suffix any document reference with a line feed ("%0A" in the href string) before appending script data. Short of a redefinition of valid HTML id string values this would appear to delineate the two safely and unambiguously within script. Thank you all for your comments, and question, which have helped me place this issue in context. AFAIAC this case may now be closed.
Marking closed per comment 6.