Re: fragid navigation and pct-encoded

On Wed, 18 Feb 2009, Michael A. Puls II wrote:
> > 
> > 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>
> 
> So, you're saying it needs to be something like:
> 
> @id matches with the percent-decoded (according to document encoding) 
> value that the percent-encoded fragid URI component represents.

I'm not aware of any particular legacy content requirements posed by id="" 
matching. (In the current spec text I went the route of trying to Do The 
Right Thing as much as possible for id="" matching.)


> @name on HTMLAnchorElement matches with the literal, non-normalized, as 
> the author specified, fragid URI component substring.

Well it doesn't have to be exactly that, though that's what the spec says 
now. There are several ways of getting the effect we need, e.g. both what 
IE does, what Firefox does, and what the spec currently requires (which 
are all slightly different from each other) would do.


> If so, implementing that in JS for clicking links (need something for 
> address field too) seems like you'd have to use .href and parse for the 
> fragid hvalue and decode for @id matching and getAttribute("href") and 
> parse for the fragid for @name matching. (assuming getAttribute("href") 
> in the browser returns the href as authored)

I'm not sure what you mean here. Are you proposing a particular change to 
what the spec says?

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

Received on Wednesday, 18 February 2009 08:03:55 UTC