Values to change in suckerfish menu

[Richard]

The style sheet shown below is from the suckerfish vertical menu.
http://www.htmldog.com/articles/suck.../vertical.html

I've added in a few minor changes to color code the levels.
I changed the width of the first level to 8em and get an unwanted space
between that and the 2nd level.
I'd like their to be no gap between the levels when I change the widths.
What's to change to do this?

Also, I do not understand the reason for "left: - 999em" in one definition.
However, changing the value came up with some interesting results.
<style type="text/css">

body {
font-family: arial, helvetica, serif;
}

#nav, #nav ul { /* all lists */
padding: 0;
margin: 0;
list-style: none;
float : left;
width : 11em;

}

#nav li { /* all list items */
position : relative;
float : left;
line-height : 1.25em;
margin-bottom : -1px;
width: 11em;

}

#nav li ul { /* second-level lists */
position : absolute;
left: -999em;
margin-left : 11.05em;
margin-top : -1.35em;
}

#nav li ul ul { /* third-and-above-level lists */
left: -999em;
}

#nav li a {
width: 8em;
display : block;
color : black;
font-weight : bold;
text-decoration : none;
background-color : #FAA;
border : 1px solid black;
padding : 0 0.5em;
}
#nav li li a {
width: 8em;
w\idth : 10em;
display : block;
color : black;
font-weight : bold;
text-decoration : none;
background-color : #0F0;
border : 1px solid black;
padding : 0 0.5em;
}

#nav li li li a {
width: 11em;
w\idth : 10em;
display : block;
color : black;
font-weight : bold;
text-decoration : none;
background-color : #DDF;
border : 1px solid black;
padding : 0 0.5em;
}
#nav li a:hover {
color : white;
background-color : black;
}

#nav li:hover ul ul, #nav li:hover ul ul ul, #nav li.sfhover ul ul, #nav
li.sfhover ul ul ul {
left: -999em;
}

#nav li:hover ul, #nav li li:hover ul, #nav li li li:hover ul, #nav
li.sfhover ul, #nav li li.sfhover ul, #nav li li li.sfhover ul { /* lists
nested under hovered list items */
left: auto;
}

#content {
margin-left : 12em;
}
</style>

[Steve Pugh]

"Richard" <An*******@127.001> wrote:

The style sheet shown below is from the suckerfish vertical menu.
http://www.htmldog.com/articles/suck.../vertical.html

I've added in a few minor changes to color code the levels.
I changed the width of the first level to 8em and get an unwanted space
between that and the 2nd level.
I'd like their to be no gap between the levels when I change the widths.
What's to change to do this?
If you change the width of the upper levels you must also change the
margin-left of the lower levels to match.
#nav, #nav ul { /* all lists */
width : 11em;
}
So when you change the above, you must change the following to match:
#nav li ul { /* second-level lists */
margin-left : 11.05em;
}
Also, I do not understand the reason for "left: - 999em" in one definition.
However, changing the value came up with some interesting results. #nav li:hover ul ul, #nav li:hover ul ul ul, #nav li.sfhover ul ul, #nav
li.sfhover ul ul ul {
left: -999em;
}

Instead of using display: none to hide the lower levels this menu
positions them way off the edge of the screen and then brings them on
as needed. The advantage to doing it this way is that they menu items
are always displayed and thus will always be accessible to screen
readers and the like.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Richard]

On Thu, 03 Mar 2005 17:36:29 +0000 Steve Pugh wrote:

"Richard" <An*******@127.001> wrote:

The style sheet shown below is from the suckerfish vertical menu.
http://www.htmldog.com/articles/suck.../vertical.html

I've added in a few minor changes to color code the levels.
I changed the width of the first level to 8em and get an unwanted space
between that and the 2nd level.
I'd like their to be no gap between the levels when I change the widths.
What's to change to do this?

If you change the width of the upper levels you must also change the
margin-left of the lower levels to match.

#nav, #nav ul { /* all lists */
width : 11em;
}

So when you change the above, you must change the following to match:

#nav li ul { /* second-level lists */
margin-left : 11.05em;
}

Also, I do not understand the reason for "left: - 999em" in one
definition. However, changing the value came up with some interesting
results.

#nav li:hover ul ul, #nav li:hover ul ul ul, #nav li.sfhover ul ul, #nav
li.sfhover ul ul ul {
left: -999em;
}

Instead of using display: none to hide the lower levels this menu
positions them way off the edge of the screen and then brings them on
as needed. The advantage to doing it this way is that they menu items
are always displayed and thus will always be accessible to screen
readers and the like.

Steve

Got that worked out now.
Any way to set the width so that it will expand as needed?
Setting to auto plays havoc with the listings.

[Michael Winter]

Steve Pugh wrote:

[snip]

The advantage to doing it this way is that they menu items are
always displayed and thus will always be accessible to screen
readers and the like.

Wouldn't it just be more sensible to limit proper hiding to the screen
(and possibly projection) media type, allowing others to see the items
normally.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Steve Pugh]

Michael Winter <m.******@blueyonder.co.invalid> wrote:

Steve Pugh wrote:

The advantage to doing it this way is that they menu items are
always displayed and thus will always be accessible to screen
readers and the like.

Wouldn't it just be more sensible to limit proper hiding to the screen
(and possibly projection) media type, allowing others to see the items
normally.

Screen readers use the screen media type (in theory they should use
the aural media type as well). Makes sense really. Audio browsers on
the other hand should not use the screen media type.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[kchayka]

Steve Pugh wrote:

"Richard" <An*******@127.001> wrote:

http://www.htmldog.com/articles/suck.../vertical.html

Instead of using display: none to hide the lower levels this menu
positions them way off the edge of the screen and then brings them on
as needed. The advantage to doing it this way is that they menu items
are always displayed and thus will always be accessible to screen
readers and the like.

I don't think this is really the best thing for screen readers, text
browsers or users with JS disabled. What you end up with is a big long
site map on every page. Consider how tedious it is to have to wade
through it page after page looking for any one link. It's bad enough for
sighted users to scan it over and over again, but it's even worse for
screen readers.

A much better approach, IMNSHO, is to put just the top-level menu links
in the HTML, which go to section index pages that contain the submenu
links. Use JavaScript to *add in* the submenus rather than just hide
them. That way, those who are able to use the DHTML menus as intended
get the "benefit" and the rest of us aren't punished for it.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[Richard]

On Thu, 03 Mar 2005 17:17:58 -0600 kchayka wrote:

Steve Pugh wrote:

"Richard" <An*******@127.001> wrote:

http://www.htmldog.com/articles/suck...e/vertical.htm
l

Instead of using display: none to hide the lower levels this menu
positions them way off the edge of the screen and then brings them on
as needed. The advantage to doing it this way is that they menu items
are always displayed and thus will always be accessible to screen
readers and the like.

I don't think this is really the best thing for screen readers, text
browsers or users with JS disabled. What you end up with is a big long
site map on every page. Consider how tedious it is to have to wade
through it page after page looking for any one link. It's bad enough for
sighted users to scan it over and over again, but it's even worse for
screen readers.

A much better approach, IMNSHO, is to put just the top-level menu links
in the HTML, which go to section index pages that contain the submenu
links. Use JavaScript to *add in* the submenus rather than just hide
them. That way, those who are able to use the DHTML menus as intended
get the "benefit" and the rest of us aren't punished for it.

Does this mean you'd prefer to rewrite a 50kb page just to add in one link?
I'm on dialup and I had to wait 3 minutes for your page to load.
You want me to do it all over again for one link? Bye bye.

[Nico Schuyt]

kchayka wrote:

http://www.htmldog.com/articles/suck.../vertical.html
A much better approach, IMNSHO, is to put just the top-level menu
links in the HTML, which go to section index pages that contain the
submenu links. Use JavaScript to *add in* the submenus rather than
just hide them. That way, those who are able to use the DHTML menus
as intended get the "benefit" and the rest of us aren't punished for
it.

Sounds reasonable. Can you point me to an example?

--
Nico
http://www.nicoschuyt.nl

[kchayka]

Nico Schuyt wrote:

kchayka wrote:

http://www.htmldog.com/articles/suck.../vertical.html

A much better approach, IMNSHO, is to put just the top-level menu
links in the HTML, which go to section index pages that contain the
submenu links. Use JavaScript to *add in* the submenus rather than
just hide them. That way, those who are able to use the DHTML menus
as intended get the "benefit" and the rest of us aren't punished for
it.

Sounds reasonable. Can you point me to an example?

No, coz everybody else seems to think the suckerfish way is the best for
accessibility. I strongly disagree with this opinion.

Every time this subject comes up, I think I should make an example, but
I just haven't gotten around to it. Should be easy for somebody who
knows how to manipulate the DOM, inserting child elements in particular.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[Steve Pugh]

kchayka <us****@c-net.us> wrote:

Nico Schuyt wrote:

kchayka wrote:

>

http://www.htmldog.com/articles/suck.../vertical.html

A much better approach, IMNSHO, is to put just the top-level menu
links in the HTML, which go to section index pages that contain the
submenu links. Use JavaScript to *add in* the submenus rather than
just hide them. That way, those who are able to use the DHTML menus
as intended get the "benefit" and the rest of us aren't punished for
it.

Sounds reasonable. Can you point me to an example?

No, coz everybody else seems to think the suckerfish way is the best for
accessibility. I strongly disagree with this opinion.

Every time this subject comes up, I think I should make an example, but
I just haven't gotten around to it. Should be easy for somebody who
knows how to manipulate the DOM, inserting child elements in particular.

I agree that having a full site map on every page is usually not a
good idea. For reasons that include aspects of usability and
accessibility. I would go further and say that it's not a good idea
regardless of how the menu is included in the page. Too much clutter
can distract users from what they came there to do.

On several sites I've done exactly what you describe - top level links
that work as links and which, if JS is enabled, also act as triggers
for a dynamically inserted dropdown menu.
(Example is four years old and almost every part of the site been
hacked about by muppets since then but the menu system is intact:
http://www.netbenefit.com/)

But I'm not sure that it is automatically better for accessibility.

A sighted but keyboard using user can gain as much benefit from these
menus as a mouse user. So you should make the menu respond to focus as
well as mouseover. (Interestingly my example above works with Opera's
spatial navigation but not with the standard previous/next link q/a
keys which Opera uses instead of tabbing).

Once you've done that there's no way that a screen reader running on
top of an ordinary browser isn't also going to pick up the menus, so
you're back the problem of the blind user having to wade through the
menus.

A much better solution is to minimise the number of links on each
page. Do your user studies, so your information architecture, channel
users into task based navigation schemes that give them only what they
need at that moment, if they want to explore then let them go off to
the site map page or use the searcg facility. Less clutter is good.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

[Steve Pugh]

"Richard" <An*******@127.001> wrote:

On Thu, 03 Mar 2005 17:17:58 -0600 kchayka wrote:

A much better approach, IMNSHO, is to put just the top-level menu links
in the HTML, which go to section index pages that contain the submenu
links. Use JavaScript to *add in* the submenus rather than just hide
them. That way, those who are able to use the DHTML menus as intended
get the "benefit" and the rest of us aren't punished for it.
Does this mean you'd prefer to rewrite a 50kb page just to add in one link?

No. He means that a new page with new content should be loaded when
the top level links are clicked on. (In some of these menus systems
top level itens are merely hooks for the DHTML and aren't actually
links). The content of this new page should contain all the links that
are children of the top level item in the DHTML menu.
That caters for users without JS.

And if such a page is 50kb then you're doing something wrong. CSS and
site furniture images should be cached. So unless you're adding new
images to the section page it really shouldn't be 50kb. 50kb is a lot
of HTML - http://www.sfsfw.net/a/author.php is less than 50kb.
I'm on dialup and I had to wait 3 minutes for your page to load.
You want me to do it all over again for one link? Bye bye.

You, and most other users, have the option of enabling JavaScript and
using the DHTML menu. This is a fallback for those users who can not
or who choose not to enable JavaScript.

On the file size issue:

suckerfish - HTML for all levels of menu is in every page so everyone
gets a bigger download.

kchayka - HTML for top level of menu is in every page. Rest of menus
are in JS file and only downloaded once.

So users with JS enabled get a slightly bigger download on the first
page but a smaller download on all other pages.
Users without JS enabled get a smaller download on every page but
sometimes have to click through an intermediate page or two to reach
their target.

Neither option is automatically better or worse.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>