Re: [css-masking] reference boxes

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.

>>   # 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.

>> 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.

> 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.

>> 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.

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.

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.

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.)

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

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.

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?

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

~fantasai

Received on Tuesday, 17 December 2013 00:31:44 UTC