W3C home > Mailing lists > Public > www-style@w3.org > June 2013

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Sat, 8 Jun 2013 19:34:28 -0700
To: fantasai <fantasai.lists@inkedblade.net>
CC: www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <0B3AE3A4-B27F-4353-BB75-5298EFF62176@adobe.com>
Hi,

I had a chance to discuss this topic with fantasai during the CSS F2F. fantasai suggested that the 'mask-*' properties get a new shorthand property (maybe 'mask-layer'?). 'mask' itself would reset the 'mask-layer' and 'mask-box-image' properties and would itself have a reasonable setting.

Based on this idea, a syntax proposal could look like this:

'mask' = none | <url> [alpha | luminance]?

- 'none' is the initial value in current implementations
- If 'mask' is set all mask properties (including 'mask-box-image-*' and 'mask-*') are reset to the initial value.
- '<url>' can just be used to reference <mask> elements, as it is defined SVG 1.1 and implemented in all browsers.
- 'mask' will not be a shorthand

The old 'mask' shorthand will be renamed to 'mask-layer' and all 'mask-*' longhands to 'mask-layer-*' (or a better name if there is one).
- 'mask-layer-image's '<url>' will just support CSS Images, no references to <mask> elements possible.

No changes to 'mask-box-image*' necessary.

The new proposal would avoid the problem of different fetching algorithms depending on the resource type that is referenced.

Any comments or suggestions?

Greetings,
Dirk

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

> 
> On Jun 5, 2013, at 2:06 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
>> On 05/29/2013 09:01 PM, Dirk Schulze wrote:
>>> Hi,
>>> 
>>> During the WG meeting today, there was a question if 'mask: none;' can clear all masking operations on an element.
>>> 
>>> As an introduction, the CSS Masking spec defines three main properties: mask, mask-box-image and clip-path where some are shorthands for a couple of longhand properties:
>>> 
>>> mask
>>>    * mask-image, mask-source-type, mask-repeat, mask-position, mask-clip, mask-size
>>> 
>>> mask-box-image:
>>>    * mask-box-image-source, mask-box-image-slice, mask-box-image-width, mask-box-image-outset, mask-box-image-repeat
>>> 
>>> While the 'mask*' properties are similar to the 'background*' properties,
>>> the 'mask-box-image*' properties are similar to the 'border-image*' properties.
>>> 
>>> Since 'mask' and 'mask-box-image' are two shorthands, it seems to be impossible
>>> to disable all masking operations with 'mask: none'.
>> 
>> That's because of the way the shorthands have been defined.
>> That can be changed to be more like the way 'border'
>> interacts with 'border-image'.
> 
> Ok, now I understand you. However, this still leads to the following questions:
> 
> 1) Has "mask-image: none;" any affect on mask-box-image? Or is it just the mask shorthand that can reset mask-box-image?
> 2) What about "mask: none, url('image.png')" or even "mask: none, none;"  (notice: there are two masking layer defined)? Does this setting for the both examples affect mask-box-image?
> 3) Can the mask shorthand be restricted to just reset 'mask-box-image' if it is explicitly set to "none"?
> 
> Greetings,
> Dirk
> 
>> 
>>> The biggest problem is that the initial value for 'mask-image' is 'none' and
>>> therefore would always disable 'mask-box-image' as well.
>> 
>> This is an invalid issue. Shorthands don't have initial values
>> and don't reset anything unless they're explicitly specified.
>> (That declaration then gets expanded into the relevant longhands.)
>> 
>>> I added a note to the 'mask' property, that 'mask: none' will just disable
>>> masking by the 'mask*' properties, but not for 'mask-box-image*' properties.
>>> If there are no objections, I will remove the issue 1
>> 
>> I object to removing the issue without thinking through potential solutions
>> and concluding that it's in fact not a good idea to have a master shorthand
>> for masking.
>> 
>> ~fantasai
> 
Received on Sunday, 9 June 2013 02:36:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC