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

On Nov 7, 2012, at 1:08 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Nov 7, 2012 at 12:45 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> On Nov 7, 2012, at 10:43 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> So, 'mask-image' needs to have its grammar revised to take this into
>>> account, so that it can take mask references as well.
>> 
>> This would be the consequence, but wouldn't help IMO.
>> 
>> mask-image: url(image#frag);
>> 
>> It would be unclear until the processing, if this is an SVG resource or an image. However, the syntax would be valid in both cases. The problem for WebKit is, that we already assume that this will be an CSS Image and already start creating an CSSImage resource. This is incompatible with an SVG resource (because of various reasons roc already mentioned). That's why this is not an option for WebKit right now.
> 
> Let's be precise here.  It's unclear at parse time whether you're
> pointing at a <mask> element or some other paint server element like
> <linearGradient>.

I think you mix up some things. I am not talking about paint servers at all. I am just talking about the <mask> element for reference.

> You *do* know, at parse time, that it won't be
> loading the SVG as an image, because 'mask' is on the list of
> properties that default frag-urls to being a resource reference rather
> than an image.

You do not know that it actually is an SVG file at all. This is what I described in a previous mail:

""
And even the fragment itself is not a good identifier, url(image.png#frag) will be an image as well. And the file ending itself can not be trusted. The file doesn't need to have a file ending at all. Therefore, the fragment alone can not be used to clarify if it is a resource or an image. That is what I meant in the mail before. The CSS Parser would need extra information about the file then just the URL.
""

You would need to check the URL itself (e.g check mime type) and can't just rely on the parsing output. That is actually my point.

> 
> Now, a paint server *is* a CSS <image> value, but our existing code
> obviously doesn't do anything special with this yet.  (Our existing
> code for mask-image doesn't implement roc's rule, so it'll currently
> try and interpret it as an SVG image, likely an SVG Stack.)  Once we
> switch over, though, we should be fine - we can generate a mask from
> the paint server (turned into an image) or the <mask> element equally
> well at that point, right?

See comment above.

> 
> 
>>> Alternately, we
>>> need an additional property which takes a mask ref, and overrides
>>> mask-image if specified (like list-style-type and list-style-image -
>>> the latter wins if it's not none).
>> 
>> This additional property would make sense from the logical point of view and seem to solve the issue described above, but doesn't help at all on the short hand:
>> 
>> mask: url(image#frag);
>> 
>> Is that 'mask-image'? 'mask-reference'? You can't say until you load the resource. So you can't distinguish between the both during the pure parsing process. This seems to be worst IMO.
>> 
>> Another name for the shorthand for the 'mask-*' properties on the other hand would work for all browsers.
> 
> Having 'mask' be a longhand property and some 'mask-*' property be the
> shorthand would be *terrible* for usability.  We should avoid this if
> there is any possibility of solving this in a different way.

It is a reasonable solution IMO.

Greetings,
Dirk

> 
> ~TJ

Received on Wednesday, 7 November 2012 21:26:52 UTC