STEPS TO REPRODUCE Open an HTML file with multiple link elements with rel="next". ACTUAL RESULTS Only the first is made available. EXPECTED RESULTS The "next" button should sprout a down arrow like the back button, and clicking this arrow (or right clicking anywhere in the button) should pop down a menu of the various "next" links. Ditto for any of the other link types that have a dedicated button. cc'ing usual suspects as per bug 102832. mpt: Your advice on exactly how this should work is welcome.

cool new feature! ->claudius, since he tests toolbars.

Again, this worked in one of the incarnations, but doesn't do so anymore. Same area of code as bug 102896.

We probably want to be using <toolbarbutton class="menu">, according to the stuff in n.p.m.xpfe about the demise of <menubutton>. This may have worked before I fixed the toolbar to compensate for that XUL change. Gerv

What is the meaning of "multiple nexts" or "multiple previouses"? Only one correlation makes sense: going next or previous multiple times, similar to how the Forward and Back menubuttons let you make jumps through your browser history. Having multiple, author defined values for next or previous will only make the link toolbar a complex feature that most people avoid because it befuddles them. I don't see anything in the HTTP spec that suggests we must support multiple values for all link types, especially those link types that conceptually (to normal people) imply singular items. We have an oppurtunity to suggest a proper usage of link types, to give more guidance than the overly generic W3C recommendation.

I believe I commented about this back in bug 2800. One case where you could have multiple Next links is where the page is in multiple sequences that happen to intersect. For example, my "How I got Linux installed on my TSR-80" page might be part of a my own sequence (the "Tim's a Geek" series, next goes to my Macquarium page) as well as a web ring (the "Linux rules the world" ring, next goes to somebody else's Linux site). The author should be responsible for proper title attributes to differentiate these. I tend to think that as an aid to navigation, authors should probably only use one Next and Prev link per page. (Navigating with a single button click is easier than using menus all the time.) But not every site is structured with a single linear direction in mind, and even if it were, users may not think the way the author does and want alternatives, so perhaps the author tries to think outside the box to accommodate. I'm not sure how these menubuttons work (haven't downloaded a build with the fix yet). Does the first choice get used if the user just clicks, or does it expand the menu? Asking another way, does the user just click to expand the menu or does he need to click-hold? How do we signal the user that a button has multiple options in a menu? If it's done like the main Back and Forward buttons, that would be good, I think. BTW, I'm doing my masters research on web navigation and searching, so thanks to everyone who's made this happen. I was starting to think I was going to do my presentation in iCab or Lynx.

My point isn't whether we can think up possible uses for multiple previous/next links. My point is, how's the user going to expect previous/next menubuttons to behave? Considering that the 2nd most used interface in a web browser is the back button, and considering that back/forward navigation is so similar to previous/next navigation, making the behavior of the former menubutton behave different than the latter will cause quite a bit of confusing. The First, Previous, Next, and Last buttons are the most "inuitive" part of the link toolbar, because they mimic so closely how applications like PowerPoint use the same interface. Navigating along multiple, orthoganal, previous/next axes is /not/ an easy concept to grasp, let alone to design a UI for. Menubuttons simply don't cut it, even if you ignore the behavior precedent set by back/forward menubuttons. Here, BTW, is an alternative representation to overloading a single page with multiple next/previous links: Geek Webring: geek site n <--> Tim's Geek Series <--> geek site n+2 ____________|_______________ / | \ Tim's Geek series: VAIO HOWTO <--> TRS80 HOWTO <--> Java 123 ____________|_______________ / | \ TRS80 HOWTO: Chapter 1 <--> Chapter 2 <--> Chapter 3 <--> ... In this arrangement previous/next links actually make sense. At the scope of the entire site, you navigate among similar sites. Once you delve into a topic, you navigate sibling topics. Once within a topic, you navigate chapters, sections, or subsections. Think of the common case and make that real easy. The common case is paging through search results or forum articles, navigating a set or presentation slides, or thumbing through a photo album. These have a single, obvious previous and next page. I'm not opposed to multiple axes of previousness or nextness, but I am opposed to a substandard UI for this concept, and for impairing the UI for the common case to support an edge case.

What about the UI for a Twist-a-Plot book :)

I was thinking of that sort of thing too :-) But I think Tim is right. No-one has defined Link very well, and we get a chance to set a UI precedent. I think we have a great chance here to say "No, that's too complicated. Just because we _can_ do something doesn't mean we _should_." There are all sorts of other ways of doing multiple exit points - use the various methods under More, or add new link types of your own to the bottom of that menu. I'm not going to implement this, and recommend WONTFIX. Gerv

What happened to the UI we used to have, where we normally got a button for next, previous, etc., but if multiple links were defined, we'd create a drop-down menu? That seems like the best case-does the expected thing for most links, but authors with a real need to define multiple rel="next" can shoot themselves in the foot if necessary.

It probably died with <menubutton> recently. I still think we should do the UI to discourage the confusion called by multiple Next links. See my comment about "just because we can..." :-) Gerv

One of the things we have to remember here is how do we decide which is the 'best' link to be the default 'next'. We need a documented specification on this that we can show to web developers. Remember we can _not_ determine this by adding another type to the rel= attribute (alternate, default, whatever). There is discussion on this in the two status field links in bug 87428.

Spec's on my list of things to do (I'll bring it to one of these bugs for discussion, of course), after some of the simpler polish stuff gets taken care of.

Given that there is a very valid use case for multiple "next" links (see comment 7), and that the spec makes no mention of it being invalid, I see no reason to not support this. If authors consider them poour UI, then they can avoid using them. We aren't going to remove our support for frames, are we? Plus, precedent (namely, Lynx) is to support this.

FWIW, iCab shows one next link as a right-pointing arrow button. The other next link go in the genric link menu. (I'm not very fond of the idea of overloading the basic buttons.)

We could not change the appearance of the button, but merely do a popup instead of a take-you-to-the-link for multiple links. Gerv

> What happened to the UI we used to have, where we normally got a button for > next, previous, etc., but if multiple links were defined, we'd create a > drop-down menu? Did that ever exist? When I came along, the current toolbar had every single item as a menubutton. I found it so poor it compelled me to learn XUL so I could demonstrate a better UI. One assumption I made was that certain link types are better recognized only once, because conceptually they implied singularness and it made the UI simpler. Damn authors who want multiple axes of nextness, most users would benefit from a simple UI to move previous and next. What you suggest, switching between button or menubutton is even worse. People who become habituated to their previous/next buttons being buttons will not be pleased when their UI starts changing around on them depending on which pages they're on. If anything in the toolbar is ever going to be a menubutton, it must always be a menubutton. Example: Forward and Back are always menubuttons, even when there is 0 or 1 items to go forward or back to. With multiple items for every link type taken to its logical extreme we end up with: a) an inconsitent UI that deters habituation as toolbar items morph between being buttons or menubuttons and items of the More menu morph between menu items or submenus or b) an overwhelmingly complex UI with every single item on the toolbar a menubutton, and every item in the More menu a submenu

No offense taken :) The UI that I originally hacked up for 2800 supported multiple next/prev links. If there was only one, clicking the button took you there. If more than 1, clicking the button dropped down a list of the titles, from which one could pick. I think you might be blowing it a bit out of proportion. If someone clicks on a button and gets a menu, their brain isn't going to melt.

I confess my choice of words was too dramatic. However, I stand by this pearl of UI design widom: good user interfaces allow habituation. I'm referring to the kind of habituation Jef Raskin writes about in "The Humane Interface" or is referred to in cognitive psychology. A UI that changes around either prevents habituation (if it changes infrequently) or punishes habituation, by suprising the user when things don't behave as expected. Here's the specific problem with a toolbar item that change between being a button or a menubutton: Someone in the habit of using the next button in "button" mode won't be in the habit of avoiding the drop down portion of that same button in "menubutton" mode. They might not even notice that the widget looks different when they make a habituated gesture of clicking the button to go next. They may unintentionally click the drop down portion and get the menu popup when they were expecting to activate the button instead. This is jarring, moreso because it's a task the user become accustomed to, nearly automatic. They're immediately distracted from their task (going next), and have to change their locus of attention to the widget to figure out what went wrong. They'll figure it out and move on. But suprises in a UI are never good. They interrupt the users flow. Three different things will come about, depending on how often the user encounters multiple next links: a) if infrequently, the user will continue to be habituated to a "button" mode next button, occasionally getting the suprise of a popup menu b) if more frequent, they might learn to investigate the nature of the next button each time, using the visual difference to determine what mode it is in and avoiding the popup portion. This is bad because it prevents habituation because the user must turn their locus of attention away from the task (going next) to determining the state of the button c) also if more frequent, they might learn a new habit where they always click a smaller portion of the button, avoiding the area where the dropdown "might be". This allows them a return to habituation, but requires that they memorize the proper area to click on since there's no visual cue of the dropdown area when the button is in "button" mode. Sure, this is a small thing. However, it's the aggregate of these small suprises, good versus bad design, that add up to a good experience or not. Automagically switching between button or menubutton is bad UI design. That's why permanent menubuttons are preferred if we must support multiple links for all types. Lastly, an anecdote: people in Microsoft's focus groups clammered for dynamic menus, the kind where infrequently used items are hidden. However, when they actually made it into products, users complained, finding them hard to use. Their automatic gestures to select menu items get disrupted whenever an infrequently used item goes away, or a new frequently used item shows up. The ever changing menus prevent habituation.

sorry for the spam, didn't proof read carefully enough... > A UI that changes around either prevents > habituation (if it changes infrequently) or punishes habituation, by suprising > the user when things don't behave as expected. Should have read "if it changes frequently"

I don't quite follow you here. I admit, I have no idea about the XUL implementation of button versus menubutton. The place where you lost me is "avoiding the area where the dropdown might be". I am definitely not talking about a button where part of the button creates a drop down that comes and goes (like the forward/back buttons in the main navigation bar). Here's what I'm talking about: The Single Next Case. User clicks anywhere inside the asterisks and goes to the next page. +----------------------------------------------------------------------------+ | < > @ H _____________________________________________ |Go| |Print| | | | |-----------------********---------------------------------------------------+ | Top | Up | Prev * Next * Document | ??? | | |-----------------********---------------------------------------------------| ~ ~ +----------------------------------------------------------------------------+ The Multiple Next Case. User clicks anywhere inside the asterisks and a menu appears: +----------------------------------------------------------------------------+ | < > @ H _____________________________________________ |Go| |Print| | | | |----------------------------------------------------------------------------+ | Top | Up | Prev | Next | Document | ??? | | |-----------------********************---------------------------------------| | * Original Ending * || * Alternate Ending * | | ******************** | ~ ~ +----------------------------------------------------------------------------+ I don't see how this is punishing the conditioned user. They are still conditioned to click the next button, which hasn't moved or changed size. They simply have to make an additional choice. To me, this is the same as interjecting an extra step in the content, like this. +----------------------------------------------------------------------------+ | < > @ H _____________________________________________ |Go| |Print| | | | |----------------------------------------------------------------------------+ | Top | Up | Prev | Next | Document | ??? | | |----------------------------------------------------------------------------| | | | * Next: Chapter 2 | | * Next: Chapter 2b | ~ ~ +----------------------------------------------------------------------------+

I see Tool-Man's point about inconsistent and changing UI, and I agree. As a user it is frustrating, annoying, or at least inconveniencing. Mozilla's current Back/Forward buttons fall in this category, since the "history list" portion comes and goes, and the user has to learn to click where this list won't be. I think IE5 implements this better, always having the "down arrow" next to the main button to expand the menu. My question is, why couldn't our Prev/Next buttons be implemented like that? Click the main button, go to the default Prev/Next/whatever. Click the menu part and get a menu. As far as which <link> is the default for a button, we can't expect to read minds. :) But it makes sense (to me) that if you came from a different domain, your next page will also leave the domain; and if you came from the same domain, you will likely continue in the same domain. Within the domain, this could be extended to directories too. This may help disambiguate multiple <link>s at least in the case like I suggested, a webring vs my own collection. Even if we don't implement a menu for multiples, we need to determine which to use.

> Mozilla's current Back/Forward buttons fall in this category, since the "history > list" portion comes and goes, I don't know which skin you are using, but in Classic and Modern, the history list dropdown arrow is always present. However, I think this is precisely the wrong way to do it, because it is very annoying to hit the arrow when you wanted the button. And the buttons on the Site toolbar are small enough as it is. Here's my view: We could do this, in the way jwbaker proposes, but is is so _not_ a priority. The priorities are getting the toolbar XBLified and moved into the content area so we can turn it on by default. Has anyone started on that? Let's not do what the rest of Mozilla is prone to, and implement extra features instead of making sure what we've got works right. Gerv

> However, I think this is precisely the wrong way to do it, because it is very > annoying to hit the arrow when you wanted the button. And the buttons on the > Site toolbar are small enough as it is. The problem isn't the UI idiom, the problem is Mozilla's implementation of it. The dropdown buttons are round and tiny. It's hard to use because it's poorly designed in the name of looking modern. The Classic theme and Internet Explorer get the menubutton idiom right: large, rectangular, easy to click dropdown areas. The way Classic's buttons don't look like buttons until mouseover is a mistake, but that's another matter... > Here's my view: We could do this, in the way jwbaker proposes Argh. No offense, but jwbaker's suggested widget is even worse. This is bad for all the reasons that the a switcheroo button/menubutton is bad PLUS it's bad because it provides zero feedback as to which state the button is in. I would have no way of knowing beforehand whether I'm going to get a menu popup or just a button activation when I use the button. Only until after the click or mousedown would I know what I was getting.

For singleton link types (top, up, previous, next, table of contents, index, ...) the current implementation uses the first LINK of that type as the link to display for that type. In English, the first REL="Next" LINK encountered is used as the Next button. This is both pragmatic and consistent with other areas of determining priority, like the Cascade in CSS.

Well, now that we've heard 101 things that Tool-Man thinks are wrong, how about a telling us what you propose? I'm opposed to treating rel="next" as a singleton. It is a limitation that isn't derived from the standard.

I don't think treating certain types as singletons is in violation of the HTML recommendation. Agreed, it isn't derived from the recommendation, but it isn't prohibited. The W3C doesn't address multiples of the same type. My proposal is to mark this bug WONTFIX. Assuming that's unacceptable to the majority of people, a suitable solution would be for the additional links of a singleton type to appear at the bottom of the More menu where the unrecognized link types get added. This should satisfy the requirement that all links have an item in the toolbar.

_My_ proposal is to mark this bug Future and come back to it when the toolbar is in the state we want it, and we can think about enhancements. I would use LATER, but it's deprecated. Let's, please, spend less energy discussing the fine details of possible enhancements, and fix the really important bugs! Be warned; if anyone produces a patch for this bug, they are not getting review cycles or checkin from me. I'm serious. This bug should be off the radar. Gerv

> I don't know which skin you are using, but in Classic and Modern, > the history list dropdown arrow is always present. I beg to differ. Attaching screenshot (sorry, it's .bmp, all I have is MS Paint) to clarify. That said, I agree with your later comment. Let's get the important things fixed and worry about enhancements later. Put this off until Future. Like I said, most authors will probably only offer one Prev/Next link, so this concern is relatively small.

Sorry, bugzilla is puking when I try to attach the screenshot. Will email it to ya.

I can't read BMP files - I'm on Linux. But don't worry about it. Let's just leave this bug and move on. Gerv

*** Bug 106038 has been marked as a duplicate of this bug. ***

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Reconfirming Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100413 SeaMonkey/2.1a1pre c-c rev 5e3d80a05323 / m-c rev 82c37c003465