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

On Jun 4, 2012, at 7:16 AM, "Florian Rivoal" <florianr@opera.com> wrote:

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

It seems almost as useful to me as inline direction marquee, so I guess I'll agree to disagree on that for now. 

If it is only useful for inline content in inline direction, then maybe we should change it to 'text-overflow: marquee'. 

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

I'm not talking about overflowing the lines themselves, nor that "overflowing in the inline direction" is the same as "inline overflow".  I'm just talking about "overflowing in the inline direction", and mentioning having a multi-col child element as a reasonable use case. If you have overflowing in the inline direction, then it should be a reasonable expectation to be able to page to it.  So overflow-x:paged is useful. 

Similarly, even if you ignore the multi-col child use case, a region could have a fixed width and height, and exist within a horizontal layout. So overflow-x:repeat could also be useful. 

Applying box-decoration-break to horizontal fragmentation is a secondary issue. But since it is reasonable to expect overflow paging and overflow region repeating to create horizontal fragmentation, then I think decoration-break should be extended to cover those situations, instead of it always being 'slice', as I'd expect current paged printing to do. 

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

I was thinking more of the case where overflow causes more columns to appear, which could make the layout wider by an amount unknown ahead of time by the CSS author. If the column width was one page width, with no gutter gap, then it should be easy to use overflow-x:paged to show one column at a time. 

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

Just slicing it into pages shouldn't be hard. It is just like overflow:hidden, with a different scroll position. Perhaps there are some difficulties with box-decoration-break? Perhaps you can elaborate on why it can't be described in CSS. 

Here is the sort of thing I had in mind:
@page {
   size: 800px 600px;
   margin: 100px;
   overflow: paged;
   /* most pages have controls to display next Y page */
}
a.foldout_image {
   width: 1200px;
   height: 400px;
   /* this appears on a page that also automatically includes a control to display next X page, to be able to see the right side of the image */
}

Received on Wednesday, 6 June 2012 17:56:27 UTC