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

Tab wrote:

 > I think the approach you've outlined in GCPM would handle extra text
 > by spawning more full-height columns to the right of column #4,
 > correct? 

Yes

 > These would then move to the next page if necessary, as
 > usual for multicol overflow columns.

Yes

 > This behavior can be achieved with Grid as well - just make the last
 > region multicol.

Hmm. Let's see. Starting with your code found here:

 http://lists.w3.org/Archives/Public/www-style/2011Dec/0290.html

You would say:

  #region4 { grid-cell: e; columns: 20em }

Is this what you are proposing?

And you would get full-height columns, on the next pages if necessary?
I don't see that happening; grid-cell 'e' has a width and height and
seems to be limited by those constraints. I don't see how, by turning
a region into multicol, these constraints would suddenly go away. 

Another issue is columns widths. In multicol, one can declare an
optimal width and the number of columns will adjust accordingly. In
grid layout, it seems this is not possible -- you can't increase the
number of columns automatically, I believe. So even if we are able to
make the last region multicol, the widths of the columns will not be
coordinated with the widths of the regions.

Do you have any good use cases for grids where you can post sample code?

 > > The next chunk is a little harder, but not much:
 > >
 > >  .article { columns: 3 }  /* sets the number of columns to 3 */
 > >  img { column-span: 2;    /* image spans across two columns, starting from the natural column */
 > >    width: 100%;           /* makes the image fill two columns + gap between */
 > >    float: top;            /* floats image to the top of the article; this is simlar to how
 > >                              CSS currently float images to the left and right. */
 > 
 > I'm unsure of the interactions of column-span, width, and float.  I'm
 > *extra* unsure of how this is meant to act with incomplete spans like
 > the above (that is, spans other than 'none' or 'all').
 > 
 > So far as I understand, the effect of 'column-span:all' is to split
 > the content into pieces around the spanning object, where each piece
 > generates an independent column-row and auto-balances.

Yes. 

 > The spanner is also enclosed in an anonymous BFC. 

BFC, yes, but not anonymous.

 > If I fill in a lot of blanks myself, I think you're implying that
 > integer column-spans also have this effect

Not quite. In the example, the image spans two columns and it is
floated to the top of the article. So there is no need for
auto-balancing. 

Describing the effect of 'column-span: <integer>' is somewhat tricky;
if the spanner naturally appears in the last column, should the spec
require that the spanner intrudes into previously laid out columns?

But, we're avoiding the tricky issues here by floating the element.

 > except that they set the width of the anonymous spanner
 > wrapper to some multiple of the column width (+ gutters as
 > appropriate) which allows you to declare the image to be 100% of that
 > anonymous box's width, and then once the anonymous boxes have been
 > generated, you can float things around.
 > 
 > I'm confused how the the top-float behavior you're assuming is
 > supposed to square with the fact that the spanner wrapper is a BFC.

Why would it be problematic to have a BFC floated to the top?

 > >  article::region(1) {     /* selects region/column 1 */
 > >    column-span: 2;        /* makes that region/column span two normal-sized columns
 > >    float: top;            /* floats the region to the top, i.e. just under the image */
 > >    visibility: collapse;  /* flags that the next column (i.e., column 2) should move into where
 > >                              column 1 once was */
 > >    height: 3em;           /* the width of the region/column is set with column-span, but the height
 > >                              must also be set in order to replicate the intended design */
 > >  }
 > >
 > > The basic idea is that columns can be moved/resized/positioned, while
 > > keeping their place in the flow of content.
 > 
 > Same as above, I'm not sure how column-span and float interact.

It may be easier to try it out; we have implemented this feature in
builds available here:

  http://people.opera.com/howcome/2011/reader/

In one of those builds, try visiting:

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

Our implementation experience is that top/bottom-floating combine well
with column-spanning and that you can reproduce common newspaper
layouts in a few lines of code.

 > further confused at how a column box can, itself, be spanning columns.

It means: make this column have the same width as two normal
columns, plus any gap between

 > Does it only span columns that are somehow still "column-y"?  How do
 > you determine when a column is no longer "column-y"?

I don't understand what you mean by "column-y".

 > What would happen if I made, say, column #3 also float?

That works. If you float it to the top (like column 1) it would end up
underneath column 1. If you float it to the bottom, it would go there. 

 > >  > Almost every line in there invokes combinations of behavior that I'd
 > >  > have to look up and think about to understand, and there are a few
 > >  > bits (like the "visibility:collapse") that I'm *completely* in the
 > >  > dark over.
 > >
 > > It's borrowed from CSS 2.1:
 > >
 > >  http://www.w3.org/TR/CSS2/visufx.html#propdef-visibility
 > >
 > > It's used here to indicate that when column 1 is moved, the next
 > > column should take its place in the layout. This should probably be
 > > the default behavior, so we may not even need the switch.
 > 
 > The behavior you're attempting to invoke for multicol-collapse is
 > substantially different from table-row-collapse.  The latter is
 > basically display:none, except it works intelligently for
 > table-columns as well, and has some ill-defined magic to avoid causing
 > a re-layout.  I would not attach your behavior to this keyword.
 > (Though it might make sense to define 'visibility:collapse' for column
 > boxes, with similar behavior to tables.)

I'm not tied to the syntax. The code line "visibility: collapse" can
probably be dropped from the example, as this behaviour would be
default.

 > > If you hate floats, Plan B will be challenging. Personally, I think
 > > floating elements to the left, right, top and bottom makes sense -- I
 > > see it in publications every day. For example, here:
 > >
 > >  http://pdfreebooks.org/files/alice-in-wonderland-book.pdf
 > >
 > > How would you code this without floats?
 > 
 > I don't hate floats - when used in the traditional (pre-web) way
 > they're extremely useful and appropriate.  For example, in the Alice
 > example you link to, floats would be appropriate for both the Adobe
 > icon and the Alice book cover.

Maybe we're looking at different documents. I'm looking at a PDF file
with top/bottom floats on page 12, page 15, page 23, page 26, page 37,
page 48, page 56, page 63, page 67 etc. I don't see a better way to
encode this than:

  img { float: top }

I've put a copy of the document here:

  http://people.opera.com/howcome/2012/tests/alice-in-wonderland-book.pdf

(it's in the public domain)

 > My webdev experience has taught me to abhor the use of floats for
 > page-level layout, however.  It's a siren song that ultimately leads
 > to disaster, because the mental complexity growth is *very*
 > non-linear.

How would you code the images in the book?

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

Received on Sunday, 8 January 2012 03:57:13 UTC