471,319 Members | 1,770 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

Problems with cascade in menus

As usual, it looks right in Firefox 3 but not in IE6.

See http://www.tc3.edu/instruct/sbrown/n.../indexgood.htm
for the desired behavior -- when you hover over the second or third
main menu item, a submenu appears and an item can be selected. (The
links don't go anywhere.) This works in FF and IE.
The style sheet is
http://www.tc3.edu/instruct/sbrown/prodrop4.css

But when I include my own style sheet
http://www.tc3.edu/instruct/sbrown/screen.css
in addition to prodrop4.css, then FF still works but IE now has a gap
between the main line and the sub-menus, so when you try to mouse to
a sub-menu the main item is no longer hovered and the sub-menu
disappears. See
http://www.tc3.edu/instruct/sbrown/n...s/indexbad.htm

I'm sure there's something about sizing or positioning of the sub-
menus (the inner ULs) isn't being explicitly specified in prodrop4,
but after a couple of hours with the Mozilla DOM inspector I haven't
been able to find it.

Can someone point out what I'm missing? Thanks!
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Jul 27 '08 #1
41 2407
Sun, 27 Jul 2008 16:07:39 -0400 from Stan Brown
<th************@fastmail.fm>:
But when I include my own style sheet
http://www.tc3.edu/instruct/sbrown/screen.css
in addition to prodrop4.css, then FF still works but IE now has a gap
between the main line and the sub-menus, so when you try to mouse to
a sub-menu the main item is no longer hovered and the sub-menu
disappears. See
http://www.tc3.edu/instruct/sbrown/n...s/indexbad.htm

I'm sure there's something about sizing or positioning of the sub-
menus (the inner ULs) isn't being explicitly specified in prodrop4,
but after a couple of hours with the Mozilla DOM inspector I haven't
been able to find it.

Can someone point out what I'm missing? Thanks!
I figured it out by systematically removing chunks of my own CSS
until the undesired behavior disappeared. It was a declaration
table { margin-top: 1em }

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Jul 29 '08 #2
Stan Brown wrote:
>
Can someone point out what I'm missing? Thanks!
Hi Stan,

I am not claiming any great expertise here, as much as anything because
when I went through this exercise a few months back I quickly discovered
that with CSS you couldn't really calculate what was going to happen,
you just had to try it out in as many browsers as possible, and attempt
to fix the broken bits (FF for me was the best starting point). It is
coding by trial and error - which means basically doing experiments.
And in any case I have now forgotten most of what I learnt.

So I have only quickly skimmed your CSS. I noticed that the body style
has some padding which will cascade down to other objects. Since older
version of IE had the box model inside out, you may be seeing some
effects of that. You might want to try zeroing that out, and if the
menu works identity the elements that need to have the padding zeroed.
Aug 3 '08 #3
Sun, 03 Aug 2008 08:35:04 +0800 from David Morris
<dl**************@netwizDONTSPAM.com.au>:
I noticed that the body style
has some padding which will cascade down to other objects. Since older
version of IE had the box model inside out, you may be seeing some
effects of that. You might want to try zeroing that out, and if the
menu works identity the elements that need to have the padding zeroed.
Thanks for the thought, David. I guess my article of 29 July never
reached your site. As I reported, I solved the problem by a divide-
and-conquer strategy. The working code is now at
http://www.tc3.edu/instruct/sbrown/stat5808b/

In Lynx, the menus show as nested lists, which seems to be a graceful
degradation.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Aug 3 '08 #4
Stan Brown wrote:
Sun, 03 Aug 2008 08:35:04 +0800 from David Morris
<dl**************@netwizDONTSPAM.com.au>:
Thanks for the thought, David. I guess my article of 29 July never
reached your site. As I reported, I solved the problem by a divide-
and-conquer strategy. The working code is now at
http://www.tc3.edu/instruct/sbrown/stat5808b/
Um nope. I guess the news server here doesn't get to see everything.
This might not be all bad!

Was that you who made the useful suggestions about spelling on my site?
Aug 3 '08 #5
Mon, 04 Aug 2008 06:37:44 +0800 from David Morris
<dl**************@netwizDONTSPAM.com.au>:
Was that you who made the useful suggestions about spelling on my site?
Maybe, but I have no memory of that, possibly because you didn't say
what your site is. :-)

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Aug 4 '08 #6
Stan Brown wrote:
Maybe, but I have no memory of that, possibly because you didn't say
what your site is. :-)
http://www.netwiz.com.au/cssmenu.html
Aug 4 '08 #7

David Morris wrote:
>
http://www.netwiz.com.au/cssmenu.html
/* We change font size to 62.6 % to make 0.1em == 1px. We then jump all
the other font sizes up and fix some of the cascading effects...

Another "clagnut" lemming, I see. <heavy sigh>

This is the stupidest method ever devised for sizing text. Will this
crap ever go away?

--
Berg
Aug 4 '08 #8
Bergamot wrote:
David Morris wrote:
>http://www.netwiz.com.au/cssmenu.html

/* We change font size to 62.6 % to make 0.1em == 1px. We then jump all
the other font sizes up and fix some of the cascading effects...

Another "clagnut" lemming, I see. <heavy sigh>

This is the stupidest method ever devised for sizing text. Will this
crap ever go away?
If you are not just sounding off because you think it makes you sound
good, and you really do have a problem with min-font size, upgrade to
FF3. The font sizes are fine there.
Aug 5 '08 #9

David Morris wrote:
Bergamot wrote:
>>
Another "clagnut" lemming, I see. <heavy sigh>
If you are not just sounding off because you think it makes you sound
good,
I'm sounding off because clagnut *is* the stupidest method ever devised
for sizing text. It needs to be abolished.
and you really do have a problem with min-font size, upgrade to
FF3.
Yes, I really do have a problem with minimum font size, but you couldn't
pay me to use Firefox. Any version. Or IE, or Safari, for that matter.
The font sizes are fine there.
Perhaps, but it has enough other deficiencies where it's a useless
browser to me.

--
Berg
Aug 5 '08 #10
On 2008-08-05, David Morris wrote:
Bergamot wrote:
>David Morris wrote:
>>http://www.netwiz.com.au/cssmenu.html

/* We change font size to 62.6 % to make 0.1em == 1px. We then jump all
the other font sizes up and fix some of the cascading effects...

Another "clagnut" lemming, I see. <heavy sigh>

This is the stupidest method ever devised for sizing text. Will this
crap ever go away?
If you are not just sounding off because you think it makes you sound
good, and you really do have a problem with min-font size, upgrade to
FF3. The font sizes are fine there.
No, they are not fine in FF3; they are too small for me to read.

If I set a minimum font size in FF, the page is too wide to fit on
my screen.

Using 'font-size: 62.5%' is one of the problems.

Both can be solved with a sensible stylesheet.

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
================================================== =================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Aug 5 '08 #11
Tue, 05 Aug 2008 08:25:03 +0800 from David Morris
<dl**************@netwizDONTSPAM.com.au>:
Bergamot wrote:
Another "clagnut" lemming, I see. <heavy sigh>

This is the stupidest method ever devised for sizing text. Will this
crap ever go away?
If you are not just sounding off because you think it makes you sound
good, and you really do have a problem with min-font size, upgrade to
FF3. The font sizes are fine there.
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.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Aug 6 '08 #12
Stan Brown wrote:
Tue, 05 Aug 2008 08:25:03 +0800 from David Morris
<dl**************@netwizDONTSPAM.com.au>:
>Bergamot wrote:
>>Another "clagnut" lemming, I see. <heavy sigh>

This is the stupidest method ever devised for sizing text. Will this
crap ever go away?
If you are not just sounding off because you think it makes you
sound good, and you really do have a problem with min-font size, upgrade
to FF3. The font sizes are fine there.
>
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 actually am not aware of anyone who
says the page is unreadable. (And if it is please send a screen shot
and browser details).

I hope you are not suggesting that my site is less usable than the
majority out there covering in Flash and Javascript?

The only hard evidence in support of an observable problem has been the
min-font size in FF2 which if set caused the fonts to appear
unnecessarily large. This was fixed in FF3. No doubt there are other
issues, but I have all ready conceded that my site won't work in some
early versions of Opera and some other browsers. I suspect neither will
yours.

I have as you should be aware, made a considerable effort to make my
site work in a number of browsers. FireFox 2 will work well with
default settings.
Aug 6 '08 #13
In article <12***************@angel.amnet.net.au>,
David Morris <dl**************@netwizDONTSPAM.com.auwrote:
The only hard evidence in support of an observable problem has been the
min-font size in FF2 which if set caused the fonts to appear
unnecessarily large. This was fixed in FF3.
If we are talking about

http://www.netwiz.com.au/cssmenu.html

I have no big problem using your site and I come in on this only to
mention that there seems so little reason for me to have to horizontally
scroll to see your material. But if you are not interested in this, I
won't stop to suggest a solution.

--
dorayme
Aug 6 '08 #14
dorayme wrote:
If we are talking about

http://www.netwiz.com.au/cssmenu.html

I have no big problem using your site and I come in on this only to
mention that there seems so little reason for me to have to horizontally
scroll to see your material. But if you are not interested in this, I
won't stop to suggest a solution.
Clever.

Horizontal scrolling is of course a usability issue. For me in FF3 with
min-font size at 14pt and screen width 1024, I can read the main body.
The right panel would need to be scrolled into view, but I don't see
that as important as it is a side panel for a reason. But I think that
would happen anyway since that is required for the menu, and while the
numbers would change the effect would be the same (I just didn't like
two rows of buttons - and that broke things). Without min-font set the
Horizontal scroll starts a little after 800 pixels.

I still have heaps on issues on the site. Starting with content and
spelling. I may change the body font size back to 100% in any case to
simplify some descendant styles (they will all need to be smaller of
course) as, despite the noble attempts of others here previously, I am
not locked into any position. Right now I can't change it since it will
break the menu. So, if and when I get around to it, it will be a big
job - and not one to be taken on lightly. So, if you have another
suggestion feel free.
Aug 6 '08 #15
In article <12***************@angel.amnet.net.au>,
David Morris <dl**************@netwizDONTSPAM.com.auwrote:
dorayme wrote:
If we are talking about

http://www.netwiz.com.au/cssmenu.html

I have no big problem using your site and I come in on this only to
mention that there seems so little reason for me to have to horizontally
scroll to see your material. But if you are not interested in this, I
won't stop to suggest a solution.
Clever.

Horizontal scrolling is of course a usability issue. For me in FF3 with
min-font size at 14pt and screen width 1024, I can read the main body.
The right panel would need to be scrolled into view, but I don't see
that as important as it is a side panel for a reason. But I think that
would happen anyway since that is required for the menu, and while the
numbers would change the effect would be the same (I just didn't like
two rows of buttons - and that broke things). Without min-font set the
Horizontal scroll starts a little after 800 pixels.

I still have heaps on issues on the site. Starting with content and
spelling. I may change the body font size back to 100% in any case to
simplify some descendant styles (they will all need to be smaller of
course) as, despite the noble attempts of others here previously, I am
not locked into any position. Right now I can't change it since it will
break the menu. So, if and when I get around to it, it will be a big
job - and not one to be taken on lightly. So, if you have another
suggestion feel free.
OK, I had not looked into the exact details but my experience tells me
that whenever there is no very wide pictures or other wide object to
account for it, there is generally a nice enough solution to what I was
complaining about. Not that it would stop me using your site (I don't go
off in huffs at the least little annoyance. Perhaps this is because of
my extreme maturity and calm nature, not to say very good looks, who
knows?

Perhaps I might just let you know the problem in case you come to think
about it later. When I get tired I up my text size quite a bit. When
that happens, I am forced to make my browser wider for your site to read
the paragraphs. It would be nice if this did not happen. Or if it
happened only in the presence of things which by their nature cannot
wrap.

I think the problem comes from your setting such fixed percentages for
the three main cols. But it is not a show stopper. And it is not all
that bad.

--
dorayme
Aug 6 '08 #16
dorayme wrote:
In article <12***************@angel.amnet.net.au>,
David Morris <dl**************@netwizDONTSPAM.com.auwrote:
OK, I had not looked into the exact details but my experience tells me
that whenever there is no very wide pictures or other wide object to
account for it, there is generally a nice enough solution to what I was
complaining about. Not that it would stop me using your site (I don't go
off in huffs at the least little annoyance. Perhaps this is because of
my extreme maturity and calm nature, not to say very good looks, who
knows?
Perhaps someone of an appropriate gender who knows you can judge your
looks, but I do appreciate your extreme maturity and calm nature, which
does seem to contrast somewhat with others I have seen in other threads.
Though, perhaps this is just relativity at work.
I think the problem comes from your setting such fixed percentages for
the three main cols. But it is not a show stopper. And it is not all
that bad.
Ok, that is something I could change easily (I think, maybe, perhaps).
What would you suggest? I went with percentages as it was likely to be
approximately proportionate with width:18%, width:64%, width:15%
respectively, with minimum width:90px on the outside two columns (I
forget the reason now but probably to stop the text getting to sub word
width). I can live with the outside columns being fixed, but I want the
center one to max out the space available.
Aug 6 '08 #17
David Morris wrote:
dorayme wrote:
>If we are talking about
http://www.netwiz.com.au/cssmenu.html

I have no big problem using your site and I come in on this only to
mention that there seems so little reason for me to have to
horizontally scroll to see your material. But if you are not
interested in this, I won't stop to suggest a solution.
Clever.

Horizontal scrolling is of course a usability issue. For me in FF3 with
min-font size at 14pt and screen width 1024, I can read the main body.
The right panel would need to be scrolled into view, but I don't see
that as important as it is a side panel for a reason. But I think that
would happen anyway since that is required for the menu, and while the
numbers would change the effect would be the same (I just didn't like
two rows of buttons - and that broke things). Without min-font set the
Horizontal scroll starts a little after 800 pixels.
The problem is you can't possibly know anything about a user's setup.
Here's a screen shot as I was looking at your site. My display
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

--
Ed Mullen
http://edmullen.net
Nothing says poor craftsmanship more than wrinkled duct tape.
Aug 6 '08 #18
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?
Aug 6 '08 #19
In article <12***************@angel.amnet.net.au>,
David Morris <dl**************@netwizDONTSPAM.com.auwrote:
I think the problem comes from your setting such fixed percentages for
the three main cols. But it is not a show stopper. And it is not all
that bad.

Ok, that is something I could change easily (I think, maybe, perhaps).
What would you suggest? I went with percentages as it was likely to be
approximately proportionate with width:18%, width:64%, width:15%
respectively, with minimum width:90px on the outside two columns (I
forget the reason now but probably to stop the text getting to sub word
width). I can live with the outside columns being fixed, but I want the
center one to max out the space available.
In many designs this is no problem, best not to specify a width for the
centre, just margins. I am sure you know this.

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.

--
dorayme
Aug 6 '08 #20
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?

Aug 7 '08 #21
In article <12**************@angel.amnet.net.au>,
David Morris <dl**************@netwizDONTSPAM.com.auwrote:
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
Aug 7 '08 #22
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.


Aug 7 '08 #23

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
Aug 7 '08 #24
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.
Aug 7 '08 #25

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
Aug 7 '08 #26
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.
Aug 7 '08 #27
In article <12*************@angel.amnet.net.au>,
David Morris <dl**************@netwizDONTSPAM.com.auwrote:
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
Aug 7 '08 #28
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?

Aug 7 '08 #29
dorayme wrote:
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.
Yes, both situations are true. I did the menu first and then set the
font sizes as that was by far the easier change (though I had a pretty
quick and dirty approach by then!).
>
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:
I thought 1.5em was proportional to the font-size of the parent element.
I was doing this because I had read somewhere that your eyes follow
text better if the line height is consistent, though I can't remember
where, and may have got in wrong in any event.
Aug 7 '08 #30
Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
<do************@optusnet.com.au>:
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>
Thanks for posting this. I don't specify text size in pixels, of
course, but I've been doing line heights in em or % rather than a
unitless proportion.

If I understand your page correctly, where problems come up in using
units for line-height is for inheritance nd not in the specific
selector where it's specified. Would that be an accurate summary?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Aug 7 '08 #31

David Morris wrote:
Bergamot 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
Which has nothing to do with px. 1em could be 10px or 30px.
The default size for
‘medium’ text in browsers is about 16px
So what? Not everyone uses those defaults, and that is where you are
failing. You are *depending* on your visitors using those defaults.
If we change font size to 62.6 % we make 0.1em ~ 1px in most browsers.
And what about the rest of us?

It all comes down to the insane desire to absolutely control the type
size of your visitors. Let that go and the web will be a happier place
for a lot of us.

If you insist on using smaller than 100% type for body text, there are
much better ways to do that without punishing those of us who need large
text.

--
Berg
Aug 7 '08 #32
In comp.infosystems.www.authoring.stylesheets message <1218013495.564458
@angel.amnet.net.au>, Wed, 6 Aug 2008 17:08:18, David Morris <dlmorrisDO
NT****@netwizDONTSPAM.com.auposted:
I actually am not aware of anyone who says the page is unreadable.
IE7, default settings.

It overrides my preferred text font with one which, for equal legibility
to me, needs to be larger. The lists, while not actually unreadable,
are undesirably small-font.

"(One would expect most Opera users to be using the very latest
version)" - but Opera 9.5 has dropped (AFAICS) a useful feature present
in 9.2 - CtrlAltV.

The paragraph under "Comment on this page" is objectionably small. Its
last sentence only says that details will not be released in the manner
outlined : it needs a comma.

The comments textarea is foolishly narrow. BTW, one can add a button to
do rows++.

Antipodeans may - very briefly - be amused by my gullible.htm in IE.

GENERAL NOTE, UNRELATED TO THAT PAGE - It has occurred to me, a bad
typist who sometimes, for example, puts foe instead of for and fails to
notice, that it should be useful to read Google's French (etc.,)
translation, assuming that one knows some French. In my contexts, the
occurrence in the translation of "l'ennemi" is much easier to notice.
Granted, there will be false positives - the translation of that page
seems to mention fleas, for example.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)
Aug 7 '08 #33
In article <MP**********************@news.individual.net>,
Stan Brown <th************@fastmail.fmwrote:
Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
<do************@optusnet.com.au>:
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>

Thanks for posting this. I don't specify text size in pixels, of
course, but I've been doing line heights in em or % rather than a
unitless proportion.
I chose px only to keep the same units for both font-size, line height
and the ruler for the demo. I know you don't.
If I understand your page correctly, where problems come up in using
units for line-height is for inheritance nd not in the specific
selector where it's specified. Would that be an accurate summary?
Roughly so. Unless you have special requirements in mind (I can think of
one or two but I won't bore anyone with them unless they don't think
there could be such a cases), it is better practice to use unitless.
Why? Because for most purposes there are only downsides doing otherwise.

There are the downsides I demonstrated in the URL provided, and this can
spring out of nowhere in a complex site. It can trip authors when they
are adding descendant elements later. Better to play safe and engage the
built in safeguard of proportionality of setting as a pure number. Plus,
less typing! <g>

--
dorayme
Aug 7 '08 #34
In article <12***************@angel.amnet.net.au>,
David Morris <dl**************@netwizDONTSPAM.com.auwrote:
dorayme wrote:
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>


I thought 1.5em was proportional to the font-size of the parent element.
I was doing this because I had read somewhere that your eyes follow
text better if the line height is consistent, though I can't remember
where, and may have got in wrong in any event.
Clearly, line height should be more or less consistent within a
paragraph of same sized text. But if you are relying on the actual (em
or px) line height of the parent element to dictate the line height of a
child or grandchild, then it will result in what no one would want as I
tried to example.

If you want consistent readability, you have two choices.

(1) Use units with line-height but watch your back all the time, and be
ready to hand code more line heights for the children and grandchildren
so readability and commonsense prevails.

(2) Don't use units and relax and let one (or very few) line height
declarations do the job for the trunk and branches.

--
dorayme
Aug 7 '08 #35
In article <Zf**************@invalid.uk.co.demon.merlyn.inval id>,
Dr J R Stockton <jr*@merlyn.demon.co.ukwrote:
Antipodeans may - very briefly - be amused by my gullible.htm in IE.
Would non-Antipodeans find it amusing:

(1) Not at all?

(2) More than briefly?

--
dorayme
Aug 7 '08 #36
On Thu, 7 Aug 2008 17:47:48 +0100
Dr J R Stockton <jr*@merlyn.demon.co.ukwrote in:
<Zf**************@invalid.uk.co.demon.merlyn.inval id>

[snip]
"(One would expect most Opera users to be using the very latest
version)" - but Opera 9.5 has dropped (AFAICS) a useful feature
present in 9.2 - CtrlAltV.
The feature is still there, just the keyboard shortcuts have changed.

http://snapshot.opera.com/950a1-keyboard.html

The old shortcuts are still available if you choose "Opera 9.2
Compatible" in Preferences Advanced Shortcuts.

http://help.opera.com/Windows/9.50/en/keyboard.html

[snip]

--

BootNic Thu Aug 7, 2008 11:31 pm
The human mind treats a new idea the same way the body treats a
strange protein; it rejects it.
*P. B. Medawar*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkibvi0ACgkQylMUzZO6jeL5IACgxscTgWx9iK ZQ9/qziKOPONMu
dEwAoML59gBWd8UHZwnTx8ssSqW8DsDj
=05tJ
-----END PGP SIGNATURE-----

Aug 8 '08 #37
Fri, 08 Aug 2008 09:14:29 +1000 from dorayme
<do************@optusnet.com.au>:
In article <MP**********************@news.individual.net>,
Stan Brown <th************@fastmail.fmwrote:
Thu, 07 Aug 2008 14:46:40 +1000 from dorayme
<do************@optusnet.com.au>:
<http://netweaver.com.au/alt/line-height_demo.html>
If I understand your page correctly, where problems come up in using
units for line-height is for inheritance nd not in the specific
selector where it's specified. Would that be an accurate summary?

Roughly so. Unless you have special requirements in mind (I can think of
one or two but I won't bore anyone with them unless they don't think
there could be such a cases), it is better practice to use unitless.
Why? Because for most purposes there are only downsides doing otherwise.
Yes, I agree. The intent of my question was to make sure that I
understood the actual problem.

It's an easy enough change for me. I have a fair number of line-
heights in my CSS right now, but about half those are "normal" and
several of the others are redundant as I look at the cascade, so this
is a good opportunity to simplify.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Aug 9 '08 #38
dorayme wrote:
In article <12***************@angel.amnet.net.au>,
David Morris <dl**************@netwizDONTSPAM.com.auwrote:
>dorayme wrote:
>>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>

I thought 1.5em was proportional to the font-size of the parent element.
I was doing this because I had read somewhere that your eyes follow
text better if the line height is consistent, though I can't remember
where, and may have got in wrong in any event.

Clearly, line height should be more or less consistent within a
paragraph of same sized text. But if you are relying on the actual (em
or px) line height of the parent element to dictate the line height of a
child or grandchild, then it will result in what no one would want as I
tried to example.
I remember now, that part of this approach was to set padding or margin
to add up to the same value as line height. Just to make sure I have
understood this, ...by specifying 'ems' you are using the parent
containers font-size to specify the line height, where as just the
number is the font size of the text in the element.

The effect I wanted was to have everything based on a ratio of 1.5 of
the typical body text font (as displayed not the element). What ever I
actually got, I liked it enough, and so stuck with that. This means
that the spacing around heading and larger fonts 'should' add up to some
number that is an integer multiplier of the line-height of this basic
body text style -- I think.
>
If you want consistent readability, you have two choices.

(1) Use units with line-height but watch your back all the time, and be
ready to hand code more line heights for the children and grandchildren
so readability and commonsense prevails.
And this looks like what I have done.
>
(2) Don't use units and relax and let one (or very few) line height
declarations do the job for the trunk and branches.
Which would be nice if I fully grokked what is going on. I need to
revisit by quick and dirty approach and sort this out so I actually do
understand what is going on. A few changes to just 1.5 made things look
very odd.

Aug 10 '08 #39
On 2008/08/09 09:56 (GMT+0800) David Morris apparently typed:
Which would be nice if I fully grokked what is going on.
Maybe this will help grokability:
http://fm.no-ip.com/auth/line-height-inherit.html
--
"Love is not easily angered. Love does not demand
its own way." 1 Corinthians 13:5 NIV

Team OS/2 ** Reg. Linux User #211409

Felix Miata *** http://fm.no-ip.com/
Aug 10 '08 #40
Dr J R Stockton wrote:
"(One would expect most Opera users to be using the very latest
version)" - but Opera 9.5 has dropped (AFAICS) a useful feature present
in 9.2 - CtrlAltV.
The site was tested with the latest version of Opera at the time, which
was 9.2.
The comments textarea is foolishly narrow. BTW, one can add a button to
do rows++.
I am sure you meant 'unnecessarily' rather the than 'foolishly'. To be
foolish would be to include Javascript on a page that highlighted why
you shouldn't use Javascript.
Aug 10 '08 #41
In comp.infosystems.www.authoring.stylesheets message <1218406629.246129
@angel.amnet.net.au>, Mon, 11 Aug 2008 06:20:38, David Morris <dlmorrisD
ON*****@netwizDONTSPAM.com.auposted:
>Dr J R Stockton wrote:
>"(One would expect most Opera users to be using the very latest
version)" - but Opera 9.5 has dropped (AFAICS) a useful feature present
in 9.2 - CtrlAltV.

The site was tested with the latest version of Opera at the time, which
was 9.2.
Irrelevant. My comment referred ONLY to that in ".." above.
>The comments textarea is foolishly narrow. BTW, one can add a button to
do rows++.

I am sure you meant 'unnecessarily' rather the than 'foolishly'. To be
foolish would be to include Javascript on a page that highlighted why
you shouldn't use Javascript.
You may be sure; but your first sentence is wrong. So is your second,
as it would be eminently reasonable to include a demonstration on such a
page.

For an example of Web folly, consider a site intended to support the
purchase of new computers in which the essential details are
inaccessible to those with only a moderately old computer (it is of
course OK for part of the site to demonstrate what only a new machine
can handle).

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)
Aug 11 '08 #42

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Fraser Hanson | last post: by
2 posts views Thread by Raghuraman | last post: by
2 posts views Thread by Chris | last post: by
3 posts views Thread by Terry Bell | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.