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

On Wed, May 4, 2016 at 5:19 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

OK, that really profoundly isn't what I thought pushState did; thanks
for setting me straight.

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.  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"?  Maybe "this is a
same-document reference" _should_ be baked into the URL when it's
absolutized?

zw

Received on Wednesday, 4 May 2016 21:45:53 UTC