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

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

From: L. David Baron <dbaron@dbaron.org>
Date: Wed, 4 Apr 2012 14:34:10 -0700
To: Håkon Wium Lie <howcome@opera.com>
Cc: www-style@w3.org
Message-ID: <20120404213410.GA31209@crum.dbaron.org>
On Tuesday 2011-12-27 15:04 +0100, Håkon Wium Lie wrote:
> 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

Some brief thoughts on these (apologies for such a delayed
reaction):

I like your alternative to regions expressed using pseudo-elements,
except that:

 * I don't like tying it to multicol at all; I'd rather see it be an
   entirely separate mechanism (using ::region() only)

 * I'm also not happy about the interaction of the ::column()
   multicol styling mechanism with the column selectors described in
   http://dev.w3.org/csswg/selectors4/#table-pseudos .  Technically
   there's no name collision, but I really wouldn't want :column()
   and ::column() as two totally different things.  However, fixing
   the previous point would avoid this problem for now.

Otherwise I think it's a great start based on issues I've thought
about so far, though it obviously will need more detail eventually.

In my head, at least, I'd imagine that generation of new regions
would happen when:
 * the styles on a region constrain the size of the region such that
   it would overflow
 * the size of the pages or columns constrain the size of the region
   such that it would paginate
and then if there's no style for a ::region() pseudo-element for the
given number, it would just be an unstyled block (which would mean
we'd never have the problem of running out of regions).


I like the idea of having an alternative to exclusions based more on
the float model.  But I'm a bit less happy with what you're
proposing.  It feels to me that the feature set doesn't line up very
nicely with the typical use cases, so that authors would be using
strange-looking declarations to get common effects, etc.  I'm also
worried it offers a bunch of combinations of features that don't
make sense (though the draft seems to have two alternative
proposals, one of which is a bit better than the other in this
regard).

As an alternative to exclusions based on the float model, I'd
perhaps be more interested in something along the lines of features
like (ignoring vertical writing for the moment for simplicity,
though we'd need to handle it eventually):

  float: gutter (or float: rule)
    - would float to the next available spot in a column gutter/rule
    - apply 'top' and 'bottom' when not auto, and center between them
    - if both 'top' and 'bottom' are auto, use position of placeholder
      for top
    - when not in multicol, behave like 'float: start'

  float: center
    - just like float:left/float:right, except allows flow on both
      sides
    - apply 'left' or 'right' when not auto; center between them if
      neither auto

  float: page-top | page-bottom | clear-page-top | clear-page-bottom
    - float something to fill the entire width of the page at either
      the top or the bottom
    - the clear-* variants would require there be no previous floats
      at that page top or bottom

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Wednesday, 4 April 2012 21:34:42 GMT

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