Values to change in suckerfish menu

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>

Richard

"Richard" <Anonymous@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 <> <http://steve.pugh.net/>

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

> "Richard" <Anonymous@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.

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.

Michael Winter <> 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 <> <http://steve.pugh.net/>

Steve Pugh wrote:
> "Richard" <Anonymous@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.

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

> Steve Pugh wrote:
>> "Richard" <Anonymous@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.

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

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.

kchayka <> 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 <> <http://steve.pugh.net/>