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: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 1 Jun 2012 17:52:05 -0700
Message-Id: <B96A0804-82C4-448A-B317-6203835614A6@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
To: Alan Stearns <stearns@adobe.com>
On Jun 1, 2012, at 2:40 PM, Alan Stearns <stearns@adobe.com> wrote:

> On 5/31/12 9:32 AM, "Florian Rivoal" <florianr@opera.com> wrote:
>> === Proposal ===
>> == In css3-box:
>> * define overflow-x and overflow-y to be in the inline and block
>> directions, not in the physical direction.
> This makes sense to me.

It seems reasonable to me too, unless it breaks the Web. 

> Aside from the nomenclature, is there any reason
> to keep these physical?

We'd need to anwer how much it would mess up existing content. Maybe Japanese ePub folks could help answer that, if they are creating a lot of content with mixed directionality?

>> == In css3-marquee:
>> * drop the overflow-style property
>> * introduce overflow-x:marquee to replace overflow-style:marquee-line
>> * maybe introduce overflow-y:marquee to replace
>> overflow-style:marquee-block
> I am in favor of this replacement.
>> * Optionally define overflow:marquee to either mean:
>> "overflow-x:marquee;overflow-y:visible;" or
>> "overflow-x:marquee;overflow-y:marquee" depending on whether or not we
>> introduce overflow-y:marquee
> Since it would not make sense to have marquee in both directions, I'm in
> favor of the first shorthand definition whether or not we have
> overflow-y:marquee.

Marquee-block is a current overflow-style, so it seems like we'd want overflow-y:marquee as an option. Maybe we just say that if you have 'overflow-x: marquee;', then 'overflow-y:marquee;' is always treated the same as 'overflow: visible'. 

>> == 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).

I don't understand the statement "don't introduce paged on overflow-x, as It doesn't do anything useful". It seems to me like it'd be useful. 

> 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.

Why? Just slice it, or clone the box decorations on the right and left (use box-decoration-break on the inline direction edges). Is that complicated? Slicing, at least, does not seem complicated. If I have a 2 column box with no gutter, and each column is one page wide, then I should be able to page from one column to the next with 'overflow-x: paged'. 

>> == In the upcoming CSS repetition:
>> * use overflow-y:repeat (we can bikeshed on the value name later, I just
>> care about which property it is a value of)
>> * don't introduce repeat on overflow-x, as it doesn't do anything useful

It could be used if the region has fixed width and height and contains a multi-col element that itself has fixed height and grows new columns to accomodate it's content. It could happen. 

>> * Optionally define overflow:repeat to mean:
>> "overflow-x:visible;overflow-y:repeat"
> I agree.

Yes, that would be a good default behavior. 
Received on Saturday, 2 June 2012 00:52:42 UTC

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