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

Alan Stearns wrote:

 > >> To use regions, the code is slightly longer:
 > >> 
 > >>  .article { columns: 3 } /* or better: a width in ems */
 > >>  img { column-span: 2; width: 100% }
 > >>  article::region(1) {    /* selects column 1 */
 > >>    column-span: 2;
 > >>    float: top;
 > >>    visibility: collapse; /* so that column 2 moves in */
 > >>    height: 3em;          /* or something */
 > >>  }
 > >> 
 > >> But still only seven lines compared to the 20 or so lines in the
 > >> grid-based syntax (not counting markup). As for readability, others
 > >> should judge, but personally I find the compact code easier to read.
 > > 
 > > I'm glad you find that readable, but it's completely opaque to me.
 > 
 > It took me a while to puzzle through this, too - thanks for the line-by-line
 > explanation. Personally I find the article::region(1) styling strangely
 > indirect. I am assuming that if the article paginates the spanning column
 > gets repeated.

As proposed, "arcticle:column(1)" (or "article:region(1)") only
selects the first column/region of the article. But, I think it's
useful to be able to select the first column/region on all pages. This
could easily be expressed as:

  article::column(1,*)     /* first column on all pages */

just like one can select all columns on a certain page:

  article::column(*,2)     /* all columns on the second page */

 > That could be fixed by making the selector
 > article::column(1,1). I also find it a bit odd that the article specifies
 > three columns but gets a fourth by virtue of visibility:collapse. Can I
 > style article::column(4) when article has columns set to 3?

Yes. In the multicol model, there's an infinite number of columns.
Setting the number of columns, e.g. through:

  article { columns: 3 }

doesn't limit the number of columns, it merely states that three
columns should fit inside the multicol box. 

So, selecting "article::column(4)" makes sense, but there's no
guarantee that it will hold any content.

 > I do like the idea of column selectors, but I think there will be quite a
 > few issues to work through with positioning and changing such properties as
 > width and height for individual columns. Tab's mentioned column balancing,
 > but I'm also concerned with how columns are sized and positioned to begin
 > with. Consider your overlapping case:
 > 
 > article {
 >   columns: 15em;
 > }
 > article::region(1-3) {
 >   height: 15em;
 > }
 > article::region(2-3) {
 >   margin: 4em 0 0 -4em;
 > }
 > 
 > The overlapping columns would fit in an available width of 44em, but would
 > the multicol algorithm from 3.1 [1] lay out less than three columns in a
 > 44em space before moving them into place? The multicol implementations I've
 > worked on have had a difficult enough time determining the number and width
 > of columns without considering the result of moving or resizing individual
 > columns. I am more comfortable specifying where elements should display
 > directly, rather than using offsets from a calculation that isn't the end
 > result.
 > 
 > [1] http://www.w3.org/TR/css3-multicol/#the-number-and-width-of-columns

First, it's a good question -- in what order do these things get
worked out and is enough information available at every stage to make
the decision deterministic. 

I think we can work this out. We have, as discussed above, an
unlimited number of columns at our disposal, so we are not limited to
what would normally fit into the elements. So, while only two columns
would naturally fit into a element with an available size of 44em, we
can still size and position more columns. (But, we don't know if they
will have any content. And if they don't have any contnet, they
probably shouldn't be visisble in any way.)

In order to reproduce the example in question, I'd like to change my
code slightly, by adding a 'width' setting to the columns. So that we
have:

  article {
    columns: 15em;
  }
  article::region(1-3) {
    width: 15em;
    height: 15em;
  }
  article::region(2-3) {
    margin: 4em 0 0 -4em;
  }

The width and height of the first three columns now are set directly.

The next (4th) column will be auto-sized according to the available space. 

Now, it should also be possible to work out what the results would be
if 'width' isn't set directly. Let's see. The available space is 44em,
so each column will be 22em (assuming zero column gaps, and
identically sized page boxes). This width can be computed without
laying out the content, so I don't think implementations will have
problems finding it even if it's not set directly.

Cheers,

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

Received on Tuesday, 10 January 2012 00:55:54 UTC