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

Re: [css-regions] The region-overflow property

From: David Hyatt <hyatt@apple.com>
Date: Tue, 04 Oct 2011 20:04:30 -0500
Cc: "robert@ocallahan.org" <robert@ocallahan.org>, "www-style@w3.org list" <www-style@w3.org>
Message-id: <C7AC82BB-C995-46B0-9697-F03919B6CD27@apple.com>
To: Alan Stearns <stearns@adobe.com>
On Oct 4, 2011, at 7:42 PM, Alan Stearns wrote:

> On 10/4/11 5:13 PM, "David Hyatt" <hyatt@apple.com> wrote:
>> On Oct 4, 2011, at 7:04 PM, Alan Stearns wrote:
>>> Re: [css-regions] The region-overflow property 
>>> I don’t understand what it would mean to break and honor either overflow:scroll or overflow:visible.
>> I have it implemented in WebKit, so I can just show you.
> Thanks for the pictures.
> It looks to me like the only difference between “overflow:visible region-break:break” and “overflow:visible region-break:auto” is the gap at the end of the region. I can’t think of a reason I’d want that gap in either the visible or the scroll cases. The gap is a logical extrapolation for the property value combinations, but I don’t think it’s useful to combine them.

I guess I'm wondering why we wouldn't just build the behavior into the overflow values and eliminate the property then.

(1) overflow:hidden on last region = Honor breaks as though the content spilled out of the region in the pagination direction but the content gets clipped.
(2) overflow:visible/scroll/auto on last region = Don't honor breaks and just let all the content overflow and either be unclipped (visible) or reachable via a scrolling mechanism (scroll/auto).

The only reason to have region-overflow is if we think there is some value in supporting overflow:hidden, region-overflow:auto. I don't really see the point of this, because as you mentioned, it just looks like a rendering mistake.

So let's just kill the property completely and specify that overflow:hidden has the behavior you want.

Received on Wednesday, 5 October 2011 01:04:59 UTC

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