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

Re: [css-masking] 'mask-source-type' and 'mask-type'

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 12 Dec 2013 13:39:41 +0000
To: fantasai <fantasai.lists@inkedblade.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <C0DB683C-3748-4553-9F5E-FED3FACA3053@adobe.com>

On Dec 11, 2013, at 6:46 PM, fantasai <fantasai.lists@inkedblade.net> wrote:

> On 12/11/2013 08:12 AM, Dirk Schulze wrote:
>> On Dec 11, 2013, at 11:46 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
>>>   8. Does 'mask-source-type' apply to 'mask-box-image-source'?
>>>      It's not clear from the spec. (See editorial issue #8, of
>>>      which this seems to be a symptom.)
>> No, it does not. That is one reason why it is not mask-box-image-type.
>> mask-box-image just supports alpha masking at the moment. Since you
>> can apply mask-box-image and mask-image on an element, it wouldn’t
>> make sense to have the same property set the mask type for both.
> I don't disagree with you, but please make sure this is clear when you
> fix editorial issue #8.
>>>    If it doesn't:
>>>      8.A.1 Having its name match mask-x-type per issue #1 would
>>>            help clarify that relationship.
>>>      8.A.2 This raises the issue of whether we need a mask-y-type.
>> This will not part of the discussion in this thread. (See [css-masking]
>> Comments.)
> I don't think 8.A.2 was covered in that other thread.
>>>    If it does:
>>>      8.B.1 I should be pulled out into the same section as the
>>>            'mask' shorthand, since they both apply to both types
>>>            of masking.
>>>      8.B.2 Also, in this case, I'd like to reraise the question of
>>>            whether mask-source-type and mask-type should be merged.
>>>            I think it would be less confusing if there was just one
>>>            property and its value at the point of application overrode
>>>            its value at the point of source definition, the same way
>>>            the 'width' property does.
>> I take the question to merge 'mask-source-type' and 'mask-type’.
>> Both properties apply to different element. ‘mask-source-type’ applies
>> to SVG graphical element, SVG containers and HTML elements. mask-type
>> applies to SVG mask elements exclusively.
>> In the following I describe the reasons why they are separate properties:
>> * mask-type defines the type (luminance|alpha) of the <mask> element.
>>  The author of the mask defines the preferred type for the created mask.
>> * mask-source-type interacts with mask-type: a preference from the author
>>  of the mask element can be overruled by the author of the document. The
>>  spec has an example where this can make sense. Note: the mask can be in
>>  a different document, written by a different author.
>> * mask-source-type has a value auto to chose the preferred masking type
>>  of the SVG mask.
> Fwiw, this is pretty much exactly the relationship between the 'width'
> property on a replaced element and the 'width' property on an <svg>
> root. That is, you get the same interaction as I was proposing for
> 'mask-type' on an element referencing a <mask> and the <mask> itself
> as you do for 'width' on an element referencing an external SVG and
> the <svg> itself.
> However, we're in the wrong if-clause here. anyway. :)
>> * mask and its longhands do not apply to the mask element. A special
>>  casing of mask-source-type seems strange.
>> * mask-type stays a single item property. mask-source-type is designed
>>  for a layer based mask, which will happen eventually - in the next
>>  version of the spec.
> [These two reasons I'd accept as valid.]

With changing the top-level sections and separating ‘mask-type’, does it get more clear? This is tracked by Issue 9 [1]. I suppose it is kind of related to issue 2 [2]. Do you want to wait with closing Issue 9 until issue 2 is resolved?


[1] http://dev.w3.org/fxtf/masking/issues-lc-2013.html#issue-9
[2] http://dev.w3.org/fxtf/masking/issues-lc-2013.html#issue-2

> ~fantasai
Received on Thursday, 12 December 2013 13:40:36 UTC

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