OK, I'm getting a little confused......

A lot of sites actually have little in the way of content, and have a simple navigation struction... be it basic text links, button graphics, roll-over graphics, or roll-over/hover affects from JS or even CSS.....
I think this is fine for smaller sites.....
yet what about bigger sites?
The only thing I can think of as acceptable is a folding/collapsing menu system.... yet these tend to be JS, which means you are shot from the Search Engines, and I suppose not going to please those with JS disabled!

So, I have looked for a cross platform, cross browser, non-js alternative using css.... and guess what, just about all of them require a bit of JS to work!
Brilliant!
Solves the problem of SE's not liking the JS only menu.... but still stuffs up the non-JS browsers....

I have a simple JS menu at ppresent, it folds out nicely, asn as far as I know, works on all browsers with JS the same.... yet isn't SE friendly....

So, any suggestions for a reliable, cross B, cross P, SE friendly menu system for a site of around 40 odd pages?

erm...

"Hello. You have found an example page for Suckerfish Dropdowns. Under the hood you will find some nice structured HTML, a smattering of CSS and a teensy bit of JavaScript (that's just 12 lines of it). It's lightweight, it's accessible, it's cross-compatible."

See what the problem is?

I'm looking everywhere for the best ways to conform, and reading all these articles on why we MUST conform and adhere, and see everyone harping about this, that and the other, and the way things are going, we should all be using xhtml (bland html), CSS (to snazz up the xhtml), and making sure we support various browsers.....

Yet you shouldn't use JS because some browsers don't support it...
shouldn't make menus that don't use text hyperlinks due to SE's....
Shouldn't use CSS positioning/z-index because it is not fully supported...
shouldn't use tables because it's bad form...

I'm getting sick of it... the only way to generate a decent page that conforms to all the rules is by using basic CSS and generally sticking to to the standardised, exceptionally common "magazine" desing with a strong-graphical header or edging.... so it looks like a brochure.

There seems no way of dealing with a site that has a structure of...

1111
2222
3333
--3333aaa
--3333bbb
--3333ccc
--3333ddd
444
---444aaa
------444aaa111
------444aaa222
---444bbb
---444ccc
------444ccc111
------444ccc222
------444ccc222
------444ccc222

and so on..... I could use this CSS inline and indented list stuff, yet do I really want a menu that shows 40 odd pages, 15 of which are on a 3rd level?

This is really bugging me... I mean, how the hell am I supposed to obey the strictures every one sets, when nothing is fully supported, and any of the advanced, novelty of effect codes are permitted for "true design"?

is it wrong to want graphics.... themed.... snazzy menu's.... well layered and structured designs..... flexible layouts etc...??????

Oh well, I guess I''ll have to stick to the rules as much as possible, and say sod it when the needs arise and use JS or what ever as and when needed... unless you know of an alternative?

I know exactly what it says mate. The point is that tiny bit of javascript makes it work in IE. It works via pure CSS for Gecko browsers. Text only browsers don't support either so they get a nice unordered list. A browser that supports basic css but not javascript will display your top level menu, which should constitute links to pages with the sub menus on anyway... If you use the @import rule to hide your code from older browsers then they get a straight unordered list too.
Basically the accessibility is in your implementation of the code. Obviously it's a load easier not to use drop downs, but if you want to use them then that's how.

ah... fair enough....
So, I guess that any site that is multiple levels will always face a similar issue of not being able to implement such menus as 100% browser safe.... instead I have to ensure that I provide an additional method of reaching the sub/child pages as well, incase the browser doesn't support the original method?

Damn, and I was thinking it was about possible!

Now all I have to do is think of a way to do this without it looking ugly!

So, I get to use the nice pretty and funky menu's, so long as I ensure multiple means of getting around, (inc. basic anchors, a site map etc.), and ensure the funky code is hidden from older browsers.
Damn... more work!
Oh well... of to play!

Thanks for your help!

That's it. It's almost back to the days of browser detection and serve up whatever is appropriate...

LMAO

NO!
That is what I'm trying so desperaely to avoid..... several of my friends had got into WS Design, and took me on board for my business and administration skills... I ended up spending 3 months figuring how to detect browsers, versions, capabilites etc... sod that for a laugh!

:whimper:
you were kidding, right?

Yeah I was kidding. Sort of. The @import rule is probably the simplest of 'browser detection/serve up appropriate css' methods.

hmmm... I've been looking at that... and to be safe, I think it best to generate two seperate CSS files... the link one being for standard font/txt and gnereal positioning, the @import one for the detailed styling... only thing is, I'm not sure if I can alter an element twice, from two seperate files?

Have to play around abit!

yeah you can have a basic style on the first and change it to something comlicated on the @import. If you change the same property on your @import it will override the basic style.

really?
Thats handy, was worried about the cascade affect... yet if @ import is higher in ranking, then thats perfect!

All I need now is a table listing browsers and their support/lack of different CSS commands/fomattings...

any ideas?

Tell you something... I'm going mad trying to find all this stuff.... over 100 sheets just for css.... which is basically simple!

The code is basic, the applications are linear... it's the flaming browsers that have me printing everything! XXX: xxx; works in aa, bb, cc2, cc3, eee, 0004, but not ooo1,2,3....etc! Same goes for the doctypes, boxmodels, inline: block; etc.!

Damn confusing!

Still, figured some stuff out, will play with menus this week, se what I can foul up!

Still need to think of a safe alternative navigation idea incase a viewer has an older browser or no JS support!

breadcrumbs work: that's
Home > Sub Category 1 > Sub sub category1

Then make the top end pages link to separate pages with a plain version of that dropdown category.

Are you using any includes or anything to make your life easier in terms of including content?

The bread crumbs idea is ok.... yet may make the site a little untidy.... not the sort of design they want!
(typical! LOL).

I have no idea what the last part was about.... could you explain it a little, please?

The only thing I can think of is that they click on menu item 1, which takes them to a page for that section, on which is another menu..... yet thats a little tacky to be honest..... not to mention annoying!

e.g
- (rp) = real page
- (sctn) = section...go to this page to see the pages below

homepage - (rp)
club - (sctn)
***details - (rp)
***history - (rp)
style - (sctn)
***description
***kata - (sctn)
******kata 1 - (rp)
******kata 2 - (rp)
******kata 3 - (rp)
***weapons - (sctn)
******weapon 1 - (rp)
******weapon 2 - (rp)
******weapon 3 - (rp)

I thought we had gone past all of that.... yet to make a WS "properly" and to "conform" I can just slap a funky menu in there, ("apparently"), incase it isn't supported.... (be it CSS or JS, Js also being shot by SE's!).....

Hell, they don't make this anything close to easy do they!

For your menu, the typical method is a row of links for each section across the bottom of the page. You may have seen that sort of thing somewhere.
If you look at http://www.klproductions.com/webcomponents.html you can see a neat implementation of the breadcrumbs thing.

As to includes... If your server supports PHP or SSI you can use those to include blocks of code. So say your drop down menu code is the same on every page, you can use an include (either php or ssi) and have the menu in a separate file. When you call that file with your include, it's contents are included in the page that is served to the user.
The separate file will only contain the block of code that deals with the menu - it won't be a html file in it's own right.

http://www.webdevfaqs.com/php.php#include

When you're developing locally it makes previewing difficult, but you can either install some web server software on your pc, or you can get html-kit from www.chami.com and install the php extension.

ok... the bread crumb I could make standard for most things... offers simple mode of backtracking through a site!

having a php include menu still won't permit things like foldouts or drops though.... it appear to be compatible means to stick to the basic... which is a shame!

AH... NOTE.... has anyone used NN6 and looked at the suckerfish menu's.... none of them work in NN6! damn... AND i WAS GETTING TEMPTED TO USE IT!

I want to avoid reloading the page just to advance a menu...
I can't use frames.....
I can't use js....
Java is bad.....(apparently)

So... this leaves my with basic html/xml tags, generic DOM....and basic CSS

Well, I can get the equivelent of Rollovers then that degrade....and I can create huge lists as a menu... which though pretty, beats the idea.....

Nope... I now think it can't be done.

The only alternative I can think of is to "page per section" the menu.... which is pathetic and makes the site look like it was mad by a moron! I might as well go and stick big tacky button images behind it as well just to finish it off!

Well, I'm off to rant and moan to my self for a while!

See what you think of this.....

http://www.bokb.co.uk/test/menu.html

well it works...
At the end of the day you can't cater for everyone, but you can do your best.
I have netscape 7.2, not 6. What does it do? Would it still work if the top level links provided access to sub-menus on new pages?

In nn6, you only get the basic menu... no foldouts/drop downs over the top!
So long as I make the head section of each a link to an intermediary page with a sectional menu, it would still work.

Whats bugging me is I have seen a css menu that uses expansion.... and lists I think.
Logic says that if I creat a list with sub lists, with hide over it, then if the browsers doesn't support css, then it looks normal without the pretty ness, and shows all, yet other borwsers would be able to hide things......

maybe a header menu system with a div that permits callouts... thuis sub menus would appear below...?

going to go play for a bit.. .and rant! Need caff' and bac'.
let you know what I find or come up with!

I've been taking a really close look at the examples over at CSSZenGarden because one of the things that makes me crazy, as a designer, is when someone resizes the text, in <div> and <span> layouts, you often have overlaps ... and it looks like crap, frankly. I've found several designs that look good, regardless of the browser, resolution OR text size, and just found This One - utililizing the expanding menu option - that renders somewhat differently in different browsers, but retains the style and readability. I like it.

Ladee

I don't get it.... either the menu's work in IE and not NN, or they work in NN but not IE!

I can use a .htc file to solve IE's hover problem.... great... yet my menu at the mo' shows in NN, yet disappears before you can reach the new sections....

May have to look at the code for the Zen Garden..... though it looks about the same as sucker fish... it works inb NN6 though, and sucker fish didn't!