Re: My #1 request for CSS3

On Mon, 8 Feb 1999, George Olsen wrote:
> 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.

If you're going to do this kind of thing, checking for the screen
resolution isn't sufficient. You need to check the users font size
settings as well. If the font was chosen by someone who's legally
blind, then a single line on a 1024x768 screen might be unreadably
short for most people, and illegible if split into two columns.

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

Em's change with the font width, and make a better solution than the
screen width.

Actually, you don't want to check monitor resolution or screen width -
you want to check *window* width. And in ems. That lets you make
choices that are much less likely to produce garbage than checking
irrelevant information - like the physical screen width - or with
inadequate information - like the number of pixels wide something is.

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

Exactly - assuming that the different page is some arbitrary number of
pages forward/backward, and not simply the "next" page. Would a
skilled book designer like to comment on the sins of splitting
out-of-text objects and the references to them across page boundaries,
or should I dig out one of my texts on the subject?

> 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:

So to continue reading, I have to grab the mouse, move it over the
area of the link, click on the correct button, then move my hands back
to home position? Personally, I'd rather just hit the space bar. If my
browser will let me config something to make that possibly, I'll
certainly do it.

	<mike

Received on Monday, 8 February 1999 22:20:53 UTC