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

On Thu, May 5, 2016 at 2:34 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 05/05/2016 12:57 PM, Tab Atkins Jr. wrote:
>> On Wed, May 4, 2016 at 9:17 AM, fantasai <fantasai.lists@inkedblade.net>
>> wrote:
>>> 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 seems to violate bzbarsky's statement in
> https://lists.w3.org/Archives/Public/www-style/2016May/0040.html
> “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.”
>
> If we take that as the guiding principle, then any relative URLs,
> be then in CSS url() notations, in <a href="">, in <img src="">,
> should be absolutized against the current base URL, not the base
> URL at the time the document was loaded.

Right, but no browser does that, and doing so would break pages today,
so it's not going to happen.  On the other hand, while frag urls in
this situation are relatively rarer today, it looks like people *do*
assume behavior like what you describe, and my suggestion narrowly
fixes this case in a natural way.

~TJ

Received on Thursday, 5 May 2016 22:08:28 UTC