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

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

From: Dirk Schulze <dschulze@adobe.com>
Date: Fri, 3 Jan 2014 19:58:29 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Robert O'Callahan <robert@ocallahan.org>, www-style list <www-style@w3.org>
Message-ID: <A99A7EAB-B3F1-4ABA-8EBD-A181964F0321@adobe.com>

On Jan 3, 2014, at 8:44 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Dec 31, 2013 at 2:49 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> I think the answer to this will depend on the question I recently posted
>> about whether a fragmented element has one or many border-boxes.
>> However, whatever the answer to that is, I wouldn't support defining the
>> behavior of Chrome and Safari as correct, which I assume means defining
>> things in terms of a hypothetical layout where the element is not
>> fragmented. That layout doesn't correspond to anything which is actually
>> rendered, and Gecko never computes it. It probably doesn't even make sense
>> for Webkit/Blink in complex fragmentation situations like regions where each
>> fragment can get a different width.
> Yeah, our multicol behavior shouldn't be taken as an endorsement of
> any generic fragmenting behavior; it has always been a dirty
> visual-base hack that does bad things (like putting the border of an
> element in the next column).  Proper fragmentation would work better,
> and probably like what FF/IE are doing.

There is no implementation to blame unless it is clear from the spec how it is supposed to work. The discussion of fragmentation and borders (especially border-radius) is on another thread[1].


[1] http://lists.w3.org/Archives/Public/www-style/2013Dec/0467.html
> ~TJ
Received on Friday, 3 January 2014 19:59:01 UTC

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