HTML5 id attributes containing RFC2396 encoded %yx URL not addressable by URL

RESOLVED INVALID

Status

()

Core
History: Global
RESOLVED INVALID
6 years ago
3 years ago

People

(Reporter: Léa Gris, Unassigned)

Tracking

({html5})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

6 years ago
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
(Reporter)

Updated

6 years ago
Component: Location Bar → General
Keywords: html5
Summary: UTF-8 RFC2396 encoded URL and id not working → HTML5 id attributes containing RFC2396 encoded %yxURL not addressable by URL
(Reporter)

Updated

6 years ago
Summary: HTML5 id attributes containing RFC2396 encoded %yxURL not addressable by URL → HTML5 id attributes containing RFC2396 encoded %yx URL not addressable by URL
(Reporter)

Comment 1

6 years ago
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.

Updated

6 years ago
Component: General → History: Global
Product: Firefox → Core
QA Contact: location.bar → history.global
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

6 years ago
Thanks for the clarification.
Opened Webkit bug#56733 https://bugs.webkit.org/show_bug.cgi?id=56733

Updated

6 years ago
Duplicate of this bug: 668473
You need to log in before you can comment on or make changes to this bug.