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

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, 27 June 2013 01:02:17 UTC