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

On Wed, May 4, 2016 at 12:39 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/4/16 12:17 PM, fantasai 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.

Rereading the thread I *think* what Tab was proposing was a variant on 2:

  2a. Relative URLs are absolutized when they are parsed.  Fragment
URLs are not special-cased.  If you change the base URL, nothing
happens.

>> 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.
>
> I suspect the proposal is option 2.  That seems to be what WebKit/blink
> implement, at least in some cases (they're not terribly consistent about it)
> last I looked at their source...

My gut says 2a is more likely to be web-compatible than any of the
alternatives.  In particular, 2a is the behavior that the author of
the SVG described at
https://bugzilla.mozilla.org/show_bug.cgi?id=652991 seems to have
wanted; as far as I can tell, 1, 2, and 3 would *all* break that SVG.
I may have misunderstood how that works, though.

zw

Received on Wednesday, 4 May 2016 17:02:38 UTC