- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 8 Dec 2015 16:52:08 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: "public-fx@w3.org" <public-fx@w3.org>
On Tue, Dec 8, 2015 at 3:30 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Thu, Nov 5, 2015 at 6:16 AM, L. David Baron <dbaron@dbaron.org> wrote: >> https://drafts.fxtf.org/css-masking-1/#the-mask-image defines a >> property that can use the url() function to link to either an SVG >> mask element or to an image. >> >> I don't see where it specifies how to tell which one of these two to >> process a link as. >> >> This ought to be defined clearly. >> >> (I have vague memories of it being discussed in a working group >> meeting, but I couldn't find the minutes.) > > This was discussed back when we were talking about referencing SVG > paint servers in CSS. > > There wasn't a firm conclusion, iirc. There were two serious > suggestions that I recall: > > 1. Let url() continue to refer to the document as an image, with a > hash just activating :target semantics. Let element() take a url() > with a hash, and definitely refer to an element within that document. > > 2. Let url() do both. When loading a url() with a hash that returns > an SVG document, check if the hash points to a paint server or similar > non-rendered but referencable thing in SVG, such as a <mask>. If so, > interpret it as the appropriate thing. Otherwise, interpret it as an > image. > > IIRC, the second was preferable, but was not friendly to image-loading > pipelines in browsers, which need to know at load time whether to load > something "as an image" or "as a document". I *think* roc had some > opinions about it not being too bad, but I don't recall it well. Okay, found the thread. It starts in Oct 2012 at <https://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html>. The decision there was: 1. If the url() function does not have a hash, load it as an image. 2. If the url() function has a hash, and is an SVG document, load it as a resource. 3. The image() function *always* loads its url as an image. (You have to use this to get Media Fragments to work on SVG images.) That said, this never made it into a spec (mostly my fault, I think). Implementations are mixed: * Firefox always interprets it as an image * Blink currently always treats it as an image *and ignores the hash entirely*, but *just* got a patch in (check recent Canary) that honors the hash when treating it as an image. * Can't easily check, but I suspect WebKit is the same as our old implementation - always treat it as an image, ignore the hash entirely. * Edge always interprets it as an image. You can test at <http://www.xanthir.com/etc/bugs/svg-target/>. So, if we take current implementations as gospel, this means we probably need to do the alternate proposal from that thread, which is: 1. If the url() function does not have a hash, load it as an image. 2. If the url() function has a hash, load it as an image or a resource depending on the property. (Small list of SVG properties that treat it as a resource, everything else treats it as an image.) 3. The image() function *always* loads it as an image. 4. The element() function *always* loads it as a resource. ~TJ
Received on Wednesday, 9 December 2015 00:52:56 UTC