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

On Wed, May 4, 2016 at 1:27 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/4/16 1:02 PM, Zack Weinberg wrote:
>>
>>    2a. Relative URLs are absolutized when they are parsed.  Fragment
>> URLs are not special-cased.  If you change the base URL, nothing
>> happens.
>
> This is the current Gecko behavior, as far as the actual URIs are concerned.
>
> The issue is that what is done with the absolute URI later on depends on
> whether it's a "same-document reference" or not, and _that_ is not baked
> into the absolute URI, obviously.  So UAs have to detect it somehow, which
> is where the base URI may matter.

... this doesn't make any sense to me, and maybe this means I don't
understand what the actual _problem_ is here.

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, but, critically,
has _not_ changed the document itself. 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.

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

zw

Received on Wednesday, 4 May 2016 21:12:20 UTC