Re: fragid navigation and pct-encoded

On Wed, 18 Feb 2009, Michael A. Puls II wrote:
> On Wed, 18 Feb 2009 00:30:25 -0500, Ian Hickson <ian@hixie.ch> wrote:
> 
> > Given:
> >   <a href="#a a">...</a>
> 
> FWIW, here's how I expect it to work (whether it does or not) and makes 
> the most sense to me:
> 
> <a href="#a a">...</a> gets normalized to <a href="#a%20a">...</a> 
> (author should have used "#a%20a" in the first place and not have left 
> the space unencoded). This makes the fragid uri component "a%20a". Then, 
> to get a string from that, "a%20a" needs to be percent-decoded to "a a". 
> Then, it should match name="a a" or id="a a".
> 
> If you want to match name="a%20a" or id="a%20a", you'd need <a 
> href="#a%2520a">...</a>.
> 
> I think of it the same way as if a fragid hvalue in a query string were 
> to match @name and @id. For example, href="?fragid=a a" would be 
> normalized to href="fragid=a%20a". Then, if you wanted to get the fragid 
> value that the percent-encoded fragid hvalue represents, you'd have to 
> percent-decode "a%20a" to "a a" first and then look for a match.

I agree with you in principle, but in practice we are required by legacy 
content to have a mechanism which will have this:

   <a href="#%3F">...</a>

...match:

   <a name="%3F"></a>

The question is how to achieve this while staying as close as possible to 
existing specifications and sanity.

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

Received on Wednesday, 18 February 2009 06:52:24 UTC