[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                  http://people.opera.com/howcome

Received on Thursday, 8 December 2011 14:18:02 UTC