W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [css-overflow-3][css3-marquee][css3-gcpm] x/y directions (maybe [css3-break] too)

From: Morten Stenshorne <mstensho@opera.com>
Date: Thu, 11 Apr 2013 10:57:10 +0200
To: James Holderness <j4_james@hotmail.com>
Cc: "Brad Kemper" <brad.kemper@gmail.com>, HÃ¥kon Wium Lie <howcome@opera.com>, "Florian Rivoal" <florian@rivoal.net>, "www-style list" <www-style@w3.org>
Message-ID: <87bo9lmom1.fsf@aeneas.oslo.osa>
James Holderness <j4_james@hotmail.com> writes:

>> > Is this something that's just not supported? Does paged overflow
>> > only apply to content that overflows vertically or is there something
>> > else I'm doing wrong?
>>
>> It only applies to vertical overflow, it seems. But what you are
>> doing, expecting it to apply to horizontal overflow too, seems very
>> reasonable.
>
> There's one exception I've found so far. If the block is a
> multi-column element, which by default would overflow horizontally,
> setting overflow:paged-x or overflow:paged-y does seem to work. I'm
> not sure why that is though.

That's an interpretation of
http://www.w3.org/TR/css3-multicol/#pagination-and-overflow-outside-multicol

Additional column boxes are moved to the next page(s).

>> Wanting a virtual grid is reasonable. But what would you do if you had
>> this:
>>
>> body { overflow-x: paged-x; overflow-y: paged-x; }
>
> I have thought about that, but I didn't see a simple solution.
>
> You'd obviously start by breaking the content up into pages as you
> would for a regular paged grid, but you then have to layout those
> pages in only one dimension. That can either be by taking a row at a
> time, or a column at a time, but the preferred option will depend on
> the type of content, so it seems like there ought to be a choice.
>
> I'm not sure that's worth the complication though. Is that really a
> use case that you want to support?

I'm not sure about this grid thing. How would you go about numbering the
pages, for instance? Is there even an intuitive way?

I realize that not being able to display overflowing content in the
inline direction is a limitation in Opera's implementation, though
(WebKit's too, BTW), but I suspect that could be handled by regular
scrollable overflow. If you have "overflow:paged-y" and long unbreakable
inline content, I suppose there should be a horizontal scrollbar to
scroll inside of the current page. If you have "overflow:paged-x" and
long unbreakable inline content, on the other hand, the overflowing
content could probably just bleed over to the next page.

Then there's the multicol spec again, which says that overflowing
content is clipped at the middle of the column gap [1]. And paged
containers are very similar to multicol containers (also on the
implementation side, both in Presto and in WebKit). If it's okay to lose
overflow in multicol containers, why not in paged containers? Or perhaps
it's wrong to unconditionally clip both for multicol and paged, and that
there should be a multicol property to control it for multicol
containers, while we should just do what the overflow properties say in
paged containers (e.g. overflow-y:paged-x; overflow-x:auto /* and not
just behave as if it's always set to 'hidden' */; }

[1] http://www.w3.org/TR/css3-multicol/#overflow

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
---- Office: +47 23692400 ------ Mobile: +47 93440112 ----
------------------ http://www.opera.com/ -----------------
Received on Thursday, 11 April 2013 08:57:53 UTC

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