Re: [css-values] url(#frag) handling when base url changes

On 5/4/16 5:45 PM, Zack Weinberg wrote:
> In that case, though, I don't understand what _breaks_.  For this to
> be a reasonable thing for a page to do, the fragment reference needs
> to be valid in all three of: the originally loaded page, the page
> after JS has messed with it, and the page that would be loaded if you
> pasted the new URL into the address bar.

Sure.  So say all the pages involved (old page, old page after 
pushstate, new url) have this somewhere in the DOM:

   <svg>
     <pattern id="foo">stuff</pattern>
   </svg>

   <svg>
     <rect style="fill: url(#foo)"/>
   </svg>

If the url is converted to an absolute one, it becomes 
"http://foo.org/a#foo" while the page URL is "http://foo.org/b#foo".  So 
it's no longer a same-document reference, and the browser is supposed 
to... well, browsers differ, but at least Gecko will load 
"http://foo.org/a" and if it's an SVG document per the MIME type parse 
it and look for the thing with id="foo" in there.  But since the type is 
going to be "text/html" in this case that sure doesn't work.

> So why does it _matter_
> whether the browser interprets the fragment reference relative to the
> old URL or the new one?  I guess this is what you meant about "whether
> or not it's a same-document reference"?

Right.  In the "same-document reference" case instead of loading a 
separate document and trying to parse it, UAs just getElementById in the 
current document.

> Maybe "this is a same-document reference" _should_ be baked into the URL when it's
> absolutized?

That is one possible approach to this, yes...

-Boris

Received on Wednesday, 4 May 2016 22:13:43 UTC