Last Comment Bug 643275 - HTML5 id attributes containing RFC2396 encoded %yx URL not addressable by URL
: HTML5 id attributes containing RFC2396 encoded %yx URL not addressable by URL
Status: RESOLVED INVALID
: html5
Product: Core
Classification: Components
Component: History: Global (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.noiraude.net/bug/urlencode...
: 668473 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-20 07:13 PDT by Léa Gris
Modified: 2014-10-17 12:46 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Léa Gris 2011-03-20 07:13:51 PDT
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
Comment 1 Léa Gris 2011-03-20 09:48:27 PDT
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 "3.2.3.1 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.
Comment 2 Boris Zbarsky [:bz] 2011-03-20 19:09:24 PDT
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.
Comment 3 Léa Gris 2011-03-20 22:49:30 PDT
Thanks for the clarification.
Opened Webkit bug#56733 https://bugs.webkit.org/show_bug.cgi?id=56733
Comment 4 j.j. 2011-06-30 08:24:14 PDT
*** Bug 668473 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.