[css3-regions][css3-exclusions][css3-gcpm] Plan B

As expressed earlier in this forum [1][2][3], I believe in regions and
exclusions, but I have some ideas about how to better express them in
CSS. Others have expressed similar concerns [4][5][6][7]. Based on
this, I've written up an alternative proposal and added it to the GCPM
editor's draft [8]:

   http://dev.w3.org/csswg/css3-gcpm/#exclusions
   http://dev.w3.org/csswg/css3-gcpm/#regions

For comparison purposes, I refer to the GCPM-based proposal as Plan B,
and the set of proposals [9][10][11] championed by Microsoft and Adobe
as "Plan A". 

There are some key differences between Plan A and Plan B:

                                   Plan A    Plan B
 (1)  uses elements for regions    yes       no  
 (2)  supports auto-generation     no        yes
 (3)  deals with multicol layouts  no        yes
 (4)  deals with pagination        no        yes

Regarding (1): Structural elements in HTML should, IMO, not be used
for stylistic purposes. The markup examples from plan A uses lots of
empty elements that are present only to represent regions. This is tag
abuse. Plan B uses columns instead of elements for regions.

Regarding (2): Another problem that stems from the use of elements to
represent regions is that it's hard, if not impossible, to support
auto-generation. Auto-generation means that regions are added, as
needed by the content. This is important in order to write reusable
style sheets. For example, if the user increases the font size, the
number of regions could & should increase. The columns used in Plan B
auto-generate.

Regarding (3): The fancy books and magazines that plan A is inspired
by (and I share the inspiration) are most often laid out in columns.
Magazines will often use special designs on the first page of an
article, and then settle into regular columns on page two. Likewise,
pull-quotes most often appear between columns. Plan A is not able to
express these very basic designs.

Regarding (4): We'd like to be able to print web content. Plan A
doesn't address pagination. Admittedly, pagination is a complex area
and no specification fully deals with it. However, any proposal for
splitting web content into presentational parts must, at some level,
address pagination. Plan A does not do it. For example, there is no
way to express that a certain region should be on the next page. (Or,
is there? Would setting 'break-before: page' on a region element work?
Plan A doesn't say)

When these concerns have been raised in the past, the proponents of
Plan A often argue that the issues are out of scope for the current
drafts, but that they will be addressed later by some future
specification. I believe that we cannot have meaningful discussions
about Plan A until these issues are addressed. So, if Plan A will
address these issues, I'd like to see the proposals now.

In addition to reformulating the functionality described in Plan A,
I'd also like to propose some changes in the way we create exclusions:

 (5) in plan A, style sheets may refer to images that establish
 exclusion zones. This is handy. But I suggest using background images
 for this; we've spent considerable efforts making background images
 powerful and flexible and I think they will be a good device for
 exclusions. For example, background images can be repeating so text
 may flow around a (say) repeating zig-zag pattern. This is listed as
 use case for plan A, but left TBD [12].

 (6) I'm not convinced we should target exclusions based on shapes.
 While shapes have obvious benefits in being compact representations
 without the need for external objects, I'd prefer to wait with shaped
 exclusions until shapes are added to CSS in general. For example one
 may want to describe borders using shapes in the future. However,
 I've included shapes in plan B to show how it's possible. 

 (7) A common use case for exclusions is text that runs around big
 letters/words. In plan A, this is addressed by describing the
 exclusion zone with a shape. However, the shape may change if a
 certain font isn't available, or if the user changes the font size.
 Therefore, I think it's better to base exclusions on the rendered
 content: the big letters that actually appear in front of the user.

Plan B is not a fully baked proposal. At this stage it mostly consists
of use cases from Plan A, recast as columns and page floats from
css3-multicol and css3-gcpm. I've borrowed liberally from the graphics
found in the plan A use cases, and most examples are expressible in a
few lines of CSS code. I happen to like this code, and I'm eager to
hear what others think.

[1] http://lists.w3.org/Archives/Public/www-style/2011Aug/0259.html
[2] http://lists.w3.org/Archives/Public/www-style/2011Oct/0781.html
[3] http://lists.w3.org/Archives/Public/www-style/2011Dec/0251.html
[4] http://lists.w3.org/Archives/Public/www-style/2011Dec/0448.html
[5] http://lists.w3.org/Archives/Public/www-style/2011Dec/0456.html
[6] http://lists.w3.org/Archives/Public/www-style/2011Dec/0457.html
[7] http://lists.w3.org/Archives/Public/www-style/2011Dec/0459.html
[8] http://dev.w3.org/csswg/css3-gcpm/
[9] http://www.w3.org/TR/css3-regions/
[10] http://www.w3.org/TR/css3-exclusions/
[11] http://www.interoperabilitybridges.com/css3-floats/OriginalSubmition.html
[12] http://wiki.csswg.org/ideas/css3-exclusions-use-cases

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

Received on Tuesday, 27 December 2011 14:05:18 UTC