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 6:11 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Nov 7, 2012, at 5:49 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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.
>
> Sometimes backwards compatibility matters, even with experimental features.
>
> http://lists.webkit.org/pipermail/webkit-dev/2012-August/022120.html

Oh!  If you're just worried about back-compat with the -webkit-
prefixed version specifically, that's fine.  I don't care about that.
We can just prefix the new stuff with -webkit2- or something if
necessary.  (It looks kinda silly, but we've come very close to doing
this before.)


>> 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.
>
> We are going into circles. I tried to explain the CSS parser behavior of WebKit multiple times. And I explained why 'mask-resource' doesn't help us before. I tried to explain why I don't think that 'mask-image' is the proper solution from a logical point. I am fine with keeping the issue in the spec. But still want to come to a solution that all browser can implement.

I understand WebKit's *current* CSS parser behavior for -webkit-mask-image.

What's unclear is whether you think there is a *fundamental* problem
with the current suggested approach (where mask-image distinguishes
between urls-as-images and urls-as-resources based on the presence of
a hash), or if you're just complaining that it might break the current
prefixed implementation of the property that we have.

~TJ

Received on Thursday, 8 November 2012 02:24:06 UTC