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

On Thu, Dec 29, 2011 at 1:12 AM, Håkon Wium Lie <howcome@opera.com> wrote:
> Tab wrote:
>
>  > > - the layout is fixed; there is no way to add more columns if more
>  > >  content is poured into the flow, and the size and aspect ratio of
>  > >  the image is fixed
>  >
>  > Sure, because in that code I was doing a direct adaptation of the
>  > existing code.  That is not, in general, a failing of Grid.  Imagine
>  > other uses for Grid that might benefit from region-based styling.
>
> Ok, so the canonical regions example isn't suitable for grids. Fair
> enough. But which use case are? Could you give an example of a
> suitable use case, with code to illustrate? Code that doesn't have the
> problems discussed in this thread?

Well, it *can* be appropriate for Grid, if we understand what the
behavior should be as you add more text.  The example as written
doesn't allow for more text (or rather, it assumes there's some
unwritten rules that move extra text into another region/page later
on).

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?  These would then move to the next page if necessary, as
usual for multicol overflow columns.

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


> 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.  The spanner is
also enclosed in an anonymous BFC.  If I fill in a lot of blanks
myself, I think you're implying that integer column-spans also have
this effect, 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.


>  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.  I'm
further confused at how a column box can, itself, be spanning columns.
 Does it only span columns that are somehow still "column-y"?  How do
you determine when a column is no longer "column-y"?  What would
happen if I made, say, column #3 also float?


>  > 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.)


>  > My own experiences as a web designer, and what I've heard
>  > and seen from other webdevs, is that float-based layout was a terrible
>  > hack that happened to accomplish really useful things at the time,
>  > like table-based layouts further in the past.  I would not inflict
>  > such things on the future, especially not in the more complicated form
>  > you're demonstrating here.
>
> 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.

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.

~TJ

Received on Tuesday, 3 January 2012 19:03:33 UTC