- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Fri, 1 Jun 2012 17:52:05 -0700
- To: Alan Stearns <stearns@adobe.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
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, Yes. > 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