W3C home > Mailing lists > Public > public-html@w3.org > June 2008

Percent-encoded fragment identfiers and id matching - (was: Fragment Identifiers for HTML5)

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Sun, 22 Jun 2008 09:42:18 -0400
Message-ID: <6b9c91b20806220642j30d2ce92m4521d8dfca8d49a1@mail.gmail.com>
To: public-html@w3.org

Consider the following:

<!DOCTYPE html>
        <meta charset="utf-8">
            div {
                position: absolute;
                top: 1500px;
        <div id="&#8730; 45">Destination</div>
        <p><a href="#&#8730; 45">Test 1</a></p>
        <p><a href="#%E2%88%9A%2045">Test 2</a></p>
        <p><a href="#%E2%88%9A 45">Test 3</a></p>
        <p><a href="#&#8730; 45">Test 4</a></p>

In Firefox and Safari, the fragids for Test 1, Test 2, Test 3 and Test
4 all match the id for the Destination div. In Opera and IE, they do

In short, Firefox and Safari support percent-encoded fragment
identifiers and decode them before trying to find a match (even for
manual input in the address field). Further, Firefox and Safari make
the navigation to the destination div work when there's a match even
if the id value contains spaces or non-ascii charactesr like &#8730;.

How Firefox and Safari *handle* these situations makes sense to me.
Whether you're technically supposed to encode the fragid data in the
URI or not, I expect it to be encoded. This also fits well with how
browsers return a resolved and normalized value for .href. And, even
though the id value might not validate, Firefox and Safari have no
problem making the navigation work if the fragid data and the id value

Do you feel that behavior is ideal for this situation?

Or, do you feel that navigation should be broken in Safari and Firefox
in these situations?

Does anything explain what should happen in these situations?

I have the same type of concern for usemap="#percent-encoded_value" matching.

Received on Sunday, 22 June 2008 13:42:54 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:32 UTC