W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css3-marquee][css3-gcpm][css3-box] rethinking overflow, overflow-x, overflow-y and overflow-style

From: Florian Rivoal <florianr@opera.com>
Date: Mon, 04 Jun 2012 15:52:07 +0200
To: www-style@w3.org
Message-ID: <op.wfdss5w54p7avi@localhost.localdomain>
>> == In gcpm:
>> * replace overflow-style:paged-* by overflow-y:paged-*
>> * don't introduce paged on overflow-x, as It doesn't do anything useful
>> * optionally define overflow:paged-* to mean:
>> "overflow-x:hidden;overflow-y:paged-*"
> Why 'hidden' instead of the initial value? Wouldn't overflow:paged-* mean
> "overflow-x:visible;overflow-y:paged-*" ?
> If overflow-x and overflow-y keep their current physical definition, then
> it will make sense to have paged-* values for both (and repeat values on
> both as well). But then we'll have to define what happens when they are
> applied in the inline direction, as we can only fragment content in the
> block direction.

Two-in-one reason(s):

- That's how opera behaves, and we're the only implementation, so why not.

- If you have overflow-y:paged-x; your pages are laid next to eachother
horizontally. Having one horizontal mechanism to switch between pages, and
another horizontal mechanism to scroll inside the pages would probably
be awkward, so auto and scroll aren't nice. Visible is tricky as well, as
you may need to overflow onto the next page when mid transition, other
weird things like that. So you should really try to avoid overflowing
in the inline direction, but if you do, hidden is the least bizarre
Received on Monday, 4 June 2012 13:52:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC