W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css regions] How do regions paginate?

From: Vincent Hardy <vhardy@adobe.com>
Date: Thu, 20 Oct 2011 02:37:59 -0700
To: Alex Mogilevsky <alexmog@microsoft.com>
CC: David Hyatt <hyatt@apple.com>, "www-style@w3.org list" <www-style@w3.org>
Message-ID: <424FEEA2-DA5A-4035-AC3A-23230A33F3CC@adobe.com>
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:


May be we can resolve this at TPAC.


From: www-style-request@w3.org<mailto:www-style-request@w3.org> [mailto:www-style-request@w3.org] On Behalf Of David Hyatt
Sent: Thursday, October 13, 2011 11:03 AM
To: Vincent Hardy
Cc: www-style@w3.org<mailto:www-style@w3.org> list
Subject: Re: [css regions] How do regions paginate?

On Oct 13, 2011, at 1:00 PM, Vincent Hardy wrote:

What about we specify that the region ordering, in paged media, is done in document order on a per-page basis? I think saying that would be enough to specify the behavior we want.

Yeah that sounds good. You can nest regions also though, as well as put regions in columns. In general, it seems like any time you have nested pagination models regardless of type (columns, printing, regions), that you will want the same behavior.

Received on Thursday, 20 October 2011 09:38:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:06 UTC