tab key and pseudo class selector
|
|
Thread rating:  |
Haines Brown - 25 May 2008 16:55 GMT I have a drop down menu system that consists of many entries in two to four levels. Because of the size and complexity of the menu, I have the user hover over a menu list item to make its submenu visible.
This works fine, but I'd like to have this behavior also implemented entirely from the keyboard. To do this I've enabled tabbing among text strings by placing them into empty anchor elements. As a result, when I tab to a list item text, it makes its submenu visible.
Here is an abbreviated and simplied markup to show what I mean:
<ul> <li><a href="" id="a">Top Heading</a> <ul id="list-a"> <li><a accesskey="a" href="<path>">a) Subheading</a></li> <li><a accesskey="b" href="<path>">b) Subheading</a></li> ...
<style> a#a:focus + ul#list-a, a#a:active + ul#list-a { display: block; } </style>
When the user displays the submenu, he can click on it to navigate to the <path> page. However, I'd like to duplicate this operation from the the keyboard. The traditional way was to use accesskey property (which I've implemented in the example above by way of illustration). However, using letters for access keys conflicts with browser hot keys, and not all browsers (including my firefox/iceweasel) respond to digits.
Is there anything wrong with my way to make submenus visible above? Is there any way to select and activate a menu that links to a page other than getting there simply by tabbing, which is too cumbersome for a large complex menu.
--- Haines Brown, KB1GRM
Jukka K. Korpela - 25 May 2008 18:30 GMT Scripsit Haines Brown:
> I have a drop down menu system that consists of many entries in two to > four levels. You should most probably redesign it. That sounds like poor usability and poor accessibility, and such menu systems are a frequent cause of complains.
> Because of the size and complexity of the menu, I have > the user hover over a menu list item to make its submenu visible. Just make it simple, then keep it simple, mm'kay?
> This works fine, but I'd like to have this behavior also implemented > entirely from the keyboard. So you are now trying to find partial fixes to some problems you created by setting up an overly complex menu system.
> To do this I've enabled tabbing among text > strings by placing them into empty anchor elements. Gets even worse. You are intentional breaking the usability and the accessibility of the pages.
> <li><a accesskey="a" href="<path>">a) Subheading</a></li> The accesskey attribute, nominally introduced to promote accessibility, has been found to be hostile to accessibility. The setting above will normally mask out the functionality of Alt+A in a browser, and you cannot possibly know what damage is done (i.e., which function, if any, is masked out).
> However, > using letters for access keys conflicts with browser hot keys, and not > all browsers (including my firefox/iceweasel) respond to digits. Indeed.
And the idea of using :focus won't take you far, since it is inconsistently implemented in different browsers.
> Is there anything wrong with my way to make submenus visible above? Yes, the whole idea is wrong. It's pointless to discuss CSS details before having a reasonable design.
A single dropdown menu, implemented via CSS in a manner that degrades gracefully, might be reasonable. And perhaps you can have several such menus on a page, but don't try to nest them. A
 Signature Jukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/
Haines Brown - 25 May 2008 21:20 GMT > Scripsit Haines Brown: > [quoted text clipped - 4 lines] > and poor accessibility, and such menu systems are a frequent cause of > complains. I appreciate your other points, but I'd like to focus on this one, if you allow, for much of the rest of what you say follows from it.
It was my assumption that, in terms of usability, three levels are normally the maximum depth for cascading menus. Are you disagreeing with that generality?
One, of course, has to take into account the intended user base. My users in this case are people who are motivated to dig for material. And I'm also not in a competitive situation where competing sites' greater ease of use would give them an advantage over me.
A menu system has the great advantage of graphically organizing material into categories and subcategories that guide the user toward his ultimate destination. I can't think of any other approach that quite does that. But if you can think of any, I'd appreciate knowing of it.
In principle I could implement a search engine and make sure that each target page <meta name="keywords" ..> is equipped with a word corresponding to each categorical level. However, that wouldn't really work.
 Signature Haines Brown, KB1GRM
dorayme - 26 May 2008 00:53 GMT > > Scripsit Haines Brown: > > [quoted text clipped - 11 lines] > normally the maximum depth for cascading menus. Are you disagreeing with > that generality? Yes. Levels (even one - but that is safest) buggers up accessibility.
> One, of course, has to take into account the intended user base. My > users in this case are people who are motivated to dig for material. Everyone digs for material. Humans are driven.
> A menu system has the great advantage of graphically organizing material > into categories and subcategories that guide the user toward his > ultimate destination. In theory, maybe. But considering the troubles they run into in practice, given the technologies and browser differences, it is better to turn to alternatives. It is not as if there are not excellent alternatives.
> I can't think of any other approach that quite > does that. But if you can think of any, I'd appreciate knowing of it. [quoted text clipped - 3 lines] > corresponding to each categorical level. However, that wouldn't really > work. What quite is wrong with a search engine? Why would it not really work?
Anyway, you can have a site map. You can choose your top categories carefully so that there is little doubt that a person wanting to know about ducks will click a link that will lead to ducks (the link might go to a page that has a prominent link called "Birds good to eat").
You might suppose that this is inefficient for the user? Why? If, because he authopr of the site has not planned well, the average intelligent user can easily go on flase link trails, so too can he go on false drop down pathways on a single page, fiddling and fumbling with mouse and missing the exact spot 2 levels down and having to start all over and so on.
Go for reliability. If you must have a drop down, JK's advice is good. No more than a level.
I would forget about drop downs as much as you can for the following reason: it makes the author lazy about meaning, about logical ordering of pages and heading and titles and everything to do with good management. Drop downs can be like bad substitutes for good and deeper organization of a site.
 Signature dorayme
Haines Brown - 26 May 2008 12:40 GMT Thank you for the advice. I hope you don't mind if I reflect on it a little.
>> One, of course, has to take into account the intended user base. My >> users in this case are people who are motivated to dig for material. > > Everyone digs for material. Humans are driven. You misunderstood my point. If a company has people working in the field who need to access documents from the home office server, they are more motivated to dig than, say, a visitor to a porn site, where what is displayed on the page offers the motivation for going further. A librarian understands the need for a bit of patient digging, while a clerk-typist might not be used to that kind of effort. My point was simply that we should know our intended audience and tailor our pages to it (with which you surely agree), but this might in some cases allow for hierarchical menuing.
>> A menu system has the great advantage of graphically organizing >> material into categories and subcategories that guide the user toward [quoted text clipped - 4 lines] > to turn to alternatives. It is not as if there are not excellent > alternatives. This raises other questions. Are these "troubles" merely anecdotal or have their been solid studies made of different kinds of social groups using of hierarchical menus? I suppose there are. Not to cast any doubt on your assessment, but could you refer me to one? Or are you thinking, rather, of technical difficulties, such as a drop down menu working on one browser but not another?
> What quite is wrong with a search engine? Why would it not really > work? Search engines can work, of course. The problems I referred to were a) When the target of interest is a general category, not a specifically defined entity. In the site I'm working on, the user will probably be more interested in browsing all the material in a subcategory then locating a specific item. b) Often material that falls into a certain category does not actually contain those categorical terms, and unrelated material might in fact contain them. The site I'm redesigning after a decade in consists primarily of graphic images, and I'd have to guess the search terms a user might employ and plug them in as keywords. c) Not the site I'm working on, but I have another site that contains some 16,000 documents. It is equipped with a search engine, but almost anything you use for a search term will return hundreds of hits, most of which the user will not realize he does not want until after actually taking a look at them. That is, search engines can create their own problems.
> Anyway, you can have a site map. You can choose your top categories > carefully so that there is little doubt that a person wanting to know > about ducks will click a link that will lead to ducks (the link might > go to a page that has a prominent link called "Birds good to eat"). My idea of a site map is that a hierarchy of categories is flattened out and represented in two dimensions; the entire dendritic structure is visible at once. By saying that there are "top" categories, do you imply a menu, or a hierarchical site map having the same problems as a hierarchical menu? While a site map makes sense, I don't see how it can accommodate hundreds of categories. Or are you referring to the site-maps protocol?
> I would forget about drop downs as much as you can for the following > reason: it makes the author lazy about meaning, about logical ordering > of pages and heading and titles and everything to do with good > management. Drop downs can be like bad substitutes for good and deeper > organization of a site. A "deeper organization of a site" sounds to me like hierarchically linked pages that in effect are like a menu, and so let me be sure I understand your point. That is, are you suggesting that a hierarchy of linked pages is to an extent acceptable and is much preferred to a comparable menu hierarchy? I'm not entirely clear whether your objection to menues is primarily having to dig through a categorical hierarchy or is it to the technical problems of designing a hierarchical menu that will work reliably with all browsers?
Actually, linked pages has been my practice rather than hierarchical menus. What I don't like about menus is that a mistake can force you to start again at the top, that inexact mouse movements can take you where you don't want to go, that some do not work well on all systems, and that they are mouse-dependent.
 Signature Haines Brown, KB1GRM
Bergamot - 26 May 2008 13:40 GMT > While a site map makes sense, I don't see how it can > accommodate hundreds of categories. But you want to make drop-down menus that do? That sounds a lot more painful to use than a site map.
 Signature Berg
dorayme - 27 May 2008 03:26 GMT > Thank you for the advice. I hope you don't mind if I reflect on it a > little. Perhaps you are responding to remarks by dorayme? Wait on! That's me!
> >> One, of course, has to take into account the intended user base. My > >> users in this case are people who are motivated to dig for material. [quoted text clipped - 4 lines] > who need to access documents from the home office server, they are more > motivated to dig than, say, a visitor to a porn site, ... Not really misunderstood. Perhaps we can meet half way here and say that some sites might benefit more than other sites from drop down menuing. But the point I want to make is that this cannot be decided until you make the site as good as you can without the drop down. Once you have done that, you can judge the issue properly.
Do not be surprised that a well organised site will need less levels (if any) in the drop down menu system, the better the site is organised in the first place. Let's call this the Disappearing Need for Dropdown Menu Law (DNDM).
> >> A menu system has the great advantage of graphically organizing > >> material into categories and subcategories that guide the user toward [quoted text clipped - 11 lines] > rather, of technical difficulties, such as a drop down menu working on > one browser but not another? I can only judge on my own experience and people I talk to. A good question though! Don't forget to ask its twin: what are the ease of use stats on sites without dropdown menus that are organised very well (and therefore without any dropdowns at all - according to the DNDM law).
There is a rather nice argument for some dropdowning: it is easier than making a well organized site! Ease for the author(s) over time is not perhaps to be so lightly dismissed (as might seem to be implied by the over zealous use of DNDM law). If you do not follow me on this, ask and I will explain.
> > What quite is wrong with a search engine? Why would it not really > > work? > > Search engines can work, of course. The problems I referred to were ... OK, I understand and accept the limitations. Perhaps a search engine in addition to other things is a good idea though, we agree?
> > Anyway, you can have a site map. You can choose your top categories > > carefully so that there is little doubt that a person wanting to know [quoted text clipped - 8 lines] > accommodate hundreds of categories. Or are you referring to the > site-maps protocol? A model of the site with links to all important pages (important meaning that if someone was likely to be searching for something that was on a page, that page better appear on the site map. You would not put in page 17 of a 24 page section that was merely an essay on something, the material broken into pages to avoid too much scrolling) is what I meant.
You could couple this site map with a search function for this page alone. This way, you will get most of the functionality of the sort of comprehensive dropdown menu system you seem in favour of, without the accessibility drawbacks. Drawbacks, btw, that you are aware of (as evidenced by your remarks at the end). You will get no more results from a search of this site map page than you would get uncertainties from negotiating with a mouse a complex system of dropdowns.
> > I would forget about drop downs as much as you can for the following > > reason: it makes the author lazy about meaning, about logical ordering [quoted text clipped - 4 lines] > A "deeper organization of a site" sounds to me like hierarchically > linked pages that in effect are like a menu, Yes, there is a main home page and you can go see animals or plants from there. A click gets you to animals. The animals page has ducks and camels and the camels page has (if need be) links to different varieties, all clearly marked in the local menu there.
It is how well a site author manages this important job that determines how much need he will have for a fancy dropdown menu system.
For truly complex sites, it is not an easy job, I agree. but there are some great weapons at hand to assist. One of the weapons is the clever use of redundancy. Strictly for a super rational user you would not repeat links to "irrelevant things" on a page. But who is so rational and clear headed always? So you make it easy for folk by allowing them to shoot across the site without having to go back to the home page.
Hard to go into details because it is a complex task and requires judgement and particular circumstances.
> and so let me be sure I > understand your point. That is, are you suggesting that a hierarchy of > linked pages is to an extent acceptable and is much preferred to a > comparable menu hierarchy? More or less, yes. I am not saying a simple dropdown might not help to save some space on a page and therefore be useful. Simple one level ones are not so troublesome.
> I'm not entirely clear whether your objection > to menues is primarily having to dig through a categorical hierarchy or > is it to the technical problems of designing a hierarchical menu that > will work reliably with all browsers? Both.
 Signature dorayme
Haines Brown - 27 May 2008 12:50 GMT > Perhaps we can meet half way here and say that some sites might > benefit more than other sites from drop down menuing. I find all your points persuasive. You and Jukka have made me much more aware of the problems with drop down menus. As a result, I'm starting my site now under discussion using hierarchical pages (www.hartford-hwp.com/image_archive/index.html).
> A model of the site with links to all important pages (important > meaning that if someone was likely to be searching for something that > was on a page, that page better appear on the site map. You would not > put in page 17 of a 24 page section that was merely an essay on > something, the material broken into pages to avoid too much scrolling) > is what I meant. Here is an example of a site where there are about 40 top-level categories for a hierarchy of linked pages: www.hartford-hwp.com/archives/. This is a lot! But I know of no alternative without adding even more levels. It also has a search utility, which in this case seems quite appropriate. although less so for the site I've been discussing.
> You could couple this site map with a search function for this page > alone. This way, you will get most of the functionality of the sort of [quoted text clipped - 3 lines] > from a search of this site map page than you would get uncertainties > from negotiating with a mouse a complex system of dropdowns. Understood. I'm not really arguing for drop down menus, but only weighing the pros and cons. My initial exploration in that direction has been brought to an end by this thread, particularly Jukka's web page that catalogs some of the problems.
> Yes, there is a main home page and you can go see animals or plants > from there. A click gets you to animals. The animals page has ducks > and camels and the camels page has (if need be) links to different > varieties, all clearly marked in the local menu there. Your example has at least four levels, perhaps five. I've always worried about forcing the user to dig deeply, but for your example (given that it represents a simplification), I'm not sure how to avoid that.
> For truly complex sites, it is not an easy job, I agree. but there are > some great weapons at hand to assist. One of the weapons is the clever [quoted text clipped - 5 lines] > Hard to go into details because it is a complex task and requires > judgement and particular circumstances. Yes, a challenge. In one of my sites I mentioned above, I make extensive use of cross links to material that has relevance that is not manifest in the hierarchy.
 Signature Haines Brown, KB1GRM
dorayme - 28 May 2008 03:37 GMT > > Perhaps we can meet half way here and say that some sites might > > benefit more than other sites from drop down menuing. [quoted text clipped - 3 lines] > site now under discussion using hierarchical pages > (www.hartford-hwp.com/image_archive/index.html).
> > For truly complex sites, it is not an easy job, I agree. but there are > > some great weapons at hand to assist. One of the weapons is the clever [quoted text clipped - 9 lines] > use of cross links to material that has relevance that is not manifest > in the hierarchy. I will just for now make this point. Look at your:
<http://www.hartford-hwp.com/image_archive/menu-01.html>
which can take you to 5 different pages on parts of Archaic Africa and Europe. However, on each of these parts, the user has to come back to the above link. I am not saying this is illogical. It is quite sensible. But you have tons of room on all your pages, why not repeat the menu (I quote above) on each of those pages? This probably cuts down the number of mouse click trips users interested in all the parts of Archaic places have to make.
This is the sort of thing I was meaning previously by attending to organization and using redundancy.
The truth is, there are no rigid guidelines in all these matters and so beware of anyone selling you rigid laws. You simply excercise judgement and knowledge of the likely people using the site. I would bet quids that many people interested in Archaic Africa would be interested in stuff on from more than one region. Armed with this, putting a local menu to all the regions on each region, is the obvious move.
I assume you know that php includes are a great help in these matters.
In general, you should be putting a top level menu on each page. From the pages I just perused, I felt the need for a menu informed from the index page. For example:
Mode of productions: <Archaic> <Ancient> and <Feudal>
where <> indicate menu links, might usefully be at the top of *all* the subsequent pages. On the Archaic pages, in addition, a local menu listing <Africa> <West Africa> and <Europe>.
 Signature dorayme
Haines Brown - 28 May 2008 19:15 GMT > I will just for now make this point. Look at your: > [quoted text clipped - 3 lines] > probably cuts down the number of mouse click trips users interested in > all the parts of Archaic places have to make. dorayme,
I implemented your suggestion. It strikes me as ugly, but it does the job that you recommended. Not sure how to "prettify" it. The link buttons are sure plain looking, but at least they are utilitarian in that their purpose is transparent.
 Signature Haines Brown, KB1GRM
dorayme - 29 May 2008 03:35 GMT > > I will just for now make this point. Look at your: > > [quoted text clipped - 10 lines] > buttons are sure plain looking, but at least they are utilitarian in > that their purpose is transparent. I was only talking about the logic and the usefulness aspects, not implying how you should implement it visually. Your additions do not make the page uglier, in my opinion, if that is any consolation! <g>
It seems to me there is an almost invariable good rule to making a website of many pages. And that is to fashion the most general navigation into the template. And to put in local menus in addition for various complex sections.
Important, imo, is to show the relationship between the main (global) menu and the particular local. The sort of thing I think is quite helpful can be seen all over the place, I noticed it last at
<http://www.khs.org.au/>
Look at Local History, this stays highlighted, even though the local menu in that section changes highlighting according to the page being viewed.
The basic functional job of putting such navigation in is not, imo, a matter of taste in any way. It is essential. But how to construct the page to make it look nice, well, that is a different thing altogether and will vary according to one's aptitude. I like functional and straightforward and for a site like yours with an interesting and serious purpose, there is no need to be too fancy.
 Signature dorayme
Jukka K. Korpela - 26 May 2008 06:15 GMT Scripsit Haines Brown:
> It was my assumption that, in terms of usability, three levels are > normally the maximum depth for cascading menus. Are you disagreeing > with that generality? I am. You mentioned "a drop down menu system that consists of many entries in two to four levels". The very idea of drop down navigation on web pages is questionable; see http://www.cs.tut.fi/~jkorpela/forms/navmenu.html which is admittedly old, and CSS-based approaches (a list of link, turned into a drop down menu using CSS) have changed the picture somewhat. But most of the counterarguments apply to them as well.
> A menu system has the great advantage of graphically organizing > material into categories and subcategories that guide the user toward > his ultimate destination. Many people have difficulties in making a one-dimensional selection when there are several options, and even when there aren't. In fact, I would say that _most_ people make selections better if they can concentrate, at each level, on the selection at hand. A "graphic organization", whatever that really means (I saw no URL), probably mixes the levels.
> In principle I could implement a search engine and make sure that each > target page <meta name="keywords" ..> is equipped with a word > corresponding to each categorical level. However, that wouldn't really > work. It's hard to tell without knowing the specifics.
 Signature Jukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/
Haines Brown - 26 May 2008 13:46 GMT > The very idea of drop down navigation on web pages is questionable; > see http://www.cs.tut.fi/~jkorpela/forms/navmenu.html which is > admittedly old, I read this with interest. Very helpful. I had used javascript on the original version of the site, and one reason for redesigning it how was to get away from it.
> and CSS-based approaches (a list of link, turned into a drop down menu > using CSS) have changed the picture somewhat. But most of the > counterarguments apply to them as well. Keyboard access is something I am very concerned about. A hierarchy of links seems the only practical way to get keyboard access other than by the use of forms. Would you agree?
Your example of a "normal list of links" in fact is a hierarchy of three levels (perhaps more), and so you apparently are not objecting to hierarchies per se, but how they are implemented.
> Many people have difficulties in making a one-dimensional selection > when there are several options, and even when there aren't. In fact, I > would say that _most_ people make selections better if they can > concentrate, at each level, on the selection at hand. A "graphic > organization", whatever that really means (I saw no URL), probably > mixes the levels. Not sure I quite follow you. Are you suggesting that many people find it difficult to make a choice when faced with several alternatives? Not sure what a "one-dimensional selection" implies. Yes, choices at each level require some thought, but I'm not sure why this is more difficult with a drop down menu unless it is your point that with a URL hierarchy, each level can have aids to assist the user in making the choice.
What I meant by "graphic organization" was simply that the physical organization of a drop down menu system displays in visible terms the categorical relationships. For example, prior to making an actual selection, you can see what the current options are and the options that can be taken by choosing one of the current options. That strikes me as being one advantage of a drop down menu over a hierarchy of pages unless each page has some information about the hierarchy in which it is embedded.
I'm not trying to defend menus here, but merely fleshing out the pros and cons.
>> In principle I could implement a search engine and make sure that >> each target page <meta name="keywords" ..> is equipped with a word >> corresponding to each categorical level. However, that wouldn't >> really work. > > It's hard to tell without knowing the specifics. For example, suppose someone was looking for something about gay marriage in Kampuchea. However, a categorical hierarchy (listed as keywords) might be: Southeast Asia, Cambodia, society, gender. The user guessed wrong about these categorical search terms. The hierarchy: Southeast Asia -> Cambodia -> society -> gender would have guided him to his target by defining the options for him, and it would also have facilitated access to other material on gender relations that would likely be relevant or of interest.
 Signature Haines Brown, KB1GRM
Jukka K. Korpela - 27 May 2008 07:24 GMT Scripsit Haines Brown:
> Keyboard access is something I am very concerned about. A hierarchy of > links seems the only practical way to get keyboard access other than > by the use of forms. Would you agree? For more than, say, a dozen links, yes.
> Your example of a "normal list of links" in fact is a hierarchy of > three levels (perhaps more), and so you apparently are not objecting > to hierarchies per se, but how they are implemented. A list is not a hierarchy, but you are right in the sequel. If you have, say, 100 links, you should try and group them somehow, so that the user can first select between the groups, then within the selected group. If you have hundreds of links, you start needing several levels of selection, i.e. some hierarchy. But this means that you need to divide the links into several _pages_.
Using CSS, you _might_ be able to put all the links on one page so that at any time, only a handful (say, a dozen) of them is visible. But this is usually a wrong approach. To begin with, when someone enters the page using a speech browser, he often hears first some general information about the page, as analyzed by the browser, e.g. the total number of links on it. And "This page has six hundred seventy-five links" isn't very promising.
> Not sure I quite follow you. Are you suggesting that many people find > it difficult to make a choice when faced with several alternatives? Yes, that too.
> Not sure what a "one-dimensional selection" implies. A selection between items with no hierarchy indicated between them. Something like names in alphabetic order, or a collection of images of fruits.
> Yes, choices at > each level require some thought, but I'm not sure why this is more > difficult with a drop down menu unless it is your point that with a > URL hierarchy, each level can have aids to assist the user in making > the choice. I'm not referring to any URL hierarchy. I'm referring to the situation of making a choice. When you need to select between fruits, you should have the images or the names (or both) of the fruits available to you, with no disturbing factors. For example, a breadcrumb-like path showing what you chose before that is probably just disturbing. Moreover, when implemented as hierarchic dropdown menus, such a path would involved the need for some accuracy in hand movement so that you really move up or down, instead of accidentally moving to the left, upwards in the hierarchy or history. This is my experience with such systems in different contexts, including web pages, and it seems that I'm not alone with this problem.
> What I meant by "graphic organization" was simply that the physical > organization of a drop down menu system displays in visible terms the > categorical relationships. That's what I'm referring to, too.
> For example, prior to making an actual > selection, you can see what the current options are and the options > that can be taken by choosing one of the current options. I admit that this is often an advantage - for poorly designed hierarchies. If, for example, the main menu is "File", "Edit", "Show", "Add", "Format", "Tools", "Message", "Help", as in a typical GUI by Microsoft and friends in their software, how am I supposed to guess how to print the document or to search for a string? Why, by experience! But to anyone who faces the situation for the first time, the system you describe can be useful: he can quickly check each submenu (and then check them all again, still not finding what he was looking for, but I digress).
But if the hierarchy is well-designed, the approach is not needed. Granted, even a well-designed hierarchy isn't perfect. At times, it is not evident to the user which option he should select to get to the right next menu. But then it is generally better to use a Help system, or maybe Search, than to be able to go through the sub-menus fast.
> That > strikes me as being one advantage of a drop down menu over a > hierarchy of pages unless each page has some information about the > hierarchy in which it is embedded. Of course each page should have information about its context somehow, but that's not relevant. When you have separate pages for submenus, there's of course the overhead of opening a new page (and possibly going back). But it's simpler, more accessible, and easier to style. For navigation pages, you can concentrate on making the navigation proper the most prominent part of the page.
 Signature Jukka K. Korpela ("Yucca") http://www.cs.tut.fi/~jkorpela/
Haines Brown - 27 May 2008 13:34 GMT > Scripsit Haines Brown: > [quoted text clipped - 8 lines] > of selection, i.e. some hierarchy. But this means that you need to > divide the links into several _pages_. Sorry for the confusion. I did not mean to imply a list is a hierarchy, but meant a hierarchy of link-lists.
> Using CSS, you _might_ be able to put all the links on one page so > that at any time, only a handful (say, a dozen) of them is [quoted text clipped - 3 lines] > e.g. the total number of links on it. And "This page has six hundred > seventy-five links" isn't very promising. An example of a page that gets close to the plethora of links that you find problematic is: www.hartford-hwp.com/archives/ , which has 40. At least they are put into five distinct groups.
 Signature Haines Brown, KB1GRM
|
|
|