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

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.

Yes. 

 > 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:

  http://people.opera.com/howcome/2012/tests/magazine1.html

(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
regions)

 > 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:

  http://people.opera.com/howcome/2011/gcpm/ss

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

  http://people.opera.com/howcome/2011/reader/news/e1.html

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
disappear.

 > > (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.

Yes.

 > >   (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
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Friday, 17 February 2012 15:54:13 UTC