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

Re: [css-masking] reference boxes

From: Dirk Schulze <dschulze@adobe.com>
Date: Fri, 27 Dec 2013 18:53:51 +0000
To: fantasai <fantasai.lists@inkedblade.net>
CC: www-style list <www-style@w3.org>
Message-ID: <B1E70D69-160F-4323-A442-A03C6610DE83@adobe.com>

On Dec 26, 2013, at 7:39 AM, fantasai <fantasai.lists@inkedblade.net> wrote:

> On 12/17/2013 04:24 AM, Dirk Schulze wrote:
>> 
>> Short summary of the latest changes regarding reference boxes after the discussion on this thread.
>> 
>> * I removed the sentence stating that the mask painting area is limited
>>  to the bounding client rect on mask-clip: no-clip
> 
> Looks good. (Btw, s/rectricted/restricted/ in the previous <dd>s.)

Fixed.

> 
>> * I added the keyword bounding-box to mask-origin. The keyword references
>>  the bounding client rect
> 
> OK. I'm going to think about that after we've sorted the rest of this;
> it may need to change to something else if it does not in fact correspond
> exactly to the bounding client rect.
> 
>> * I changed the definition of bounding client rect to:
>> “”The object bounding box for elements in the http://www.w3.org/2000/svgnamespace and without an associated CSS layout box. The smallest rectangle that contains the border box of the element and the border boxes of all its descendants otherwise. (See getBoundingClientRect [CSSOM-VIEW].)”"
> 
> Move "otherwise" to the front of the sentence so it's more clearly
> interpreted as a link between the two sentences. Otherwise, looks
> pretty clear.

Fixed.

> 
> My remaining concern here is how this box behaves wrt fragmentation.
> That particular definition is in conflict with the explanation in
> 'clip-path' of how the clipping path is fragmented.

I am not sure if it is. bounding-box defines a reference box and does not effect fragmentation differently than the other property values. Even though I wish it would! It would be more pleasant to not fragment the clipping path for this value.

> 
>> * I added an optional <box> value and bounding-box keyword to clip-path
>>  so that authors can choose the reference box. The syntax now looks like:
>>  <clip-source> | [ <basic-shape> || <box> | bounding-box ] | none
> 
> Seems reasonable. Minor comments:
> 
>  # If specified in combination with a <basic-shape> it is the reference
>  # box for the <basic-shape>.
> 
>  Suggest s/is/provides/

Fixed.

> 
>  # If specified by itself a clipping path is computed based on one of
>  # border-box, margin-box, border-box, padding-box or content-box which
>  # use their respective boxes including curvature from border-radius,
>  # similar to background-clip [CSS3BG].
> 
>  Suggest replacing with
> 
>  | If specified by itself, uses the edges of the specified box, including
>  | any corner shaping.

Done.

> 
>  Also, suggest folding the ''margin-box'' definition in with ''<box>''
>  by putting the both <dt>s before the <box> definition. The definition
>  for <box> (including its reference to Shapes) is exactly what's needed
>  here.

Done.

> 
>  # The size of the box is determined by the bounding client rect.
> 
>  I think you mean
> 
>  | The reference box is the bounding client rect.

Fixed.

> 
>  ?
> 
>> * The default reference box for basic shapes on clip-path is border-box
> 
> I'm happy for mask-origin and clip-path to agree on the default box.
> 
>> * I defined how container breaks affect masking and clipping for each
>>  of the source referencing properties.
> 
> See conflict above with definition of 'bounding-box' for boxes fragmented
> within a page.

I am happy to discuss this further.

Thanks a lot,
Dirk

> 
> Thanks~
> 
> ~fantasai
> 
Received on Friday, 27 December 2013 18:54:24 UTC

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