Problems with cascade in menus

dorayme wrote:

...
The trouble with percentage width is often that it does not relate well
to stable content. Imagine a user is happy with his font-size, but
changes his browser width. The width of a column he could perfectly well
read before is now unnecessarily wide. This growth serves no function
here.

Compare this with sizing a side column in ems. Here the width will not
grow just because the user widens his window. And this is perfect if it
was perfectly adequate before. Compare it also with sizing a col in
pixels, the same thing applies in respect to these conditions.

One downside of em widthing is that the col grows wider on text up! Yes,
that is what it is meant to do. But this is not always what is best for
a side column. Better sometimes for it to be fixed in px and the text
wrap earlier. Sure, the danger is it will spill out if the text is upped
real big. Your job is to catch the likelihoods and allow sufficient
room, nothing is perfect.

So, it is all swings and roundabouts. If I have time later, I will take
another look.

Thank-you for those thoughts. With CSS it seems to be all "swings and

roundabouts". One thing that I should consider is - do I need all those
buttons - which is the reason for the min-width? I could set the
minimum width to be a lot smaller by removing two of the buttons. (I
might try that later today to see how it looks, as part of a concerted
procrastination effort to avoid the documentation that I should be doing.)

I like the ability to change the column width, because I have found
there is a certain width (and I don't know what it is empirically - but
I know it when I see it!) that I like to have to read most easily, and I
get frustrated with web sites that don't allow me to change the width of
the 'main column'. And for me the easiest adjustment is just to drag the
browser wider (or narrower). The worst offenders for me are the sites
that have it so wide that I have to scroll sideways to read it. Which
is why I have some sympathy for the comments made elsewhere about the
scroll bar -- and why I am allowing myself this procrastination today!

.... (a little while later)...
.... (and some considerable 'crastinationg )...

Ok, I have taken two buttons and reduced min width from 80em to 60em,
which should fix most of the width issue (74em for IE), perhaps even in
FF2. Actually, I think this configuration of the buttons makes more
sense too. Is this better?

In article <1218071331.86255 (AT) angel (DOT) amnet.net.au>,
David Morris <dlmorrisDONTSPAM (AT) netwizDONTSPAM (DOT) com.au> wrote:

dorayme wrote:
...
The trouble with percentage width is often that it does not relate well
to stable content. Imagine a user is happy with his font-size, but
changes his browser width. The width of a column he could perfectly well
read before is now unnecessarily wide. This growth serves no function
here.

Compare this with ...Your job is to catch the likelihoods and allow
sufficient
room, nothing is perfect.

So, it is all swings and roundabouts. If I have time later, I will take
another look.

Thank-you for those thoughts. With CSS it seems to be all "swings and
roundabouts".

Ok, I have taken two buttons and reduced min width from 80em to 60em,
which should fix most of the width issue (74em for IE), perhaps even in
FF2. Actually, I think this configuration of the buttons makes more
sense too. Is this better?

Yes. It is better for me to read now. Well done.

Now, perhaps have a look to reduce the left margin or padding at far
left of the whole show *a bit* so that it is not so constant at reduced
browser widths. If somehow you can get the left margin (and right if you
care) to vary with browser width, then you achieve both looks and
functionality. The latter because where space is at a premium on a
screen, you need to keep the not very functional space on the left to a
minimum. At more generous browser widths, this space then gives grace
(when there is room for generosity). I notice that you have a number of
boxes on the left and each has a left padding it seems. The background
is all white so you could reduce the padding a bit.

..mnupannelleft{
padding: 0;
margin-top: 80px;
margin-right: 18px;
text-align: right;
font-size:.9em;
}

I would be inclined to bring down the text size of the left side
information a touch. It is not for general reading and .9 or .85em would
be fine, especially as you bold various important bits.

I notice the font size system you use keeps enraging some folks <g>.
What is ultimately important is the result for the user. Your text is
all pretty good.

For what it is worth, I favour a very simple system, in the CSS 100% for
body, tweak just very few things up or down, body text leave well alone
to enjoy the 100%, navigation, especially horizontal strip ones I mostly
bring down to .85 or .9 unless there are very few list items, headings
vary of course and that is that. The obvious advantage of this for the
author is that it is dead simple to do and maintain.

--
dorayme

dorayme wrote:

(when there is room for generosity). I notice that you have a number of
boxes on the left and each has a left padding it seems. The background
is all white so you could reduce the padding a bit.

.mnupannelleft{
padding: 0;
margin-top: 80px;
margin-right: 18px;
text-align: right;
font-size:.9em;
}

I would be inclined to bring down the text size of the left side
information a touch. It is not for general reading and .9 or .85em would
be fine, especially as you bold various important bits.

I have had a bit of a play with it, but nothing too drastic. Rather
hamstrung by the different word wrapping of the @netwiz.com.au. I also
didn't want to take the font size down too far as to make it not
readable at the smallest IE6 font size (or two Ctrl<-> in FF), though as
you say, not a critical area.

I notice the font size system you use keeps enraging some folks <g>.

Yes. I generally find their comments have religious content, rather
than art or a science, so I am somewhat confounded by the fuss.

What is ultimately important is the result for the user. Your text is
all pretty good.

Thank-you. I agree.

For what it is worth, I favour a very simple system, in the CSS 100% for
body, tweak just very few things up or down, body text leave well alone
to enjoy the 100%, navigation, especially horizontal strip ones I mostly
bring down to .85 or .9 unless there are very few list items, headings
vary of course and that is that. The obvious advantage of this for the
author is that it is dead simple to do and maintain.

I do wonder if this is why I have problems trying to change the fonts
sizes in authorit.css. They grow and shrink rather unexpectedly for me,
though this is probably a result of me not all together getting
descendants in CSS when using ems (c.f. 6.1.2 Computed values and 6.2
Inheritance in the spec) more than anything. Doing it for simplicity
is, ironically, exactly the reason I did this in the first place, that
is, to make doing the menu easier as 1.2em equals 12px -- so any change
now won't be with out a lot of pain.

David Morris wrote:

Stan Brown wrote:

So you are saying that someone should change their browser to
compensate for bad Web page authoring? Yeah, that's gonna be real
popular with your visitors.

What I suspected and the author has admitted, was he was just 'sounding
off' (and rather off topic too).

I admit no such thing. It's not off topic, either. Clagnut has been
discussed in this group several times already.

I actually am not aware of anyone who
says the page is unreadable.
The only hard evidence in support of an observable problem has been the
min-font size in FF2

And Seamonkey, and Opera, perhaps other browsers as well.

which if set caused the fonts to appear
unnecessarily large. This was fixed in FF3.

I don't understand why this is such a hard concept for clagnut followers
to grasp: You can get the exact same result (smaller, deeziner type
sizes) by *not* doing this foolish thing, and have no ill effects on
*any* browser.

Besides that, your CSS will be trimmer and easier to maintain. It's a
win-win situation for users and developers alike. Why do you (that's the
collective you) refuse to even consider this?

I have as you should be aware, made a considerable effort to make my
site work in a number of browsers.

If you abandon clagnut, it would work in even more browsers, with less
effort on your part, too.

FireFox 2 will work well with
default settings.

And there's the rub - those of us who cannot live with default settings
are punished for it. :-( You try running your browser at a 17px minimum
font size for a while and maybe you'll start seeing the error of your ways.

--
Berg

David Morris wrote:

Ed Mullen wrote:
David Morris wrote:
dorayme wrote:

resolution is 1280 x 1024. But I don't necessarily want to always use
my browser full screen. My minimum font size in SeaMonkey is 13.

http://edmullen.net/temp/dm.jpg


I tried to replicate your screen shot in FF3, and the center column text
was visible as per my previous comments, in fact I then set min size to
14 and it was still visible. Since Sea Monkey is based on Mozilla code,
is it possible that Sea Monkey is using FF2?

I just compared FF and Sm. they both can force horizontal scrolling if
their windows are compressed enough. However, it's not as bad as when I
took that screen shot so I must assume you've changed something.

--
Ed Mullen
http://edmullen.net
Bad breath is better than no breath.

David Morris wrote:

Ed Mullen wrote:
David Morris wrote:
dorayme wrote:

resolution is 1280 x 1024. But I don't necessarily want to always use
my browser full screen. My minimum font size in SeaMonkey is 13.

http://edmullen.net/temp/dm.jpg


I tried to replicate your screen shot in FF3, and the center column text
was visible as per my previous comments, in fact I then set min size to
14 and it was still visible. Since Sea Monkey is based on Mozilla code,
is it possible that Sea Monkey is using FF2?

I just compared FF and Sm. they both can force horizontal scrolling if
their windows are compressed enough. However, it's not as bad as when I
took that screen shot so I must assume you've changed something.

--
Ed Mullen
http://edmullen.net
Bad breath is better than no breath.

David Morris wrote:

Ok, I have taken two buttons and reduced min width from 80em to 60em,
which should fix most of the width issue (74em for IE), perhaps even in
FF2.

When I see comments like this in a stylesheet, it's a dead give-away
that the author is confused at best:

/* We add this because Konquerer (at least 3.3.3 "release 45")
doesn't calculate 64em to be 768px - but we will keep using em

Why do you think 64em should *ever* equal 768px? There is absolutely no
relationship between em and px. This is your downfall - expecting
everyone to use particular browser default text sizes.

Ever think about what happens to someone using extra large text? That
60em min-width may very well be wider than their screen, so there may be
excessive horizontal scrolling even running a maximized browser.

Change that min-width to max-width and you might have something useful.

--
Berg

Ed Mullen wrote:

David Morris wrote:
Ed Mullen wrote:
David Morris wrote:
dorayme wrote:

resolution is 1280 x 1024. But I don't necessarily want to always
use my browser full screen. My minimum font size in SeaMonkey is 13.

http://edmullen.net/temp/dm.jpg


I tried to replicate your screen shot in FF3, and the center column
text was visible as per my previous comments, in fact I then set min
size to 14 and it was still visible. Since Sea Monkey is based on
Mozilla code, is it possible that Sea Monkey is using FF2?

I just compared FF and Sm. they both can force horizontal scrolling if
their windows are compressed enough. However, it's not as bad as when I
took that screen shot so I must assume you've changed something.

Yes, as discussed elseware in the thread, though my initial response was

made before I made those changes.

In article <1218081124.6196 (AT) angel (DOT) amnet.net.au>,
David Morris <dlmorrisDONTSPAM (AT) netwizDONTSPAM (DOT) com.au> wrote:

For what it is worth, I favour a very simple system, in the CSS 100% for
body, tweak just very few things up or down, body text leave well alone
to enjoy the 100%, navigation, especially horizontal strip ones I mostly
bring down to .85 or .9 unless there are very few list items, headings
vary of course and that is that. The obvious advantage of this for the
author is that it is dead simple to do and maintain.

I do wonder if this is why I have problems trying to change the fonts
sizes in authorit.css. They grow and shrink rather unexpectedly for me,
though this is probably a result of me not all together getting
descendants in CSS when using ems (c.f. 6.1.2 Computed values and 6.2
Inheritance in the spec) more than anything. Doing it for simplicity
is, ironically, exactly the reason I did this in the first place, that
is, to make doing the menu easier as 1.2em equals 12px -- so any change
now won't be with out a lot of pain.

You might find that so much attention to font specification is a
maintenance worry in the long term. But your mileage might vary. What
worries me about the approach is that you seem commited to so much font
specification. Look at how many times font-size etc is repeated. It is
nice if you can get to the stage where you can rely on the natural
cascade to work for you. I can understand that you have travelled a long
road and would be reluctant to do wholesale changes at this point. But I
just mention for the future at least.

I am not sure if you know there is an issue with line height being
specified in units. There could be some circumstances where you might
consciously want units but for the most part it is safest to use line
height as a mere proportion without units. I see that I have something
on this that explains the idea a bit:

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

--
dorayme

Bergamot wrote:

David Morris wrote:
Why do you think 64em should *ever* equal 768px? There is absolutely no
relationship between em and px. This is your downfall - expecting
everyone to use particular browser default text sizes.

The 'em' unit is equal to the computed value of the 'font-size' property
though it will be rounded, so while won't necessarily exactly be the
same in all browsers (IE seems a tiny bit smaller), given the same font
at the same size it should be about the same. The default size for
‘medium’ text in browsers is about 16px (that is, default body text).
If we change font size to 62.6 % we make 0.1em ~ 1px in most browsers.
(actually, all of the ones I tested except Konquerer - and perhaps IE
which I could deal with separately).

The comment was from early in testing when I may have been using a
different div font size in any case (it looks like a font size of
1.2em), and that whole section is now commented out as it wouldn't validate.

But you knew all that didn't you?