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:32 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Nov 7, 2012 at 1:26 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> 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.
> 
> ...I know?  My point is that url(image#frag) might also point at a
> paint server, which is an <image>.  But it won't ever be interpreted
> as an image file, like an SVG Stack.

Well, for 'mask' I would follow CSS4 Images. If you want to use paint servers, use element().

> 
> 
>>> 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:
> 
> That doesn't matter.  The rule that we're switching to says that, *at
> parse time*, a value like "url(image#frag)" will be an external
> resource reference, *not* an image file.  You don't need to know what
> type of file it is to make this distinction.  It just tells you which
> code path to go down.

This would be a mayor difference to current behavior. See below.

> 
> 
>> ""
>> 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.
> 
> No, not according to the rule we've come up with.  You can tell,
> before you attempt to load the url, that it will be a resource
> reference of some kind, not an image.
> 
> The resource might end up being a CSS <image> type (if you're pointing
> at a paint server), but that's a different story.

This has nothing to do with the rule we come up. "image.png", "image.png#frag" and even "image#frag" can be PNG images, in which case the fragment doesn't matter at all. You can't make decisions depending on fragments on these files. These are no "resources" in the sense of SVG. These are images where CORS doesn't apply. You can not just say that they are resources now if they have fragments and stop displaying images. As roc said, if Gecko treats something as resource, it doesn't download it at all. Currently Gecko does for images.

Greetings,
Dirk 

> 
> 
>>> 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.
> 
> I will strongly oppose it until I'm convinced there's no way to
> salvage 'mask' being the shorthand.
> 
> ~TJ

Received on Wednesday, 7 November 2012 21:43:43 UTC