W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 8 Dec 2015 16:52:08 -0800
Message-ID: <CAAWBYDArBwX__4pLf5Da66C0qUTMAFKB=3z4GevOF_O2RxPEsQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 9 December 2015 00:52:56 UTC