Re: [css-masking] when to interpret 'mask-image' as SVG mask vs. image?

> On Dec 8, 2015, at 4:52 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> 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.

At one point WebKit had a behavior similar to Blink’s, but we reverted it because
it caused a bunch of problems (some related to the "not friendly to image-loading
pipelines in browsers” issues you imply above).

I would prefer the explicit nature of (1).

Simon

Received on Friday, 8 January 2016 23:03:21 UTC