Critique CSS layout (issues addressed)

[lime]

I have addressed most of the issues listed in the responses to my last post
"Critique CSS layout (1st go - fingers crossed)". I'm rapt with the progress
I have made, thanks to all for your past critiques.

http://www.limelightstudio.com.au/iss/8/

The issues addressed:

- Nav uses <li> now
- No horizontal scroll in IE6 at 850-900 pixels
- Nav area not fixed, fluid now
- Added <h#> markup to replace <div>
- Changed CAPS
- Darker body text
- Changed footer layout & colour
- Made nav links different on hover
- Mis-alignment of banner in Opera

It's amazing how much easier CSS layout is when using the correct <h#>
markup....

Note: Links don't go anywhere. Font size has remained the same.

 

[rf]

http://www.limelightstudio.com.au/iss/8/

Why do you waste about 20% if my canvas, on the right hand side. Surely the
text could wrap near the right hand side of my window?

 

[Martin Bialasinski]

Why do you waste about 20% if my canvas, on the right hand side. Surely the
text could wrap near the right hand side of my window?

Limiting the length of a line is not unreasonable. Depending of the
size of the font, the outline of the font, the line height, the
inter-word spacing and the font-stretch, there is a point when lines
get too long for good readability.

You won't find a text printed with a 8pt ultra-condensed font with 1ex
line height on A4 landscape very readable, won't you?

Whether the line width chosen by lime is sensible, is
debatable. First of all, it is not dependant on the font
size. Someone with bad eyesight, who has overridden the font sizes to
something larger, will find it to short.

A better way would be something in the lines of
http://www.uni-koeln.de/~agr30/iss/limelightstudio.com.auiss8.html

(tested in Opera and Firefox). You can zoom in and out without
destroying to layout (ctrl + Num+ and Num- in Firefox). Maybe lime can
consider something in these lines and reconsider to not touch the
fontsize for the content. Using s smaller size for things like the
page footer is OK, IMHO.

I too find many websites having too small a fontsize. Thanks god,
Opera allows to set a minimum fontsize that can not be overridden by
css (mine is set to 14px, which is also the 100% fontsize I configured).

Bye,
Martin

 

[Rijk van Geijtenbeek]

Why do you waste about 20% if my canvas, on the right hand side. Surely
the text could wrap near the right hand side of my window?

Easy reading? I don't mind at all. Depends a lot on your window size I
suppose, but full length text isn't always a good thing...

Maybe adding:

min-width: 30em;

to the rules for #mmhidemiddlebox might be nice.

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

 

[lime]

"rf" wrote in message ...

Why do you waste about 20% if my canvas, on the right hand side. Surely
the
text could wrap near the right hand side of my window?

For you it may be wastage (such a pessimist aren't you ;o)) for me it was
limiting the length of text for readability.

 

[lime]

"Martin Bialasinski" wrote in message ...

A better way would be something in the lines of
http://www.uni-koeln.de/~agr30/iss/limelightstudio.com.auiss8.html

(tested in Opera and Firefox). You can zoom in and out without
destroying to layout (ctrl + Num+ and Num- in Firefox). Maybe lime can
consider something in these lines and reconsider to not touch the
fontsize for the content. Using s smaller size for things like the
page footer is OK, IMHO.

Hi Martin, thanks for your effort. I've saved the CSS you've created to have
a more detailed look later on to learn what you have done there.

I agree about the footer text - leaving that smaller and I will do a version
with 100% body text too.

 

[lime]

"Rijk van Geijtenbeek" wrote in message...

Easy reading? I don't mind at all. Depends a lot on your window size I
suppose, but full length text isn't always a good thing...

Maybe adding:

min-width: 30em;

to the rules for #mmhidemiddlebox might be nice.

I will give that a go as well (I think that's what Martin did in his version
of the page too)

 

[kchayka]

"rf" wrote in message ...

For you it may be wastage (such a pessimist aren't you ;o)) for me it was
limiting the length of text for readability.

You must be assuming a certain window size and/or text size. Don't.

With smaller windows, 60% width for the content area can make for
too-short lines of text, which is also a readability problem. Ditto with
larger text sizes. BTW, your body text size is still much too small.

 

[Neal]

For you it may be wastage ... for me it was
limiting the length of text for readability.

Ok. How about your user. What's their viewport size? Hmm?

Answer: You dunno.

So what?

 

[lime]

"kchayka" wrote in message ...

You must be assuming a certain window size and/or text size. Don't.

With smaller windows, 60% width for the content area can make for
too-short lines of text, which is also a readability problem. Ditto with
larger text sizes. BTW, your body text size is still much too small.

True - you have a point.

 

[lime]

"Neal" wrote in message :

Ok. How about your user. What's their viewport size? Hmm?

Answer: You dunno.
True.


So what?

put it back to normal...

 

[Chris Beall]

For you it may be wastage (such a pessimist aren't you ;o)) for me it was
limiting the length of text for readability.

Here's a quote on the subject:

"Line length
The recommended number of characters in a
line does not vary between the medium of
paper and screen, however. A range of 65–75
characters per line is a comfortable maximum
for a single column of text in print, with a
range of 30-40 characters per line common in
multicolumn layouts. The reason for this maximum
is based on the characteristics of our
visual system. We scan a line of text in groups
of letters, first picking up the exterior shapes of
word groups, then decoding words as our eye
bounces along from left to right. The sweeping
motion of turning our eye back to the left
becomes increasingly difficult as the line gets
longer. Our ability to pick the start of the next
line is decreased by combinations of long lines,
tight line spacing, and lack of white space on
the left-hand margin."

This is from
http://www.kahnplus.com/download/pdf/uitype_interactions.pdf, which has
lots of discussion of text presentation considerations.

Another rule of thumb I vaguely recall is that line length in any given
font should not exceed the length of the combined upper and lower case
alphabet in that font.

In either case, you have to express the desired max-width in terms of
ems, so that it will scale with the choice of font and font size. And
the results will vary a bit depending on which font is actually used by
the browser. Max-width: 30em seems to come pretty close for most cases
I tested.

And, of course, the browser has to support max-width...

Chris Beall

 

[Christoph Paeper]

In either case, you have to express the desired max-width in terms of
ems, so that it will scale with the choice of font and font size.

'ex' should be even more appropriate.

Max-width: 30em seems to come pretty close for most cases

Although it comes often close to the traditional recommendation, it's too
narrow, because scrolling is also a (negative) factor, that doesn't have
to be considered in paged media, where it's easier to find the next first
word of a page or column.

 

[Chris Beall]

Christoph Paeper wrote:
(snip)

'ex' should be even more appropriate.

Agreed. That might resolve a problem I had with a couple of the fonts I
tested. 'ex' hasn't been brought up much here; I had to go look it up.

Although it comes often close to the traditional recommendation, it's
too narrow, because scrolling is also a (negative) factor, that doesn't
have to be considered in paged media, where it's easier to find the
next first word of a page or column.

We're into a very subjective area here. I see two conflicting goals.
To minimize the NEED for vertical scrolling, we want the longest
possible line length, so as to get as much text as possible 'above the
fold', but once scrolling is required, we've aggravated the normal
printed-media situation, since all of our visual reference points will
jump during the scroll, giving our visual system a real challenge to
keep its place. That would argue for shorter-than-print-media lines.

Since we can't control the window or font size, I'd vote for assuming
that we have little control over what stays above the fold and thus
should assume vertical scrolling WILL be needed and thus opt for short
line lengths. But that's my abstract opinion. In any given case I'd
want to look at the page in totality to see what works best (under a
wide variety of conditions).

30em or about 65ex seems like a good starting point.

Chris Beall

 

[Stephen Poley]

Christoph Paeper wrote:
(snip)

Agreed. That might resolve a problem I had with a couple of the fonts I
tested. 'ex' hasn't been brought up much here; I had to go look it up.

Not agreed. I spent sometime investigating this and came to the
conclusion that ex was no improvement at all. It might be for some
specific fonts, but worse for other fonts - and for most browsers it
just seems irrelevant anyway. See
http://www.xs4all.nl/~sbpoley/webmatters/emex.html