User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110319 Firefox/4.0b13pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110319 Firefox/4.0b13pre When an html element id contains UTF-8 RFC2396 encoded chars, it can not be properly targeted in a hrefs like: <a href="#broken+with+RFC2396+URL+%E9l%E9ment"> <section id="broken+with+RFC2396+URL+%E9l%E9ment"> Work as intended with Opera and Webkit Reproducible: Always Steps to Reproduce: 1.load the mentioned URL 2.click first working link 3.click second not working link Actual Results: The link containing UTF-8 encoded "élément" is not targeted Expected Results: Should properly targed
The id attribute and IDL as commented in the W3C HTML5 working draft: http://dev.w3.org/html5/spec/common-dom-interfaces.html#reflect "If a reflecting IDL attribute is a DOMString attribute whose content attribute is defined to contain a URL, then on getting, the IDL attribute must resolve the value of the content attribute relative to the element and return the resulting absolute URL if that was successful, or the empty string otherwise; and on setting, must set the content attribute to the specified literal value. If the content attribute is absent, the IDL attribute must return the default value, if the content attribute has one, or else the empty string." So, if the id attribute is to be used as document internal reference a href="#…" then (IMHO) it may constitute a URL or URI and support RFC2396 %xy encoded chars. As of stated in "18.104.22.168 The id attribute" of the HTML5 working draft: http://dev.w3.org/html5/spec/elements.html#the-id-attribute the processing of "space characters" has contradictory mentions as: 1 - "The value must not contain any space characters." and later: 2 - "…user agents must associate the element with the given value (exactly, including any _space characters_) for the purposes of ID matching…" As reference implementations: Webkit (Chrome) actually accept id attributes containing RFC2396 %xy encoded chars. Opera 11 does not and neither the older khtml.
1) This has nothing to do with global history. 2) This sounds like a bug in Webkit. The algorithm for navigating to a fragment identifier is at http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-the-fragment-identifier and is very clear: the part in the href gets %-escaped decoded into UTF-8, but the ID does NOT. Please do report this bug to the Webkit folks.