Re: My #1 request for CSS3

>Håkon Wium Lie wrote:

>Several proposals on multi-column layout has been floating around (so
>to say) for some time. Here's a simple proposal from July 96:
>
>   http://www.w3.org/Style/CSS/multi-column

That's definitely a start.


>We probably want to add support for columns of variable widths, as
>well as non-shorthand properties.

Definitely. Might as well do it right.


>You can do this with media-dependent style sheets:
>
>  @media handheld {
>     BODY { columns: 1 }
>  }
>  @media screen {
>     BODY { columns: 2 }
>  }

I'd assumed you probably could do this via meda formats, and of course the
same thing should also be available via an "auto" feature, which could be
done by setting a minimum/maximum width, as your original proposal
suggested. However, I have a feeling that it would be hard for an "auto"
feature to handle mixed-width columns, so this could be useful in this sort
of situation, which is an argument for making it accessible via the DOM.

Doing so allows for subtler adjustments, if desired. For example, "media
screen" might include anything from 640x480 to 1024x768. A line that runs
the full width of the latter just ain't likely to be readable. Therefore
(assuming you can check monitor resolution), you could switch from a single
column to two columns for a wider screen. Likewise, the reader could also
decide to switch to a multi-column format.


>Also, by setting the column widht to be an 'em' value, you would
>achieve fluid designs automatically:
>
>  BODY { columns: 10em }

Using ems to set a minimum/maximum width is a good way to do this, but
again I'd also like to make this adjustable based on screen width to
provide more flexibility.


>Braden N. McDaniel wrote:
>
>The traditional print media have a constraint that makes this a lot more
>workable: the page has a very definition notion of a "bottom". The Web page
>has no such notion. As such, users may very likely find themselves not only
>having to scroll down the page to read the text, but to scroll *back to the
>top* to start reading the next column! The annoyance this produces obviously
>increases markedly with each additional column.

Of course there are trade-offs, but this isn't much different than having
to turn to a different page in the print world.

However, this is an issue that can be dealt with by providing a "header"
and "footer" areas to each column where internal links could be placed.
This would allow "next column" and "previous column" links. I've seen
similiar things done with TABLE used for layouts, like so:

<TR>
  <TD>
    Column 1 top anchor
  </TD>
  <TD>
    Column 2 top anchor
    Link back to bottom of column 1
   </TD>
</TR>

<TR>
  <TD>Column 1 text</TD>
  <TD>Column 2 text</TD>
</TR>

<TR>
  <TD>
    Column 1 bottom anchor
    Link to top of Column 2
  </TD>
  <TD>
    Link to column 1 top anchor (aka beginning of text)
  </TD>
</TR>

Obviously a dedicated multi-columns tag would be more flexible, since this
TABLE-based kludge can't reflow text among columns.

I'm not sure how the syntax would work, since you're in effect
incapsulating a link tag within the columns tag.

Maybe a solution is to use a positioning element that would allow an item
to be placed in a SPAN tag. For example:

<SPAN STYLE="columns-col: 1; columns-position: bottom">
  <A HREF="#top_of_col2">More content</A>
</SPAN>

which would position an item at the bottom of a column 1 and allow other
text in the column to flow around it. The second example would set up the
target link at the top of the second column:

<SPAN STYLE="columns-col: 2; columns-position: top">
  <A NAME="top_of_col2"></A>
</SPAN>

This would also allow you to set up all your "next"/"previous" links at the
beginning of the multi-column area for easier reference.


An additional solution might be to also allow control over the height of
each column, so for example, you could say:

I want two columns that are x ems | pixels | lines | whatever high. If the
text is longer than these two columns, start another row of two columns
below the first row; continue doing this until you run out of text.

(This is almost identical to what you can do with a page-layout program
like QuarkXPress, when you "auto-flow" text, so on the rendering side of
things, it's a problem that's long been solved.)


George Olsen                                     mailto:golsen@2lm.com
Design Director                                     http://www.2lm.com
2-Lane Media                                   tel: 310/473-3706 x2225

Received on Monday, 8 February 1999 22:00:21 UTC