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

On Wed, May 4, 2016 at 9:17 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 04/28/2016 07:52 PM, Tab Atkins Jr. wrote in
> <https://lists.w3.org/Archives/Public/www-style/2016Apr/0454.html>:
>>
>> > ... [ https://bugzilla.mozilla.org/show_bug.cgi?id=652991 ] ...
>> Ping! I'm going to make this change if no one objects.
>
>
> I don't understand what change you're planning to make.

This is exactly what you said in response to my first email in this
thread, and I explained myself further. :/  The two options in my
first email should be totally clear in terms of suggested changes?
I'm suggesting option #1 from that email, fwiw, as it's
minimum-change.

> Imho there are three options, based on this thread
>
>   1. Relative URLs stay relative. If you change the base URL,
>      we resolve against that new base URL, which may or may
>      not result in a change in resource depending on whether
>      it absolutizes to something new or not.
>
>   2. Relative URLs are absolutized. If you change the base URL,
>      nothing happens. Unless it's a fragment URL, in which case
>      we handle those specially and don't absolutize them so they
>      stay relative.
>
>   3. Relative URLs are absolutized. If you change the base URL,
>      nothing happens. Unless it's a fragment URL, in which case
>      instead of absolutizing them, we turn them into a special
>      relative-fragment function, which stays relative.
>
> Imho options #2 and #3 are silly and weird. I'm happy with #1.
> But I have no idea what you're proposing or why.

Repeating myself from earlier in the thread:

Browsers do not today eagerly update resource urls when they're
specified as relative and the base URL changes.  That is, if I'm on
https://example.com and I have a resource link like "#foo", it'll
initially absolutize to "https://example.com#foo", and if I then
change the base url (by inserting/mutating a <base>, or calling
pushState()) to https://neworigin.example.com, the url is *still*
"https://example.com#foo".  I put together some testcases showing this
behavior in browsers for <img>, inline style attr, and stylesheets at
<http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4017>.
Firefox and Chrome agree with what I just outlined; Edge does
something a little weird.

This behavior is *not* a bug - it's the *desired* behavior when your
relative URL is something like, say, "images/foo.jpg".  If you
pushState() to a url that changes more than just the last path
segment, re-absolutizing the url would probably break that image
reference.  (Any *new* images you put in will be relative to the new
base url, but hey, compromises.)  Instead, we keep the url as it is,
so whenever we happen to make the request, it fetches the intended
url.

This happens to be bad for fragment refs, tho, because when we get
around to fetching them, we check them against the page's url to see
if they're a local ref or not.  If the page url has changed, but the
ref's url hasn't be reabsolutized, it will look like it's a
cross-document ref instead.

So the proposal is to recognize fragment-local urls in url() (that is,
relatively urls containing *only* a fragment ref), and set an internal
flag marking them as local.  Then we always treat them as a local ref
to that fragment, rather than checking their absolutized form against
the page's url.  (Other urls continue to act as they do today,
unchanged.)

~TJ

Received on Thursday, 5 May 2016 20:25:52 UTC