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

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?

~TJ

Received on Monday, 21 March 2016 22:48:04 UTC