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

I was toying around with the idea of box generation based on overflow as
discussed during the f2f, wondering if it should
be a value of overflow or overflow-style.

After looking at the various specs that deal with these properties, I've
come to the conclusion that there are problems with the existing overflow,
overflow-x, overflow-y and overflow-style, and that we should fix that
before introducing a new value.

=== Problems with css3-marquee ===

overflow-style was introduced in the css3-marquee spec. It has the
following values: "auto | marquee-line | marquee-block". It doesn't in
itself trigger the overflow to behave as a marquee. You need to use
it in combination with overflow:auto or overflow:scroll.

The marquee-line and marquee-block hints values at the fact that you
typically want different types of overflow in the inline and in the block
direction. In the case of marquee, you usually only want it in the inline
direction.

I believe it would have made more sense to introduce marquee as
a value of overflow-x, and maybe also as a value of overflow-y, although I
wonder if anybody ever wants marquee in the bloc direction.

Even though you probably hardly ever want nested marquees, overflow-style
is inherited. While not terribly useful, it is at least harmless, as it
won't cause nested marquees to happen unless you manually apply
overflow:auto (which does not inherit) on several nested elements.

As far as I know, nobody implements CSS marquee according to the spec.
webkit has a marquee implementation, but it uses
overflow-x:-webkit-marquee to trigger the mechanism, which matches my
observations above.

In itself, I don't consider the marquee spec fatally flawed, but I
think the introduction of overflow-style sets a poor foundation
for other modules to build on.

=== Problems with GCPM ===

paged overflow is introduced as values of overflow-style in GCPM, and it
also has issues.

overflow-style is an inherited property, but I find it very doubtful that
nested pages is a useful default behavior.

The spec gives this as an example of how it is used:

html {
         overflow-style: paged-x;
         height: 100%;
}

So unlike overflow-style:marquee-*, overflow-style:paged-* doesn't need to  
be
paired with overflow:auto, and triggers the pagination mechanism
on its own. This is inconsistent with what css3-marquee says this property
is for (selecting the preferred scrolling method). Combined with the fact
that this property inherits, it makes the problem of unintended nested
pages much worse.

We could fix the spec to require overflow-style:paged-* to be used in
combination with overflow-y:auto or overflow-y:scroll, this extra
verbosity doesn't really buy use anything compared to overflow-y:paged-*

Also, nobody implements paged overflow the way it is specified. Instead of
overflow-style, Opera's implementation uses the paged-* values on the
overflow, overflow-x and overflow-y properties. Using either properties
has the same effect: pagination if you overflow in the block direction,
and the equivalent of overflow:hidden in the inline direction. Using both
overflow-x and overflow-y with different paged-* values triggers a
conflict resolution to figure which type of pagination should be use.

http://www.opera.com/docs/specs/presto2.11/paged-overflow/

Since paged overflow only makes sense when you overflow in the block
direction, I think paged overflow should be specified on the overflow-y
property only, leaving overflow-x free to do scroll or hidden or visible
or marquee for overflows in the inline direction.

=== Problem with css3-box ===

using overflow-x:marquee and overflow-y:paged-* only makes sense if
overflow-x is always in the inline direction, and overflow-y in the block
direction, but currently they are defined as physical directions. Because
of that, we can't simply say that marquee is only a value of overflow-x
and paged-* is only a value of overflow-y, as that wouldn't work in a
vertical writing mode.

We could define "overflow-x:paged, fallback" to be paged in a vertical
writing mode, and fallback in a horizontal one (where fallback is one of
the other values of overflow-x), vice-versa for overflow-y, and similarly
for marquee, but that looks clunky.

I'd much prefer defining overflow-x and overflow-y to be in the inline and
block direction. Admittedly x and y are not the best names for that, but
we're already stuck with them, and at least it isn't as bad as if they
were called overflow-horizontal and overflow-vertical.

=== Proposal ===

== In css3-box:

* define overflow-x and overflow-y to be in the inline and block
directions, not in the physical direction.

== 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
* 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

== 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-*"

== 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
* Optionally define overflow:repeat to mean:  
"overflow-x:visible;overflow-y:repeat"

Received on Thursday, 31 May 2012 16:33:16 UTC