W3C home > Mailing lists > Public > www-style@w3.org > January 2014

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 13 Jan 2014 14:46:26 -0800
Message-ID: <52D46CC2.3060405@inkedblade.net>
To: www-style@w3.org
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.

~fantasai
Received on Monday, 13 January 2014 22:46:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:38 UTC