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

On 5/4/16 5:11 PM, Zack Weinberg wrote:
> The scenario we're concerned with, I thought, is: there's a CSS
> reference to a fragment of the current document. A JS operation has
> changed the user-visible URL of the current document

No, it's changed the URL of the current document, period.  Not just the 
user-visible one.  It's changed what location.href says, it's changed 
what document.URL says, it's changed what the base URI is, it's changed 
what URL gets sent as referrer for subresource loads.  You name it, it 
got changed.

Oh, and the way it's _supposed_ to work is that if you were to load this 
new URL to start with by pasting it in your URL bar you would get the 
same document.

So for clarity, say we have the original URL being http://foo.org/a and 
the new URL is http://foo.org/b.  If after the change someone appends a 
node to the document that has style="fill: 
url(http://foo.org/b#something)" that needs to be treated as a 
same-document reference (c.f. the "it needs to behave as if you had 
loaded that URL to start with" thing).

The question is what should happen with nodes that have style="fill: 
url(#something)", whether appended before or after the change.

> The browser therefore _thinks_ the reference points to a document whose DOM is not available, and for
> some reason (perhaps having to do with not wanting SVG images to be
> able to trigger additional network requests?) it doesn't try to load
> that document, it just treats the referenced material as unavailable.

Or it loads it and the result is not actually SVG so fails to parse. 
Either way you get fail.

> If that's the scenario, then absolutizing the URL at load time should
> mean that it continues to be recognizable as a reference to the
> current document even though the apparent URL of the current document
> has changed.  Because the _true_ URL of the current document is also
> baked in at load time.  Isn't it?

No.

> (I can't imagine how it can't be;
> otherwise tons of other stuff would break, starting with the
> reload-this-page button.)

Reload-this-page after pushstate reloads the post-pushstate URL, not the 
pre-pushstate one.  It's really meant to be just like a navigation but 
without actually hitting the server.

-Boris

Received on Wednesday, 4 May 2016 21:27:26 UTC