Re: [css-masking] 'mask' with resource and image references (was: [css4-images] support for SVG Paint Servers without element())

On Nov 5, 2012, at 5:21 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Mon, Nov 5, 2012 at 4:52 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> On Oct 26, 2012, at 6:14 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> On Oct 23, 2012, at 2:17 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>>>> The code paths to load an SVG document as an image and an SVG document to provide an external resource such as a paint server are quite different, in Gecko at least. We need to know when we start loading the document which situation we're in. With your syntax, we can't know until the document is loaded. We use the presence of element() to signal that we're in the external resource situation.
>>> 
>>> As discussed in the previous thread, the 'mask' property[1] does reference the mask resource as well as images, which would lead into the same problem for Gecko.
>>> 
>>> I can't say if WebKit will run into the same situation as well. Maybe. The 'mask' property with image processing is prefixed on WebKit. So WebKit will continue to support -webkit-mask as it does right now. But the unprefixed property may do something different.
>>> 
>>> A solution can be that we split the 'mask' property again. The 'mask' property will use resource referencing and another property, with a different name, will be the shorthand for the 'mask-image' properties. I am unsure how this property could be named.
>>> 
>>> I added an issue to the spec for now and am open for suggestions.
>> 
>> We seem to have a consensus when we treat a SVG fragment as SVG resource (reference to e.g <mask>) and when as an image. This consensus still needs discussion on the WGs.
>> 
>> However, this consensus might not fully solve the problem on CSS Masking:
>> 
>> mask: url(image.svg#resource);
>> 
>> According to the compromise, the SVG fragment is interpreted as SVG resource. This does not necessarily help the CSS parser to decide if the 'mask' property is interpreted as 'mask-image', or as SVG mask - at least on WebKit. The '-webkit-mask' property gets parsed the same way as the 'background' property. I am not sure if WebKit can identify the resource as SVG file that early in the parsing process. I need to verify that on WebKit but would like to hear feedback from other browser vendors.
> 
> This doesn't seem problematic.  For it to be an issue, you'd have to
> assume that people already commonly use SVG Stacks for mask-image.  If
> they don't (which I suspect is true - it appears that Stacks are
> commonly just used directly in HTML elements), then we can just use
> roc's suggested rules, which is that mask-image interprets a link with
> a fragment to be an external reference (because mask-image will be on
> the list of SVG properties that do this).
> 
>> At the end, the easiest way still seems to add a new short hand property for 'mask-image' and separate the 'mask' property for "CSS masking" introduced by WebKit from SVG masking.
> 
> I don't understand what this means.  Could you give an example?

[DS] I am saying that even the compromise forces the CSS parser not only to parse the URL, but also to interpret the resource during parsing and take the result of this interpretation into account for continuing the parsing process. Example:

mask: url(image.svg#id);

The URL needs to be checked if valid. In this case it needs o be checked if it is an SVG image. If it is, use SVG masking (with <mask>).

Second example:

mask: url(image.svg#id), url(image2.svg#id);

Both references should be treated as SVG resources (references to SVG mask). But in this case the construct is parsed as an shorthand for 'mask-image'. All that makes parsing more difficult. And in case of the interpretation, may extend current browsers (note that image.xml can be an SVG image as well).

If that is to complicated for browsers, I would be in favor for adding a new CSS property for the shorthand of mask-image.

'mask' would just be used for <mask> references, 'new-mask' would be the new shorthand for 'mask-image' (don't take the 'new' prefix seriously).

Greetings
Dirk

> 
> ~TJ

Received on Tuesday, 6 November 2012 01:56:55 UTC