W3C home > Mailing lists > Public > www-style@w3.org > May 2016

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

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Wed, 4 May 2016 17:53:35 -0400
To: Zack Weinberg <zackw@panix.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Jonas Sicking <jonas@sicking.cc>
Message-ID: <572A6F5F.3030308@mit.edu>
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:

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

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

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

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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:59 UTC