W3C home > Mailing lists > Public > www-style@w3.org > October 2007

Re: Feedback to CSS3 Multi-Column spec

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 22 Oct 2007 18:38:26 +0200
Message-ID: <18204.53762.820232.52834@gargle.gargle.HOWL>
To: fantasai <fantasai@inkedblade.net>
Cc: www-style@w3.org

Also sprach fantasai:

 > >  > 7) Section 4, "Note that, in most cases, only one of 'column-width'
 > >  > and 'column-count' affect the layout. If 'column-width' has a
 > >  > value other than 'auto', 'column-count' will be ignored."
 > >  >
 > >  > Why did we choose to ingore column-count? Wouldn't it make more
 > >  > sense to do the opposite? Ignore column-width in an over-constraint
 > >  > scenario. The benefit is that it is more consistent with the
 > >  > presented model. Column-width can never be guaranteed (since the
 > >  > available width is always filled). It feels non-intuitive to say
 > >  > {column-width:200px; column-count:1;} And get 6 columns....
 > > 
 > > There are two possible solutions, and we picked one, way back. I think
 > > it's the right one as, IMO, it's better to set the column width than
 > > setting the number of columns. The NYT reader seems to agree.
 > How about saying that if both are set, the column-count is regarded
 > as a maximum?
 > So for example, if I have an element and set
 >    column: 30em 6;
 > then I'll get as many 30em columns as will fit, or 6 columns if more
 > than 6 will fit.

I like the proposal. It will result in fewer too-short lines on small
screens (good) and less horizontal scrolling (good). It also adds
interdependency between properties (bad), but we can probably phrase
it so that the behavior of 'column-count' doesn't depend on the value
of 'column-width'.

I'd like to hear from implementors, what do they think?

Barring objections, I'll try to formulate it in the next revision.

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 22 October 2007 16:38:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:31 UTC