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 5:24 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Nov 7, 2012, at 4:40 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Nov 7, 2012 at 4:26 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> Well, even if I am saying the same like above again. The WebKit CSS parser does not check for fragments and definitely does not follow a different processing path depending on the fragment. And even with the support for Media fragments (which would just preserve the fragments that WebKit ignores right now), this won't change. The linked file is interpreted as CSS image and not as SVG resource. The WebKit parser can not differ between different file resource at this parsing stage at the moment. The model is still compatible with the simplified proposal so far. WebKit just can't differ between SVG resource and CSS Image on the same property. It needs to be one of both. And for 'mask-image' it would be a CSS Image.
>>
>> You keep citing WebKit's current implementation as if it can never
>> change.
>
> Like you noted, I am citing WebKits current behavior. No one knows if the code base changes in the future. That is why I explicitly don't state it as a general issue, but as the current behavior. Other browser vendors do that as well and this is totally valid.

Given that this entire thread is about new functionality, WebKit's
current behavior will change in some way anyway if we implement this.
That's not an issue.


>> Why?  Is there some technical difficulty, or do you think
>> there is a compat problem?
>
> Partly both. I think that the compat problem is not a big deal. WebKit currently treats url(image.svg#frag) as CSSImageValue, which, in theory, could break content if it should be treated as resource in the future. Again, this seems less likely the case.
>
> From the technical point of view WebKit always treats the input of 'mask-image' as a CSSImage, which is hard to change with WebKits current code base. This is because 'mask-image' uses the same logic as 'background-image'. And creates a CSSImageValue object during parsing.

I understand that -webkit-mask-image is *currently* parsed like
background-image.  The point of this discussion is that it needs to
change, so that it can discriminate between image loads (any use of
the url() function without a hash) and resource loads (any use of the
url() function *with* a hash - may result in a mask or image).

Even if mask-image doesn't change (because we instead handle resources
with a mask-resource property or something), the shorthand needs to be
able to handle this.

(Come to think of it, though, I don't think we can do the
mask-resource idea.  We can't tell at parse time if an external
resource is going to point to a mask or a paint server, so we can't
properly chop up the values into the sub-properties if we have such a
split.  We need to just have mask-image accept both masks and images,
and just ignore the masks if there is more than one layer.)


>> The ENTIRE POINT of this whole discussion was to find a behavior we
>> could settle on that would let us discriminate between resources and
>> images at parse time.  You didn't object to this at any point, and
>> explicitly supported the latest proposal.  Why are you objecting to
>> this now?  Why didn't you object earlier?  What, precisely, is the
>> problem, and why didn't you think it was a problem earlier?
>
> You are just constantly misinterpreting my statements and I am not sure if there is anything I can do about it.
>
> The proposal that we have is consistent with what we can implement in WebKit at the moment. And as you stated before, the switch between resource and image depends on the property. 'background-image' would switch to image, 'fill' would switch to SVG resource. Since 'mask-image' is so close to 'mask-image' it makes more sense to switch to image. That is exactly what WebKit does. But is obviously not compatible with switching to SVG resource in the future.

Not quite.  The "switch" in the proposal is to control what you do
when you see a url() function *containing a url with a hash*.  Some
properties from SVG will treat this as an external resource, the rest
will treat it as an image.  url() functions without a hash are
unambiguous - they're always images.

~TJ

Received on Thursday, 8 November 2012 01:50:42 UTC