Re: [css-masking] reference boxes

On Mon, Dec 16, 2013 at 8:51 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

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


Why not have the same as for backgrounds? Is there a reason to have a
different one?
In my mind, clipping and masking have the same initial area as the
background.
http://dev.w3.org/csswg/css-backgrounds/#background-clip


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


CSS masking and clipping should follow how backgrounds are fragmented when
you use 'slice': http://dev.w3.org/csswg/css-break/#box-splitting
I can't see any reason to ever allow 'clone'

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