W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2012

Re: [css-masking] Paint server as mask is redundant

From: Dirk Schulze <dschulze@adobe.com>
Date: Tue, 25 Sep 2012 19:17:35 -0700
To: Brian Birtles <bbirtles@mozilla.com>
CC: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <2ECCE1C2-BE3F-4DFF-BE3B-EB31F196F3BD@adobe.com>

On Sep 25, 2012, at 7:10 PM, "Brian Birtles" <bbirtles@mozilla.com> wrote:

> (2012/09/25 22:24), Dirk Schulze wrote:
>> A URL on a 'mask' property can also reference a paint server [1]. This seems to be redundant to the functionality of the CSS4 Images 'element()' function[2]. I would like to remove this requirement from CSS Masking. Any objections?
> What do we do with the <child-selector> value (e.g. 
> select(linearGradient)) though?
> Can these still target paint server elements? I guess not? And if not, I 
> wonder if we need it, or if 'child' is enough?

To be honest, I didn't thought about using child() or select() as a possibility to select pain servers. At least not for masking. My understanding was, that we want to have it as general approach for SVG attributes like fill and stroke.

However, IMO they are still on risc. If it turns out that they don't get implemented in time, I would like to move the functions to the next level of CSS Masking.


> To give some examples. Currently you can do the following:
> <g mask="select(linearGradient)">
>   <linearGradient>
>     ...
>   </linearGradient>
>   <path ... />
>   <path ... />
> </g>
> If we make <child-selector> only valid for mask elements then you'd need 
> to wrap the <linearGradient> in a <mask> element. Probably that's ok. 
> But then you wouldn't need select() just,
> <g mask="child">
>   <mask>
>     <linearGradient>
>       ...
>     </linearGradient>
>   </mask>
>   <path ... />
>   <path ... />
> </g>
> The only cases where you'd need the select() syntax in that case is if 
> you have multiple <mask> element children than you want to choose 
> between which I suspect is uncommon.
> Best regards,
> Brian
Received on Wednesday, 26 September 2012 02:18:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:42 UTC