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

On Sat, 02 Jun 2012 02:52:05 +0200, Brad Kemper <brad.kemper@gmail.com>  
wrote:

> 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:
>>> * 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'.

Given that no-one implements the overflow-style based marquee, there is
not need to put in backward-compatibility mechanisms. I don't think
bock-direction marquee is terribly useful, so I am proposing to leave
it out.

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

If you have a useful definition of what it does to overflow
into new pages when overflowing inline, why not. I don't have one
which is why I proposed what I said.


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

On these two points I think you're arguing that paging / cloning in the  
inline
direction makes sense due to multicol.

I definitely want this to work with multicol, but I think its current  
overflowing
behavior isn't quite inline overflow. The overflowing content is put in  
the inline
direction, but that's just how you display the overflow, not how it  
overflowed.
The lines themselves didn't overflow, so I don't consider it a case of  
inline overflow.

Since multicol is special, it would require a special definition. I'd say  
that
when the lines inside a single column are two long and overflow, then the  
behavior
of overflow-x should apply. On the other hand, when you have so much  
content
that you can't fit any more lines in the allowed number of columns, then
the behavior should be controlled by overflow-y.

Multicol behaving that way would work well with overflow-y:paged-* and  
overflow-y:repeat.

Removing the multicol case, I do think slicing isn't that easy, as it  
seems to me that the layout inside the sliced off box/page isn't something  
can simply be described in regular css.

  - Florian

Received on Monday, 4 June 2012 14:18:04 UTC