Re: [css-break][css-transforms] transform on fragmented overflow

On 01/13/2014 05:46 PM, fantasai wrote:
> On 12/31/2013 01:44 PM, Dirk Schulze wrote:
>> Hi,
>>
>> The transform origin of an element is determined by its border box as per CSS Transforms [1]. With setting the transform
>> property, the coordinate space of the element (and with it all descendants) is altered.
>>
>> Lets assume the element is rotated and has overflowing content.
>> The overflowing content gets rotated together with the element.
>> The origin is still determined by the border box of the element.
>>
>> Lets further assume the overflowing content is fragmented
>> (fragmented over multiple columns on Multi-Column layout).
>> How does the transform of the element effect the transform
>> of the overflowing content on a different fragment?
>
> We had a long discussion on a similar problem in Tucson:
>    http://www.w3.org/blog/CSS/2013/02/21/resolutions-78/
> (I think the spec didn't get updated though. I'll go fix
> that.) Looks like we need to revisit how we want to handle
> overflowing content.
>
>> According to CSS Fragmentation, the behavior of Chrome and Safari is correct IMO. The results of Firefox and IE can be more
>> pleasant though. Do we consider the behavior of Firefox and IE a bug?
>
> If the origin is interpreted per fragment, the we need a
> definition of the border-box of a fragment consisting only
> of overflowing content. I think what Firefox and IE are
>   doing is implying a zero-height border box as existing on
> the page and the overflowing content as overflowing that
> implicit box. This is pretty sensible if we're going with
> a "per fragment" approach to transforms.

Just to wrap up on this, the WG concluded on this solution,
and it is now in the spec:
   https://drafts.csswg.org/css-break/#transforms

Let me know if anything is still unclear!

Thanks~
~fantasai

Received on Wednesday, 16 September 2015 22:22:26 UTC