Re: [css3-regions] auto-generation, pagination, and code examples

Hi Hakon,

Thanks for your detailed and constructive feedback on the specification. Steve, Rossen and I have discussed your input and here is our feedback.

It seems that the disconnect, as was apparent during the last Face to Face meeting, is around the scope of the regions module. We believe that regions as specified are to be used as basic building block for more complex layouts such as grid, page template and perhaps even multicolumn. Thus, by design, we are not trying to address the issues of auto-generation (these must be addressed by the other modules such as page template mechanism [yet to be defined and proposed]) or generic content breaking issues (CSS3 Fragmentation module).

AUTO-GENERATION

We agree this is an important issue that is closely related to regions, but we have consciously decided to not address it in the CSS regions module.

As we discussed during the F2F, we see a need for a page template mechanism that will naturally work with regions (like any other content that might be added to the template). Page templates will provide a mechanism that will generate new regions.

It is important to note that we do not lose content or require that the regions be particularly fitted to a font-size or content. The last region in the chain can be configured to hold the remaining content. Scripts can be used in addition, but they are not required, to guarantee that all the content is displayed (see [1]).

PAGINATION

The previous paragraph discusses page templates, so the following is limited to breaking content into pages.

For regions, there are two aspects: a) breaking regions themselves and b) breaking regions content.

Breaking regions is handled in the same way as breaking any other block element.

Breaking regions content is to be handled in the CSS3 fragmentation module, along with breaking the content of multi-col or pages, as agreed previously by the working group.

So our belief is that the issues around pagination are being addressed in the CSS3 Fragmentation module and the CSS3 Paged Media module and the upcoming work on page templates.

When we have an agreed upon page template mechanism, we could add an example in the spec. that references it.

In the meanwhile, we could add an example that shows how regions behave when printed, but that would be similar to showing any printing example.

EXAMPLE

Regarding adding an example with style on the region element and on the region, as you suggest, is something we agree would help readers. We'll add an action item to do so.

However, we do not understand why you say the first example's code is not shown. The code showing the regions and their corresponding CSS is shown. The code that explains how to flow content into the regions is shown.  The code for the flow content is shown. The code for region styling is shown. The code is shown by snippet between section 1.1 and 1.2.

Kind regards,
Vincent, Rossen and Steve

[1] http://www.w3.org/TR/css3-regions/#the-region-overflow-property


From: Håkon Wium Lie <howcome@opera.com<mailto:howcome@opera.com>>
Date: Thu, 8 Dec 2011 06:17:25 -0800
To: W3C style mailing list <www-style@w3.org<mailto:www-style@w3.org>>
Subject: [css3-regions] auto-generation, pagination, and code examples

Bert wrote:

> The CSS WG published an updated draft of the CSS Regions module:
>
>     http://www.w3.org/TR/2011/WD-css3-regions-20111129/


I believe that CSS will benefit from adding regions (as in a series of
stylable boxes into which content can be poured) to its reportoire.
Som magazines sometimes style containers (as opposed to strucural
elements) and it seems clear that publishers would like to do
magazine-like layouts on the web. Due to the many different screen
sizes, regions may have a bigger potential on screens than on paper.
So, we want to find good solutions for regions and describe them well
in open standards. (Thankfully, the attraction of proprietary
solutions seem to be waning.)

However, some of us have concerns about the Regions draft. These
concerns were voiced in the latest CSS WG F2F meeting [1].

In summary, my concerns are:

  - auto-generation: we need to make sure that arbitrary amounts of
    content can be poured into regions so that style sheets can be
    reused

  - pagination: we need to make sure regions can be paginated/printed

  - code examples: we need readable code examples in the spec in order
    to evaluate it

The latest WD [2] makes some changes in the right direction, but not
to the extent I had hoped given the progress I thought we made in the
F2F meeting. I hope that this message will lead to an improved draft
which can be supported by all vendors.


AUTO-GENERATION

It seems that the current regions model create a fixed set of regions.
If the content poured into the regions take up more space than the
fixed set of regions can hold, no additional regions will be generated
automatically. This is a side-effect of using structural elements as
regions.

This solution may work for one-off designs where the authoring tool
knows everything about the content, which font to use, which font size
that's used etc. I.e., it's not a good solution for a web with many
types of display devices and users with varying font-size preferences.

It has been suggested that, in order to generate more regions, a
script should be invoked. I don't think it is acceptable to rely on
scripting for a fairly basic function to work.

Are there other alternatives? I believe that the multicol module [3]
offers an alternative. Columns are generated as needed, and content
flows from one to the next -- just like for regions. If we added a way
toBin select and style individual columns, we could size and position
them. They could escape the rigid framework that multicol currently
provides, and fly like angels. Angelic columns.

For example, to turn the first columnn of an article into something
special, we could write:

  article { columns: 14em; }
  article::column(1) {
     position: absolute;
     font-size: 1.2em;
     visibility: collapse; /* makes space available others to use */
     ...
  }

For now, this is just a strawman proposal. But it shows that it's
possible to have stylable regions that naturally combine
auto-generation.

An issue has been added to the latest WD which somewhat describes the
concern [4]:

  ISSUE: should we allow the following: a magazine articles with
  regions galore on the first page, and then it switches to simple
  multi-column layout from page 2 and onwards

The proposed solution to the issue is:

  May be an interesting feature, but should move to next revision of
  CSS regions for simplicity.

I don't think we can delay auto-generation until the next revision.
It's a fundamental feature that needs to be described now. If it
cannot easily be described, the model may be flawed.

I'd like to reformulate the issue (or add this text in a new issue):

  ISSUE: A mechanism to auto-generate regions is necessary in order to
  support reusable style sheets.


PAGINATION

If we want magazine-like layouts on the web, we should also make sure
we can print these layousts. The current regions draft uses the term
"paginated" and "pagniation" once, both in this paragraph:

  The getRegionsByContentNode() method gets a collection of regions
  that contain at least part of the target content node. This can be
  used to navigate by bookmark in paginated view: the method returns
  regions containing the bookmarked element, which are then passed to
  pagination UI to show desired region or page.

This is not sufficient to support pagination. I suggest the spec
describes how region-based layouts can be printed. For example, how
does one specify that a region appears on page 2? How does one put a
region in the upper right corner of page 4? How does one generate the
text "continued on page 2" in the last region on page 1?

I propose to add this issues to the draft:

  ISSUE: Explain how regions and pages interact. How can regions be
  placed onto certain pages, and how can they be positiond wrt. pages.

  ISSUE: add functionality for having textual describtion like
  "continued here" or "continued on page x" to regions.

I do understand that the region spec offloads the responsibility of
positioning regions when it says:

  CSS layout facilities can position and size regions as needed.

However, I believe the regions spec must still describe how to achieve
these commonly used effects, if only through examples.


CODE EXAMPLES

I'd like to see a few fully developed examples in the spec in order to
better evaluate it. Figure 1 has a nice figure which is a good
starting point. However, the user never gets to see the code which
achieves this example. I suggest adding it.

Also, the spec uses pseudo-code in Example 5. I suggest using real
code in the examples.

I'd like to see an example of styling set on elements vs. style set on
regions. For example, which os these will win:

  #region1 {
    color: green;
    flow-from: foo;
  }

  article {
    color: red;
    flow-into: foo;
  }

Or perhaps the green declaration never takes effect?

[1] http://lists.w3.org/Archives/Public/www-style/2011Nov/0713.html

[2] http://www.w3.org/TR/2011/WD-css3-regions-20111129/

[3] http://www.w3.org/TR/css3-multicol/

[4] http://wiki.csswg.org/spec/css3-regions#issue-12should-we-allow-multi-column-elements-to-be-regions


-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com<mailto:howcome@opera.com>                  http://people.opera.com/howcome