Re: [css regions] How do regions paginate?

From: Alan Stearns <stearns@adobe.com<mailto:stearns@adobe.com>>
Date: Thu, 20 Oct 2011 12:00:30 -0700
To: Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>, Alex Mogilevsky <alexmog@microsoft.com<mailto:alexmog@microsoft.com>>
Cc: David Hyatt <hyatt@apple.com<mailto:hyatt@apple.com>>, "www-style@w3.org<mailto:www-style@w3.org> list" <www-style@w3.org<mailto:www-style@w3.org>>
Subject: Re: [css regions] How do regions paginate?

On 10/20/11 2:37 AM, "Vincent Hardy" <vhardy@adobe.com> wrote:

Hi Alex,

On Oct 20, 2011, at 2:14 AM, Alex Mogilevsky wrote:

Is there a need for breaking regions?

I would expect regions to never break at all, they are atomic units of fragmentation – any fragment of a flow has a region associated with it, which is how fragmented content is managed.

It is certainly possible to implement flowing through parts of regions, it would just use something else as “atomic” region. It will make it more complicated for DOM though. Currently we have getRegionFlowRanges on region element. If breaking regions is supported, that will have to be on “subregion” or some other new entity, or have a qualifier of parent region… Same for “find a region where this element begins” – if somebody wants to go to a bookmark in text, how do they describe which region to make visible? Use a stack of regions?

I think the analogy with columns is misleading here, even if reusing column code makes it work this way. Columns are not broken across pages, they are generated on new pages, and each new column is a unique instance. If there was a programmatic access to columns, it would hit the same issues and would have to expose individual column identity.

I am strongly in favor of not breaking regions.

I agree with you that regions are different, as defined today, since we do not have wording about generating a new 'region row' like multi-column does when a page break happens.

I guess the two options are:

a. do as you suggest and not allow regions to break. If broken, only the 'first' part of the region is ever laid out, the rest is discarded.
b. specify something similar to the multi-col spec. and deal with the more complex DOM as a result. It seems to me that we cold still have a getRegionFlowRanges on a region element. We would not know which of the region fragment the ranges are associated with, but this still seems to be a useful API. Otherwise, we could add a getRegionFragment() and the have getRegionFragmentFlowRanges() on that...

I do not have a strong opinion on where to go. I have added an issue:

http://wiki.csswg.org/spec/css3-regions?&#issue-23should-regions-be-non-breakable

May be we can resolve this at TPAC.
Thanks,
Vincent

I am assuming we should have a way of breaking regions in a paginated context (either print or screen). One of my use cases is a set of “cascading” regions that displays content in a single scrollable page, something like the first page example shown here:

http://explorationsintypography.com/about/

I’d expect to be able to print out this layout and have a region split across a page boundary, or to be able to display this page in an on-screen paginated way that split the region content at the screen page boundary.

So you are arguing for b. then, right?

Thaks,
Vincent