- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 21 Mar 2016 21:23:43 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
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