Re: [css-masking] reference boxes

On 12/16/2013 05:05 PM, Dirk Schulze wrote:
>
> 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.

That works. :)

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

bounding-box? overflow-box?

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

Right.

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

I think the border-box should be the default here, and you use
120% etc. to get more than that.

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

I don't think it limits clipping. It gives clipping the coordinate
system of the element's border box, which is quite a bit more
predictable and matches how CSS Shapes works.

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

Sounds reasonable to me, given Shapes has such a switch.

> Right now, the implemented behavior on Blink, WebKit and Gecko
> makes sense.

I don't think it makes sense that a circular mask and a circular
clip-path do not have the same reference box.

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

See Tab's response, but yes, the suggested spec text solves the problem
so it's no longer a problem. :)

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

If there isn't a definition for how clip-path behaves when
applied to a fragmented box, then we need one. Whether it
fits best here or in Fragmentation or in CSSOM, I'm not yet
sure. But probably what needs to happen is CSS Masking needs
to say that masking and clipping follow the same rules as
backgrounds when the box is fragmented, and then it can refer
to CSS Fragmentation for how that works.

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

The behavior I'm seeing in WebKit doesn't match the spec.

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

I'll note that 'overflow' doesn't affect such elements, so why would
'clip-path' affect them? It seems confusingly inconsistent to me.
But if that's the way they're going to work, there should at least
be a note pointing out this difference between clipping with 'clip-path'
and clipping with 'overflow'.

~fantasai

Received on Tuesday, 17 December 2013 04:52:21 UTC