CSS drop-down menus

I'm experimenting with drop-down menus using one of Stu Nichols' designs:

http://www.cssplay.co.uk/menus/final_drop.html

My test-case files:

http://edmullen.net/menutest.php
http://edmullen.net/styles/menutest.css

Here's my problem. I can position the right and left fly-out
third-level menus. However, if the text is zoomed/enlarged, the space
between the second-level item and the fly-out changes. I've tried px, %
and em units with no success.

What's making me crazy is that my current menu scheme works fine when
enlarging the text: The third-level menu stays locked to its parent.

At this stage I'm only testing in SeaMonkey 1.1.16 and Firefox 2.0.0.20.
I'll deal with IE versions later.

Any help or advice greatly appreciated. I don't have enough hair left
to keep pulling it out.

--
Ed Mullen
http://edmullen.net
When cheese gets it's picture taken, what does it say?

Ed Mullen wrote:

I'm experimenting with drop-down menus ...


http://edmullen.net/menutest.php


Here's my problem. I can position the right and left fly-out
third-level menus. However, if the text is zoomed/enlarged, the space
between the second-level item and the fly-out changes. I've tried px, %
and em units with no success.

I wouldn't expect px to be at all satisfying, althouth in the current
form of the page you've pointed to, you're using them all over the place.

What's making me crazy is that my current menu scheme works fine when
enlarging the text: The third-level menu stays locked to its parent.

Possibly I haven't understood your problem thoroughly, but I see that
under MUSIC, the "sub" sits nicely to the left of "item w/ subs" no
matter the text size, while under MOZILLA, "sub2" is a varying distance
to the right of "item w/ subs", depending on font size ("sub2" is stays
in the same place). I'm guessing you don't like the behavior under MOZILLA.

Perhaps you would be happy with this:
..menu ul ul ul {
left: 10.3em;
top: -1px;
}

in which I've changed your 182px to 10.3em. Tested (heh, sort of) in FF
2.0.0.20 using the Web Developer extension.

Any help or advice greatly appreciated. I don't have enough hair left
to keep pulling it out.

I'd probably feel the same way if I had taht many stylesheets with that
many menu rules.

--
John

John Hosking wrote:

Ed Mullen wrote:
I'm experimenting with drop-down menus ...


http://edmullen.net/menutest.php


Here's my problem. I can position the right and left fly-out
third-level menus. However, if the text is zoomed/enlarged, the space
between the second-level item and the fly-out changes. I've tried px,
% and em units with no success.

I wouldn't expect px to be at all satisfying, althouth in the current
form of the page you've pointed to, you're using them all over the place.

So? Specific recommendations to change specific cases? Or is this just
a general objection/criticism?

What's making me crazy is that my current menu scheme works fine when
enlarging the text: The third-level menu stays locked to its parent.

Possibly I haven't understood your problem thoroughly, but I see that
under MUSIC, the "sub" sits nicely to the left of "item w/ subs" no
matter the text size, while under MOZILLA, "sub2" is a varying distance
to the right of "item w/ subs", depending on font size ("sub2" is stays
in the same place). I'm guessing you don't like the behavior under MOZILLA.

Did you try enlarging/zooming the text up and down? That's the problem.
Regardless of what unit I use to position the 3rd level it's position
relative to its parent 2nd level changes upon zooming. AND, if you view
any of my regular pages (non-experimental menus) that does not happen.
What I'm trying to figure out is why.

Perhaps you would be happy with this:
.menu ul ul ul {
left: 10.3em;
top: -1px;
}

in which I've changed your 182px to 10.3em. Tested (heh, sort of) in FF
2.0.0.20 using the Web Developer extension.

Nope, doesn't change the problem of text zooming. And that is the crux
of the problem.

Any help or advice greatly appreciated. I don't have enough hair left
to keep pulling it out.

I'd probably feel the same way if I had taht many stylesheets with that
many menu rules.

Not a helpful comment on the surface. However, without meaning to, you
may have given me a hint. I took out the default.css style sheet from
the test page. The problem of texst zooming and 3rd level positioning
goes away.

What is befuddling me about that is the cascade. The style sheets in
the test page load in this order:

default.css (this is loaded on every page on my site and the menus work
as they should)

menutest.css (the new experimental menu system style sheet.)

So.

1. On all current non-test pages using default.css the menus have no
positioning issue.

2. On the test page an additional style sheet is loading (menutest.css)
and the test page has the positioning issue.

3. That leads me to think that something in menutest.css is over-riding
something in default.css and this is causing the problem.

4. However, by removing default.css from the test page formatting, the
positioning problem on text zooming goes away in the test page.

Shouldn't menutest.css override the same declarations in default.css?
If so, why does removing default.css from the cascade "fix" the problem?

I have /very/ little hair left. In fact, I've checked and I have fresh
razor blades and shaving cream in the bathroom for the morning. I may
just do away with this whole issue that way.

--
Ed Mullen
http://edmullen.net
"A politician is a man who approaches every problem with an open mouth."
- Adlai Stevenson

Ed Mullen wrote:

I'm experimenting with drop-down menus using one of Stu Nichols' designs:

http://www.cssplay.co.uk/menus/final_drop.html

My test-case files:

http://edmullen.net/menutest.php
http://edmullen.net/styles/menutest.css

Here's my problem. I can position the right and left fly-out
third-level menus. However, if the text is zoomed/enlarged, the space
between the second-level item and the fly-out changes. I've tried px, %
and em units with no success.

I looked at one of the samples here:

http://www.cssplay.co.uk/menus/flyout2.html

and notice that there is no problem there. So, I'm thinking you need to
either pick a different menu (it is unreal the number he has made) or
take the stylesheet back to square one and see what changes you've made
that break it.

On a side note. I've found that even in very complex multiple tier
sites that such multiple flyouts aren't needed. I tend to do combos of
menus with a context sensitive submenu. Of course, you may already have
a specific use in mind.

Jeff

What's making me crazy is that my current menu scheme works fine when
enlarging the text: The third-level menu stays locked to its parent.

At this stage I'm only testing in SeaMonkey 1.1.16 and Firefox 2.0.0.20.
I'll deal with IE versions later.

Any help or advice greatly appreciated. I don't have enough hair left
to keep pulling it out.

Jeff wrote:

Ed Mullen wrote:
I'm experimenting with drop-down menus using one of Stu Nichols' designs:

http://www.cssplay.co.uk/menus/final_drop.html

My test-case files:

http://edmullen.net/menutest.php
http://edmullen.net/styles/menutest.css

Here's my problem. I can position the right and left fly-out
third-level menus. However, if the text is zoomed/enlarged, the space
between the second-level item and the fly-out changes. I've tried px,
% and em units with no success.

I looked at one of the samples here:

http://www.cssplay.co.uk/menus/flyout2.html

and notice that there is no problem there. So, I'm thinking you need to
either pick a different menu (it is unreal the number he has made) or
take the stylesheet back to square one and see what changes you've made
that break it.

His originals (all that I have looked at) have a similar problem. If
you zoom text in your browser, the menus fall apart.

On a side note. I've found that even in very complex multiple tier
sites that such multiple flyouts aren't needed. I tend to do combos of
menus with a context sensitive submenu. Of course, you may already have
a specific use in mind.

It's an experiment, Jeff. I may have a need for it, I may not.

I'm just trying to solve the zoom and positioning issue. The point is,
the current scheme on my pages works at any reasonable zoom level (go to
the link in my sig. Hover over a second-level link that leads to a 3rd
level menu. Note the 3rd level position. Then text zoom up. Not the
3rd level menu horizontal position. No matter the zoom level the 3rd
level menu is stuck to the parent 2nd level list.) and the experimental
one does not.

I'm trying to figure out why this experimental one does not, the
specific issue being that the 3rd level positioning breaks when text
zooming.

And, listen, I freely admit I adapted these examples without a great
deal of knowledge of the underlying logic to them. I accept the
criticisms you all might offer given that statement. But that's not the
issue. The issue is: What's going on and how to fix it. From this I
hope to learn.

I only have thirteen hairs left.

--
Ed Mullen
http://edmullen.net
Home computers are being called upon to perform many new functions,
including the consumption of homework formerly eaten by the dog. - Doug
Larson

Wed, 06 May 2009 14:31:12 -0400 from Ed Mullen <ed (AT) edmullen (DOT) net>:

I'm experimenting with drop-down menus using one of Stu Nichols' designs:

http://www.cssplay.co.uk/menus/final_drop.html

I don't know about that one in particular, but I found the ones that
I've tried very frustrating because he does so much of them in pixels
and with fixed font sizes. The result, as you observe, is that they
don't scale at all well.

It's a pity because he's obviously got a lot of ability and he is
very generous in making these designs available. YMMV, but I found
that once I had settled on one of his designs I had to do a lot of
tweaking to make it work under even a reasonable amount of browser-
based resizing.

--
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/2003/05/05/why_we_wont_help_you

In article <2ppaij.1v3.19.1 (AT) news (DOT) alt.net>, Ed Mullen <ed (AT) edmullen (DOT) net>
wrote:

I'm experimenting with drop-down menus using one of Stu Nichols' designs:

....

My test-case files:

http://edmullen.net/menutest.php

Any help or advice greatly appreciated. I don't have enough hair left
to keep pulling it out.

Don't bite my head off Ed, but was there some problem getting rid of the
validation errors I am seeing? I would think that maybe this is always a
good start to eliminate things from our enquiries.

I had you marked out for a position in my new vigilante detective frying
squad (a team of undercover "chefs" I need for a special operation...
don't ask).

--
dorayme

dorayme wrote:

In article <2ppaij.1v3.19.1 (AT) news (DOT) alt.net>, Ed Mullen <ed (AT) edmullen (DOT) net
wrote:

I'm experimenting with drop-down menus using one of Stu Nichols' designs:

...
My test-case files:

http://edmullen.net/menutest.php

Any help or advice greatly appreciated. I don't have enough hair left
to keep pulling it out.

Don't bite my head off Ed, but was there some problem getting rid of the
validation errors I am seeing? I would think that maybe this is always a
good start to eliminate things from our enquiries.

I just had a friend that used one of these CSS menus. He then ran it
through the validator and fixed all the errors. The end result result
was that this worked fine in FF and IE7, but was hopelessly and very
badly broken in IE6 and IE8.

That may not be the case here, but perfectly Valid code does not
necessarily make a well functioning site.

Jeff

I had you marked out for a position in my new vigilante detective frying
squad (a team of undercover "chefs" I need for a special operation...
don't ask).

In article <h4zMl.18058$D32.7489 (AT) flpi146 (DOT) ffdc.sbc.com>,
Jeff <jeff_thies (AT) att (DOT) net> wrote:

dorayme wrote:
In article <2ppaij.1v3.19.1 (AT) news (DOT) alt.net>, Ed Mullen <ed (AT) edmullen (DOT) net
wrote:

I'm experimenting with drop-down menus using one of Stu Nichols' designs:

...
My test-case files:

http://edmullen.net/menutest.php

Any help or advice greatly appreciated. I don't have enough hair left
to keep pulling it out.

Don't bite my head off Ed, but was there some problem getting rid of the
validation errors I am seeing? I would think that maybe this is always a
good start to eliminate things from our enquiries.

I just had a friend that used one of these CSS menus. He then ran it
through the validator and fixed all the errors. The end result result
was that this worked fine in FF and IE7, but was hopelessly and very
badly broken in IE6 and IE8.

That may not be the case here, but perfectly Valid code does not
necessarily make a well functioning site.

The point is always "that may not be the case". I train my detectives in
interrogation as well as great violence and I tell them to try first to
concentrate on the first skill. <g>

You see, if you get it kosher first, you then have the lie of the land
and can work out what to maybe do for IE's eyes.

--
dorayme

dorayme wrote:

In article <h4zMl.18058$D32.7489 (AT) flpi146 (DOT) ffdc.sbc.com>,
Jeff <jeff_thies (AT) att (DOT) net> wrote:

dorayme wrote:
In article <2ppaij.1v3.19.1 (AT) news (DOT) alt.net>, Ed Mullen <ed (AT) edmullen (DOT) net
wrote:

I'm experimenting with drop-down menus using one of Stu Nichols' designs:

...
My test-case files:

http://edmullen.net/menutest.php

Any help or advice greatly appreciated. I don't have enough hair left
to keep pulling it out.
Don't bite my head off Ed, but was there some problem getting rid of the
validation errors I am seeing? I would think that maybe this is always a
good start to eliminate things from our enquiries.
I just had a friend that used one of these CSS menus. He then ran it
through the validator and fixed all the errors. The end result result
was that this worked fine in FF and IE7, but was hopelessly and very
badly broken in IE6 and IE8.

That may not be the case here, but perfectly Valid code does not
necessarily make a well functioning site.

The point is always "that may not be the case". I train my detectives in
interrogation as well as great violence and I tell them to try first to
concentrate on the first skill. <g

You see, if you get it kosher first, you then have the lie of the land
and can work out what to maybe do for IE's eyes.

All that is fine if you wrote it and know what you are doing. Some of
these CSS menus have complex bits in them to deal with these browsers.
In the OPs case, I don't think anybody here understands just what all
this html does.

But the point I really wanted to make is that just because something
is valid does not mean it makes sense or should even work as we think
it should. You can write a lot of valid html that is complete nonsense,
the validator can't tell. It's better not to use anything you don't
understand.

Jeff