W3C home > Mailing lists > Public > www-style@w3.org > February 2012

RE: [css3-regions][css3-gcpm] Thoughts on Plan A and Plan B

From: Håkon Wium Lie <howcome@opera.com>
Date: Fri, 17 Feb 2012 16:53:31 +0100
Message-ID: <20286.30715.198851.518972@gargle.gargle.HOWL>
To: Stephen Zilles <szilles@adobe.com>, David Hyatt <hyatt@apple.com>
Cc: "www-style@w3.org Style" <www-style@w3.org>
Stephen Zilles (and David Hyatt, with two indents) wrote:

 > > From: David Hyatt [mailto:hyatt@apple.com]

 > > (3) Problems with CSS Regions:
 > >  (a) CSS Regions require explicit elements right now in order to
 > >  work. This is terrible. 

I agree. It's not acceptable to lead devlopers down this path. 

 > >  Ideally any solution for paged
 > >  presentations would not involve having to spit out a bunch of
 > >  elements just to support pagination. Especially for many of the
 > >  simpler magazine-style layouts, CSS multi-column has a real edge
 > >  here. This is the single biggest problem with the CSS Regions
 > >  proposal right now.


 > SZ: I think this confuses two separate features (something you note
 > in (4) below). One of these features is the ability to handle an
 > unspecified amount of content in whatever size a given container
 > (e.g. an element including a multicol element) turns out to be AND
 > specifying what (a flow) is to go into the container separately
 > from the container (a region). Regions are primarily there to hold
 > (a portion of) a flow. Because the various layout proposals (grids,
 > flex-box, templates) have not followed up on being able to identify
 > containers (via "slots" or some other scheme) into which content
 > can flow, a user today is required to use an existing element to
 > represent the container. That, however, is not inherent in the
 > regions proposal.

Then you should change the regions proposal and show readers how to
use it without dummy/scripted elements.

 > >  (b) CSS Regions don't have any auto-generation capability. You
 > >  have to manually set up each page. This means that scripting
 > >  would be required if the user increased the font size for
 > >  example, since you might need to generate more pages on the fly.

 > SZ: This is a reasonable objection. At the CSS F2F, this was
 > described as a requirement that all the content of a region be
 > showable without requiring scripting. Two solutions to this problem
 > were posited: 1. Allow a region to have 'auto' height (in L to R
 > formatting) so that it can grow to hold all the content assigned to
 > a flow, and 2. Allow a region to be styled with the multicol
 > properties so that the multicol overflow mechanism, adding new
 > columns to the right, can be used to see all the content.

These proposed changes are good.

 > > (4) Problems with CSS Multi-column:

 > >  Multi-column layout can't handle sourcing from multiple flows,
 > >  but is otherwise much better than regions for most use cases. In
 > >  this example:

Your image didn't make it to the archive [1]. I've uploaded a copy to [2].

[1] http://lists.w3.org/Archives/Public/www-style/2012Feb/0559.html
[2] http://people.opera.com/howcome/2012/tests/magazine1.png

 > > You have two flows. One of them is the main flow and goes across
 > > all three pages, but the "Sushi" sidebar flows from page one to
 > > page three. This is an example of where multi-column layout falls
 > > down because it can't express relationships like this.

This can quite easily be added if we allow selection of columns. For
example, if the "sushi" flow is in the <aside> element, one could say
somthing like:

  aside::region(2) {
    float: page(3);

I've tried to write up code for the sushi page here:


(It's a sketch, there are some unknowns in the equation. It'd be
interesting to see what a similar sketch would look like using

 > SZ: There are more problems with Multicol than just handling
 > multiple flows (which is a bigger problem than you imply because
 > placing content, such as ads, onto or into the containers which are
 > flowing the "primary" content is a very attractive propostion for
 > an number of content providers. Such ad content is likely to come
 > from a place other than the source of the primary content. Regions
 > make this a simple thing to create.

I don't understand why you think ads can't be displayed in
multi-column layouts. Take a look at these screenshots:


The two-column ad and full-page ad are pulled from a URL. You can find
the souce code here:


I'd say the code is fairly simple. What would the code look like using
the regions?

 > SZ: Secondly, Multicol comes with extra baggage that regions do not
 > have. For example, the Multicol spec says that a 'column-rule' is
 > drawn between columns that have content in them. When columns are
 > move up and/or down for layout reasons, where is the column-rule
 > drawn. This would have to be specified. Regions have no such
 > requirement.

That's a trivial detail; column rules only appear betwen adjacent
columns with content. If you move a column away, the rule will also

 > > (5) I think right now the multi-column solution is far more
 > > attractive than regions. However, it can't handle sourcing from
 > > multiple flows. Really I think the main problem here is that we
 > > need to be thinking about how to define page masters and page
 > > layouts *first* and then allow multiple layout solutions for
 > > building these page masters. My dream version of this feature
 > > would:
 > > 
 > >   (a) Avoid using explicit elements to define the containers for
 > >   flowing content.


 > >   (b) Allow the definition of page masters that could define the
 > >   layout of the containers for flowing content on a page This
 > >   layout could be grid layout where that makes sense, positioning
 > >   if you just want to place the boxes precisely, or multi-column
 > >   layout if you just want to quickly/easily say "this page is
 > >   just standard 3-column."

I'd be intereted in seeing a proposal on this, too. I don't think the
Regions draft can be propertly evaluated without it.

I'm concerned about complexity, though. I fear that authors may face
combinatorial explosions when trying to create page templates for
various-sized devices, pages with one figure, two figures, pages with
one flow and one figure, pages with two flows with one figure, two
flows with three figures etc. etc.

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Friday, 17 February 2012 15:54:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT