Thoughts and suggestions for our project website

[dorayme]

<snipped>

Thanks for the comment about the "nice clean look" - that's exactly what we
went for. Another poster called the design a bit bland, well, it's actually
meant to be that way. Not boring, but we didn't want to go over the top
with colours and animations and stuff...

Don't worry about bland, if you look around, it is obvious that
the human taste is big on garish.

The footer looks much nicer now.

Perhaps it is a small point or you missed it before:

<http://netweaver.com.au/alt/pics/bg_for_current_mixed_with_bg_for
_hover.png> where the arrow is the cursor and causes the
background on hover to be the same as the current "home" page bg.
It is slightly distracting/confusing. If it at all concerns you,
either have another way of marking current or else a different
way of marking hovering.

There are some (more) important issues too but I am not sure you
want to go into them? There is your .8em font-size and your 1.6em
line-height. I would not be happy with these. If you must have a
line height, be careful, there are some tricky issues using em
units (briefly, the gaps are set in concrete and do not vary
proportionally with the font-size in descendants). Safer to use
pure numbers. Perhaps 1.4 might do you? We must not be too wild.

And .8em is too small. Why not put body: {font-size: 100%;} to
cope with some problems that IE has or nothing at all about
font-size for main body text. Certainly do not go below .9em for
material that needs continuous reading, .9em is bad enough <g>

 

[Guest]

The footer looks much nicer now.

Thanks - looking back to how it was, I agree.

Perhaps it is a small point or you missed it before:
<http://netweaver.com.au/alt/pics/bg_for_current_mixed_with_bg_for
_hover.png> where the arrow is the cursor and causes the
background on hover to be the same as the current "home" page bg.
It is slightly distracting/confusing. If it at all concerns you,
either have another way of marking current or else a different
way of marking hovering.

I'm thinking along the lines of removing the hovering cursor, and only keep
the cursor for the active menu item. At least that would solve the
confusion.

There are some (more) important issues too but I am not sure you
want to go into them? There is your .8em font-size and your 1.6em
line-height. I would not be happy with these. If you must have a
line height, be careful, there are some tricky issues using em
units (briefly, the gaps are set in concrete and do not vary
proportionally with the font-size in descendants). Safer to use
pure numbers. Perhaps 1.4 might do you? We must not be too wild.

I'd very much like to go into these issues - whatever benefits the visitor,
can only be considered a plus imho.

And .8em is too small. Why not put body: {font-size: 100%;} to
cope with some problems that IE has or nothing at all about
font-size for main body text. Certainly do not go below .9em for
material that needs continuous reading, .9em is bad enough <g>

Over the next few days, I'm planning to add some new content to the site.
I'll have a go at a new approach to the different font-sizes, and I'll get
back here so you and everyone can check whether or not it's an improvement.

Thanks,

Ivana

 

[Guest]

Why attribute if you're not going to quote anything?

Why not? I wanted to thank everyone for their input, so there's no need to
quote for that.

Further more, I've devoted an article to their input, but there's no need
to go into that in this group as I can imagine the regulars considering
this off-topic for alt.html .

Ivana

 

[Els]

Why not? I wanted to thank everyone for their input, so there's no need to
quote for that.

He said "attribute", not "contribute" ;-)
If you're not quoting what Blinky said, there's no need to have
"Blinky wrote" at the top

 

[Blinky the Shark]

Why not? I wanted to thank everyone for their input, so there's no need to
quote for that.

And no need to attribute, either. Since there's nothing *to* attribute.

Perhaps you don't understand the word "attribute".

 

[Guest]

And no need to attribute, either. Since there's nothing *to*
attribute.

Perhaps you don't understand the word "attribute".

Els already pointed out my mistake in her post. Not being a native English
speaker, I indeed got "to contribute" and "to attribute" mixed up.

Another lesson learned

Ivana

 

[dorayme]

Thanks - looking back to how it was, I agree.


I'd very much like to go into these issues - whatever benefits the visitor,
can only be considered a plus imho.

Here is a first draft of something I made on line-height. if
there is anything unclear or wrong I will correct it:

<http://netweaver.com.au/alt/line-height_demo.html>

 

[Ben C]

Here is a first draft of something I made on line-height. if
there is anything unclear or wrong I will correct it:

<http://netweaver.com.au/alt/line-height_demo.html>

Line-height and vertical-align are the most obscure things in the whole
of CSS 2.1, and you got little or nothing wrong that I can see, but some
comments:

In a line of text, or text and pictures, there's an imaginary
rectangle that encloses all the things on the line. This rectangle
is called a line box. Line boxes stack vertically when text wraps.
How high these boxes are is determined by the line-height.

Line box height is a function of the font-size, vertical-align and
line-height of each of the inline boxes on the line, and is at least as
high as the line-height set on the container (unless you're in quirks
mode...).

If you ask me setting line-height on the container to set a minimum
height for the line-boxes, as your examples are doing, is the most
intuitive way to use line-height (has anyone ever set line-height on
inline boxes, except just to prevent it being inherited so that they can
do vertical-alignment effects? If so, why?).

So perhaps it's not totally precise to say "is determined by". You could
say the height of a line box depends in a complicated way on the things
in it, but you can set a minimum by setting line height on the
container.

They are at least as tall as the tallest of the objects in them,
commonsensical enough. But this minimal height is not very
satisfactory when there are wrapped lines of text, there needs to be
more breathing space, more space above and below the content.

Default line-height is usually a bit more than the bare minimum required
for the things on the line. It's usually about 1.1 or 1.2 times the
font-size, and most browsers base it on the "line-gap" value built into
the font.

So for some fonts, you will find default line-height is 1.123 times
font-size, for others 1.234, etc.

 

[dorayme]

Line-height and vertical-align are the most obscure things in the whole
of CSS 2.1, and you got little or nothing wrong that I can see, but some
comments:

In a line of text, or text and pictures, there's an imaginary
rectangle that encloses all the things on the line. This rectangle
is called a line box. Line boxes stack vertically when text wraps.
How high these boxes are is determined by the line-height.

Line box height is a function of the font-size, vertical-align and
line-height of each of the inline boxes on the line, and is at least as
high as the line-height set on the container (unless you're in quirks
mode...).

Yes. I was *imagining* the following:

(1) The 4 main specified rules in CSS 2.1 at 10.8

(2) No default provided by a browser and no line-height set by an
author. Just to abstract them for a moment.

(3) Any default for vertical-align.

and then looking to see what might then naturally result. I
concluded that the line box would then just fit everything in, no
grace at top or bottom. That seemed to me a straightforward
commonsense handle.

Of course, browsers are smart and have defaults to give grace.

Given that there is set (by default or by author) a line-height
*equal to or bigger than* the naturally stingy minimum, this
alone, this actual line-height specification is the height of the
line box.

If you ask me setting line-height on the container to set a minimum
height for the line-boxes, as your examples are doing, is the most
intuitive way to use line-height (has anyone ever set line-height on
inline boxes, except just to prevent it being inherited so that they can
do vertical-alignment effects? If so, why?).

So perhaps it's not totally precise to say "is determined by". You could
say the height of a line box depends in a complicated way on the things
in it, but you can set a minimum by setting line height on the
container.

I was thinking, given one abstracts out the default grace as
explained above, that the line height is then very simply
determined:

"The line box height is the distance between the uppermost box
top and the lowermost box bottom."

But I am nowhere finished on all this. I find it interesting and
I have not included some drafts of some quixotic and even amusing
differences in interpretation between browsers under various
conditions.

Actually, thanks for your remark on the particular sentence.
While typing this, I realise it is not quite appropriate. "how
high these (line) boxes are" *is* the height of the line box. The
initial determination is something more complicated, either as
you mention, a natural combination of things, or as I explain in
this reply above, the "generous" line-height.

They are at least as tall as the tallest of the objects in them,
commonsensical enough. But this minimal height is not very
satisfactory when there are wrapped lines of text, there needs to be
more breathing space, more space above and below the content.

Default line-height is usually a bit more than the bare minimum required
for the things on the line. It's usually about 1.1 or 1.2 times the
font-size, and most browsers base it on the "line-gap" value built into
the font.

So for some fonts, you will find default line-height is 1.123 times
font-size, for others 1.234, etc.

Of course, yes. You will see how I am not going into these
issues, the focus being the difference between a united and an
un-united line height specification.

 

[Ben C]

Yes. I was *imagining* the following:

(1) The 4 main specified rules in CSS 2.1 at 10.8

(2) No default provided by a browser and no line-height set by an
author. Just to abstract them for a moment.

(3) Any default for vertical-align.

and then looking to see what might then naturally result. I
concluded that the line box would then just fit everything in, no
grace at top or bottom. That seemed to me a straightforward
commonsense handle.

Of course, browsers are smart and have defaults to give grace.

Given that there is set (by default or by author) a line-height
*equal to or bigger than* the naturally stingy minimum, this
alone, this actual line-height specification is the height of the
line box.

Generally, although a nasty case of vertical-align can cause a bigger
line box height, in spite of a small specified font-size and large
line-height.

Here is an example: http://www.tidraso.co.uk/misc/linebox-height.html

I merely point these things out. I think your explanation is clearer if
it doesn't explain vertical-align in too much detail to start with and
just concentrates on line-height.

 

[dorayme]

Generally, although a nasty case of vertical-align can cause a bigger
line box height, in spite of a small specified font-size and large
line-height.

Here is an example: http://www.tidraso.co.uk/misc/linebox-height.html

I merely point these things out. I think your explanation is clearer if
it doesn't explain vertical-align in too much detail to start with and
just concentrates on line-height.

Fair enough. It never actually occurred to me to say much at all
about vertical align in the above url. At the last minute, in one
draft, I threw in a mere reference to it - I am not sure it is
still there.

I have a whole lot of stuff on line-height and vertical align and
its effects in different browsers, it's in chaotic form! Must
shape it and put it up. I liked your example (it works in FF)!
Both it and my own examples of various things in this area are
remarkably different in different browsers.

Firefox takes silly very seriously (thank god) but Safari and IE
will have none of it quite often, call them the humourless
browsers - although, on some things like specifying line-height:
0; iCab has a pretty funny reaction!

 

[Ben C]

Fair enough. It never actually occurred to me to say much at all
about vertical align in the above url. At the last minute, in one
draft, I threw in a mere reference to it - I am not sure it is
still there.

I meant "if" in the sense of "since". I just started throwing herrings
about vertical-align around for the sake of completeness.

 

[dorayme]

I meant "if" in the sense of "since". I just started throwing herrings
about vertical-align around for the sake of completeness.

I like all these herrings. They are food for thought. Talking of
food and herrings, I grew up on kippers... <g>

 

[Phil Kempster]

I like all these herrings. They are food for thought. Talking of
food and herrings, I grew up on kippers... <g>

Do you come from Whitby by any chance? Like Capt'n Cook's boat?

 

[dorayme]

Do you come from Whitby by any chance? Like Capt'n Cook's boat?

I think everyone in England, at least in the north, ate kippers.
You can get them here in Australia too. For some reason, probably
because I would rust, I don't. They also stink the place out. I
had nothing to do with anything when I was a kid, I ate what I
was given. To answer your question though, no - more the
Manchester side of the island was the little me.

 

[asdf]

I think everyone in England, at least in the north, ate kippers.
You can get them here in Australia too. For some reason, probably
because I would rust, I don't. They also stink the place out. I
had nothing to do with anything when I was a kid, I ate what I
was given. To answer your question though, no - more the
Manchester side of the island was the little me.

Nothing beats Loch Fyne kippers, though, especially for breakfast