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

On 03/21/2016 06:47 PM, Tab Atkins Jr. wrote:
> tl;dr: Should something like "fill: url(#frag);" depend on the base
> url of the document, such that a <base> tag or a pushState() call can
> change what it refers to?  Or should it be defined as a local
> reference always?
>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=652991> is a bug on
> Mozilla complaining about their handling of url(#frag) situations in
> SVG.  Specifically, Moz appears to follow the spec, and canonicalizes
> the URL to an absolute URL against the document's base url.  This
> works fine as long as the base url is the same as what was initially
> there; if you change the base url somehow, either through <base> or
> pushState(), it breaks.  (Check the bug for details on the breakage.)
> Other browsers have undocumented spec-divergent behavior to some
> degree, that prevents them from having this annoying behavior.
>
> Anne suggests, and I agree, that url(#frag) has a definite intended
> semantic - it's meant to be a reference to something page-local.
> We're currently handling that in a roundabout way, by absolutizing the
> URL and then comparing URLs with the page; this has knock-on effects
> that we're dealing with now.
>
> So, the suggestion is that we handle/enforce that semantic directly,
> whenever we see a "url(#frag)" function.  There are two possibilities:
>
> 1. During parsing, if the url() is a fragment, set a "local reference"
> flag on it.  Handle this specially in the processing model, so it
> doesn't absolutize, and serializes appropriately.
>
> 2. At some point before absolutizing, notice that this is a fragment
> url, and transform it into a dedicated local reference function, like
> document(#foo) or something.
>
> The former is a little bit more magic; the latter is somewhat more
> likely to have back-compat issues if people are checking the
> serialization.
>
> Thoughts?

I'm.. not 100% clear on what's going on here, but, isn't this handled
by the fact that CSS is stateless? It's only a problem if the computed
value is cached over the base URL change--and that's a caching problem,
not a spec problem.

Though possibly worth pointing out in a note.

Wrt perf concerns, I somehow doubt there are enough computed URLs and
enough frequency of the document base URL changing for updating said
cache to be a huge problem.

~fantasai

Received on Tuesday, 22 March 2016 01:24:11 UTC