W3C home > Mailing lists > Public > www-style@w3.org > November 2012

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Wed, 7 Nov 2012 18:11:27 -0800
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "robert@ocallahan.org" <robert@ocallahan.org>, "www-style@w3.org list" <www-style@w3.org>
Message-ID: <CF211A74-ADEF-4D1E-9275-08FC4915370A@adobe.com>

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

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

Sometimes backwards compatibility matters, even with experimental features.


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

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.


>>> 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 02:11:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC