Re: [css-masking] 'mask: none' clear all masking operations

Hi,

We didn't get to an agreement on the CSS WG call how to handle the 'mask' shorthand property. I think in general we did not disagree on the structure:

mask
 +-- mask-layer
 |    +--mask-layer-image
 |    +--mask-layer-position
 |    +--mask-layer-repeat
 |    etc.
 +-- mask-element
 +-- mask-box
      +--mask-box-source
      +--mask-box-slice
      +--mask-box-repeat
      etc.

But CSS WG members didn't like that 'mask' can just reference SVG elements. Here the problem why the initial proposal didn't allow <mask-layer>:

Both, mask-element and mask-layer-image can take a url(). However, while it references an <mask> element for the former, it references an CSS image for the later. There are some security considerations if one loads an SVG resource or CSS image, which leads to different fetching algorithms. Therefore, the CSS Parser must detect on parse time if we load an SVG resource or an CSS Image. Two solution that are agreed on in the past:

1) Parse the URI string and check for hashes. If there is an hash, assume it is an SVG resource, otherwise an CSS Image.
- This was quite unpopular for web authors and many complained on Twitter and some mailing lists.
2) Don't allow either <mask-element> or <mask-layer> on the shorthand. Since 'mask' is in an recommendation and uses <mask-element> this one was the natural choice.

I see two more ways to allow <mask-element> and <mask-layer> as values for the 'mask' shorthand:

3) Don't allow url() as CSS Image for 'mask-layer'
- This would mean that you can not use url() for mask-layer-image anymore, which a lot of authors are still used to. Furthermore, image() (the alternative) is not supported in browsers yet.

4) Add keywords that allow to differ between the masking operations:

mask: [<mask-element> && layer <mask-layer> && box <mask-box>] | none

As you see, this could allow 'mask' to set all kind of masking operations, not just <mask-element> and <mask-layer> but also <mask-box>

Greetings,
Dirk



On Jun 26, 2013, at 6:01 PM, Dirk Schulze <dschulze@adobe.com> wrote:

> 
> On Jun 26, 2013, at 4:37 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
>> On Wed, Jun 26, 2013 at 3:19 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>>> On 06/26/2013 12:57 PM, Dirk Schulze wrote:
>>>> 
>>>> 
>>>> Thinking about your proposal more, I actually take my response back
>>>> and claim the opposite :). What about the following structure:
>>>> 
>>>> mask
>>>>  +-- mask-layers
>>>>  |    +--mask-layer-image
>>>>  |    +--mask-layer-position
>>>>  |    +--mask-layer-repeat
>>>>  |    etc.
>>>>  +-- mask-element
>>>>  +-- mask-box
>>>>       +--mask-box-source
>>>>       +--mask-box-slice
>>>>       +--mask-box-repeat
>>>>       etc.
>>>> 
>>>> mask-element: <url> [alpha | luminance]? | none
>>>> 
>>>> mask: <mask-element>
>>>> 
>>>> * mask-element is separated of mask-layers.
>>>> * mask-layer, mask-box just reference CSS Images
>>>> * mask shorthand overrides all properties of mask-layer, mask-element,
>>>> mask-box
>>>> * mask syntax does the same as mask-element
>>>> 
>>>> Would that be reasonable?
>>> 
>>> Yes, it's totally reasonable.
>>> 
>>> However, I am wondering if we can allow a bit more into the shorthand,
>>> e.g.
>>> 
>>> mask: <mask-element> | <mask-layer>;
>>> 
>>> with the added provision that a <url> represents <mask-element>
>>> and other forms of <image> represent a mask-layer. (I'm not 100%
>>> sure that works, but maybe it works.)
>> 
>> Yes, it's possible, though a bit nasty.  In the prose, you'd just have
>> to define that for the purposes of this property, <url> isn't part of
>> the <image> type that <'mask-layer'> accepts, so that it has to fall
>> into the <'mask-element'> bucket.
> 
> Either that, or use the hack that we resolved on before: decide on the fragment identifier. If the URI has a fragment identifier if the referenced resource is an SVG resource (reference to a <mask> element, if not it is an CSS image.
> 
>> 
>>> I still don't understand, btw, why we can't use SVG masks in the
>>> mask-layers feature?
>> 
>> It's troublesome for implementations if they can't tell at parse-time
>> whether a link is meant to be an internal reference or an image.
>> There are substantially different and separate loading paths for the
>> two possibilities.
> 
> Correct, and is the reason why we came up with the described hack of above. Having a separate property 'mask-element' could solve the problem without the hack. If we just allow <mask-element>, we wouldn't even need to restrict 'mask-layer'.
> 
> I would prefer to just allow <mask-element> for 'mask', so that authors just need to rename the property name -webkit-mask-image to the new property name and their content will work just fine.
> The image() function is still not implemented in any browser. Relying on the implementation of image() could slow down the spec drastically and requires more changes on existing content.
> Beside that, the 'mask-layer-image' property (former 'mask-image' property) would not accept the same values as 'background-image' anymore. I can not estimate how much of a problem the described issues will be in the reality. So it might be acceptable.
> 
> Greetings,
> Dirk
> 
>> 
>> ~TJ
>> 
> 
>

Received on Thursday, 11 July 2013 14:46:43 UTC