Re: [css-masking] reference boxes

On Dec 17, 2013, at 1:31 AM, fantasai <fantasai.lists@inkedblade.net> wrote:

> On 12/12/2013 05:58 AM, Dirk Schulze wrote:
>> fantasai wrote:
>>> 
>>> The bounding client rect is fine to use for the mask positioning
>>> area, which determines the mask's size and position. But it is
>>> not appropriate to use for the mask painting area, because it
>>> means 'no-clip' is exactly equivalent to 'border-box’.
>> 
>> There is a difference. mask painting area is not necessarily a
>> clipping area. It is a reference box for aligning mask-origin
>> and mask-size.
> 
> That is not true. The mask positioning area is the reference box
> for mask-origin and mask-size. The mask painting area is the region
> to which the mask is clipped before being used as a mask, just as
> the background painting area is the region to which the background
> is clipped before being drawn.

Ok, in this case I am removing this sentence and just say that no clipping applies.

> 
>>>  # bounding client rect
>>>  #  The union of all border boxes for the element that has an
>>>  #  associated CSS layout box.
>>> 
>>> Consider the case of an unfragmented box. The bounding client rect
>>> is exactly the border box.
>> 
>> That is correct. I do not disagree.
> 
> My point is, clipping to the border box does not constitute
> "not clipping”.
> 
> Consider a mask image the shape of a diamond applied to a box
> with a drop shadow. And let's say the diamond is animated to
> grow from zero to covering the entire viewport, the goal of
> which is to gradually show the element (including its drop-shadow).
> 
> Because the drop-shadow is always outside the border box,
> and the bounding client rect is exactly the border box,
> the drop-shadow will never be shown as long as 'mask' != 'none',
> no matter how big the diamond gets.
> 
> The point of 'no-clip' is to allow the mask to be bigger than
> the element, so that parts of the element (overflowing content,
> drop-shadows, outset border images, etc) outside the border-box
> can be shown even when a mask is applied. The current definition
> doesn't serve that purpose.
> 

Understood.

>>> The spec requires that mask and clip-path behave differently.
>> 
>> Let us differ here between the two masking operations: masking with CSS
>> image and taking mask-size, mask-origin as well as the other longhands
>> into account and masking with SVG element.
>> * The latter (called SVG masking from now on) uses the same reference
>>  box: bounding client rects.
>> * The former (called CSS masking from now on) makes use of the reference
>>  boxes defined by background and borders. The exception is
>>  “mask-clip: no-clip” where the reference box is bounding client rects -
>>  the same as SVG masking.
> 
> mask-clip: no-clip vs. border-box shouldn't change the sizing
> function applied to a mask image. If you want to change the sizing
> function, add a value to 'mask-origin' instead.

Do you have a suggestion for such a keyword? bounding-client-rect?

> 
>> The idea of having a fourth reference box for mask-clip is to align
>> a mask to the area of the whole content. ’no-clip’ just means that
>> we do not have extra clipping beside the mask images… if a mask
>> image can never be the size of the bounding client rects, then you
>> everything automatically gets clipped to the border box… even if
>> you have overflowing content that you would like to mask. This is
>> extremely limiting and just makes sense for background and borders.
> 
> Ok, I think we're both interpreting the bounding client rect
> definition differently. Trying to go by your definitions...
> 
> What you're wanting totally makes sense. However, your considerations
> are incomplete, because CSS draws outside the border box and those
> drawings are also things we want to keep, even though they are not
> within the border box of the element or any of its descendants.

Ok. The idea is just to have a size reference for percentage, position (origin) and so on. A mask still can be bigger by choosing 120% as dimension for instance. Or negative length values for position. But we need at least a meaningful reference box. “painted area” or similar yet undefined terms are not precise enough since things like ‘outline’ are up to the browser. bounding client rect (as defined by getBoundingClientRects()) seems to make most sense to me.

> 
>>> In the case of b), the spec needs to be fixed because it isn't
>>> saying that at all atm.
>> 
>> It is definitely no intended to say that all. Which part is
>> confusing in the spec?
> 
>  # The reference box of the shape is the bounding client rect.
> 
> You need s/bounding client rect/border box/ to make masking and
> clipping behave the same.

That would not reflect current implemented behavior, and limits clipping quite a lot (same issues as with masking above).

> 
> Also, and this is important, the sizing and positioning of a clip
> path should, in general, not be dependent on whether content
> overflows (or by how much). It's possible to want the bounding rect
> to be the reference box, but in CSS layouts it's much more unlikely
> than wanting the border box to be the reference box.

That very much depends. I actually wanted to have a property to define the reference boxes in a future level of the spec. Right now, the implemented behavior on Blink, WebKit and Gecko makes sense.

> 
> Going back to the bounding client rect...
> 
>  # The union of all border boxes for the element that has an
>  # associated CSS layout box and is not in the SVG namespace
>  # and its descendant elements.
> 
> I missed "and its descendant elements". Let's try
> 
>  | For an element that has an associated CSS layout box
>  | and is not in the SVG namespace:
>  |   the smallest rectangle that contains the border box of
>  |   the element and the border boxes of all its descendants.

Sounds good for me.

> 
> so that doesn't happen. (This also fixes the problem that "union"
> is unclear: in this case we want a rectangle, but if polygons
> were acceptable, you could have some other shape as the result
> of the union.)

Well, no. All boxes are rectangular… all bounding and border boxes are rectangular. The union of these boxes is rectangular as well. But I like the suggested spec text. Or do I misinterpret your comment?

> 
> The other problem with this definition is that there's no
> explanation for how it's handled wrt fragmentation.

That would be a problem of the fragmentation spec or CSSOM, not Masking, no? The behavior of fragmentation must be specified for getBoundingClientRects().

> 
> My initial reaction to your definition was that using the bounding
> rectangle of all the fragments in a multicol to size an image vs
> using the behavior described for 'box-decoration-break: slice' to
> size an image are going to get you very different results even in
> the case of no overflow. Hence my statement wrt masking and
> clipping having very different behaviors.

If you mask a fragmented element, you are very likely to get strange results. No behavior is actually preferable. However, the specified behavior is the accepted behavior by browser implementations... Same behavior in WebKit, Blink and Gecko (with the exception of some bugs of course).

> 
> Lastly, there's another issue: should absolutely-positioned
> elements whose containing block is an ancestor of this element be
> considered in determining the size of its bounding client rect?

I think that is what we currently do in Blink and WebKit - which caused confusion on Filter Effects during the implementation process.

Greetings,
Dirk

> 
> (Let me know if what I'm saying makes sense. We may have to resort
> to pictures.)
> 
> ~fantasai
>

Received on Tuesday, 17 December 2013 01:06:38 UTC