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

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.


>> 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.


> ""
> 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.


>> 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:33:35 UTC