W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [CSS Regions] Update available

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 1 Apr 2011 07:06:58 -0700
Cc: Tab Atkins Jr. <jackalmage@gmail.com>, Arno Gourdol <agourdol@adobe.com>, "www-style@w3.org" <www-style@w3.org>
Message-Id: <DC6807E6-B5A6-4DBC-BB53-2C6C486C6B7C@gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>

On Mar 31, 2011, at 4:35 PM, Alex Mogilevsky wrote:

> It is tempting to use overflow property but there is a couple of reasons not to. Hyatt showed one (overflow has two dimensions, but only one dimension is forwarded to next container).

I didn't quite understand that. It seems like overflow--y is all that would matter. Well, maybe it would really be 'overflow-block-progression-direction', which would be 'overflow-y' in rtl ttb languages. This assumes that blocks and inlines can all be flowed, which seems necessary. 

Actually, when I think about it more, this seems a lot like the same sort of issues as you'd have with paged media (and also multicol). You'd have to break blocks between the flow boxes (or not), deal with different widths to flow into, decide what to do with borders, etc. Can't you have 'overflow-x:hidden' while flowing blocks and line boxes into multiple pages?

If we ever have something like 'overflow-y:paged' (and I hope we do), then it would be a similar situation. It doesn't seem unsolvable to me.

> Another reason is "overflow" describes how to deal with content of the element that doesn't fit in its box. However in this case the content doesn't actually belong to the element. It comes from an entirely different source, and the nature of this indirection is not overflow but rather redirection. If "overflow" was used to define that it would be semantically incorrect and confusing as hell.

I don't understand. In order to flow into another box, it has to not fit into the first box. Once it gets inside the second box, it also might not fit entirely within it (ie, it would overflow in the block progression direction) and then overflow into (or generate) a third box. If any of those boxes had pre-existing content, then the content would need to be joined somehow, or content from the send+ boxes suppressed, or forwarded on to boxes that were empty (I prefer the first option, but perhaps with a property for the author to choose). But once a box gains some content, then the box know where to begin drawing the content but not what to do with the excess. That sounds like overflow to me. 
Received on Friday, 1 April 2011 14:07:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:44 UTC