Re: fragid navigation and pct-encoded

On Thu, 4 Sep 2008, Anne van Kesteren wrote:
> 
> Apparently there are some differences between browsers in the handling 
> of percent escaped characters in fragment identifiers. I made a few 
> tests to figure out the different behavior:
> 
>   http://tc.labs.opera.com/html/navigation/fragids/
> 
> I was able to test in Opera 9.5, Firefox 3.0, and Internet Explorer 6.0. 
> Results:
> 
> IE does not handle pct-encoded in fragment which is in violation of RFC 
> 3986. It does nothing special with either the name or id attributes; 
> simple literal matching.
> 
> Firefox does handle pct-encoded in fragment. It also handles pct-encoded 
> in the name attribute. It effectively performs pct-encoded handling in 
> fragment and name attributes and after that performs literal matching. 
> Thus a fragment of ? and a name attribute of %3FC match and vice versa. 
> Likewise, a fragment of %253F does not match a name attribute of %3FC. 
> The id attribute is not affected by pct-encoded handling. So a fragment 
> of ? does not match an id attribute of %3F.
> 
> Opera does handle pct-encoded in fragment. It does not have special 
> handling of attributes. This is the behavior prescribed by HTML5 but 
> breaks sites. Eg,
> 
>   http://www.readynas.com/forum/faq.php
> 
> The test suite assumes Firefox is correct as that seems the most 
> "sensible" behavior if you want to be compliant with RFC 3986 and 
> compatible with the Web. I suggest we change HTML5 to perform 
> pct-encoded handling for name attributes. I have not checked whether 
> this affects the usemap attribute.

I have updated the spec, but I have not used the recommendation above.

Since Firefox was the only browser I could find that did the complicated 
and potentially slow unescaping of all name="" attributes, I was reluctant 
to introduce this new, somewhat surprising, behaviour. (New in terms of 
not being justified by any existing spec.)

Instead, I have made HTML5 require id="" attributes to be matched after 
decoding the fragment identifier, and name="" attributes to be matched 
before decoding the fragment identifier.

This doesn't quite match any user agent's current behaviour but seems to 
be a simple compromise between the various existing behaviours.

If any browser vendor is not willing to implement this, please let me 
know.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 18 February 2009 03:24:53 UTC