> > However, as sexy as highlighting with CSS only is, it does not make > > sense from a usability/accessibility point of view, as the current > > page _should not be a link_. Personally I highlight the current page > > with a strong - as this also makes sense without CSS and use the body > > id coupled with the nav id and the strong to apply the style. > > (http://www.csstoolshed.com/cocking/ page 8) > > but if you are using server includes, you cannot do this-adding a strong > tag to a specific link in the include. That's why many developers take > the other approach. Additionally, the bottom (footer) links can be a > "top level" category, where additional pages (3rd or deeper levels) fall > under that category or section.
Well, that is only partly true, as you _can_ use variables in SSI, too and highlight according to those. It is a bit messy though. If you use PHP for example it is really easy to highlight the current page and add a class to the parent links in a nested list: http://www.onlinetools.org/tools/easynav/ I wrote this to actually allow users of contribute to edit the navigation as an own HTML document and get the functionality. If the bottom link points to the same location it should not have a link either, if it doesn't there is no issue... If they are "top level links" then I normally tend to nest a strong inside those links instead of highlighting via a CSS class. In the css you can actually distinguish via descendant selectors: li strong {} li li strong {} li li li strong {} > I'm just adding to the conversation as to WHY someone might take the > other approach. With includes, you cannot make them different on each > page, except via some overriding (specificity) unique combination of > selectors, often started with the body tag and applying a class or id to it. Yes but using an idadequate technology should never be an excuse for bad usability. You don't normally use windows paint to create your website graphics either, and nobody complains that photoshop of fireworks is not free or too expensive. If your server does not support modern scripting technology, then you might want to maintain the site locally, create static HTML pages from templates with the unique navigation and FTP the lot over. > Just to throw in another thought on this - there are many times that you > might have page functions that display or don't display, yet are part of > an include. AND, you might be also setting the "selected" state of main > and footer links (even utility type links)... in many cases, I find I > have to go with classes *because* I can use more than one class, where I > cannot use more than one ID on the body tag. Visually, that does the trick, however not every user agent supports CSS, and why should I get a bunch of links or even content that I shouldn't get just because the server the site maintainer chose (or was forced to use) does not support technology that has been around for quite a while now - and is free? All this extra content also adds to pageweight, which can be quite significant. The visitors are those who bring either yourself or the client money/fame/fun in the end, you don't create sites for yourself or for the client to use. -- Chris Heilmann Blog: http://www.wait-till-i.com Writing: http://icant.co.uk/ Binaries: http://www.onlinetools.org/ ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
