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

Consider the following:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <title></title>
        <style>
            div {
                position: absolute;
                top: 1500px;
            }
        </style>
    </head>
    <body>
        <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>
    </body>
</html>

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
not.

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
match.

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.

-- 
Michael

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