Functionality available from a toolbar should also be available from the menu
system. LINKs that appear in the Site Navigation toolbar should also be
accessible through the main menu bar (File, Edit, View, ...).
The default location to represent LINKs should be in the "Go" menu. Some LINK
types are more intelligently placed elsewhere in the menus. In those cases,
they should be omitted from the Go menu. Here's my first take at menu placement.
Most LINK types belong in the Go menu:
Up a level
<same as Document menu on toolbar>
About the page author
<unrecognized link types>
The rel="Alternate" LINK type presents us with an opportunity to do some really
intelligent placement of these links in the menu system. Let's use hixie's LINK
test as an example, <http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link1.html>:
<!--1--> <LINK title="The page in Dutch"
<!--2--> <LINK title="The manual in Portuguese"
<!--3--> <LINK title="The manual in Arabic"
<!--4--> <LINK lang="fr" title="La documentation en Français"
<!--5--> <LINK title="The manual for printing"
Alternates in another language can be used to populate a Translate menu, instead
of only offering programmatic translation:
The page in Dutch
The manual in Portuguese
The manual in Arabic
La documentation en Français
The last LINK in hixie's test is a special case. Instead of appearing in the
menu system, it should be used by the Print command to automatically select the
printable alternate (the UI would allow the user to override this and print the
All other alternate link types that we don't know how to handle intelligently
would need to be incorporated elsewhere in the menu system, probably in Go.
Two other LINK types afford intelligent placement: Search and Help. The default
menu items and their placement would be as follows:
Find in this page
Search this site
Search the Web
Help with this site
However, we'll use the TITLE attribute if provided. Given these LINKs:
<LINK REL="Search" href="/product-search.html" TITLE="Search foo.com catalog" />
<LINK REL="Help" href="/catalog-help.html" TITLE="Help using foo.com catalog" />
their respective menu items become:
Search foo.com catalog
Help using foo.com catalog
Similarly, the Bookmark LINK type can be incorporated into the Bookmarks menu:
Add a bookmark
File a bookmark
Personal Toolbar Folder
An alternate idea for Author and Copyright LINKs would be to omit them from the
Go menu and instead incorporate them into the Page Info dialog brought up by
View -> Page Info.
Implementing this enhancement would also fix bug 102909.
These are really good ideas. I especially like the integration with the Search
and Help menus etc. The only problem I can see is that this could make the Go
menu rather long. I'm pretty certain I saw a MachV menu spec that had the
history folders (Today, Yesterday etc.) accessible from the Go menu. We could
end up with a huge Go menu if both these enhancements are implemented.
> The only problem I can see is that this could make the Go
> menu rather long.
Agreed. Let's assume a few things:
1. Author and Copyright get incorporated into the Page Info dialog
2. we figure out another acceptable menu to put unrecognized link
types and the remaining Alternate LINK
Then we have a Go menu that looks like this (submenus collapsed):
Up one level
This is 7 new menu items. The longest menu, excluding dynamic length menus (Go
with long history or Tasks with lots of windows open) is the View menu with 13
items. Assuming a long browsing session the Go menu would grow to 23 items (7
static items + 15 history entries). If we reduce the number of history items
shown to 10, then we're talking about 17 items, only 4 longer than View. That
still close to enough to cause the menu popup to get scrollers at 640x480. Is
there a spec for what the maximum number of items can be in a menu?
If we can't put all the LINKs in Go, we can at least put some. I would omit the
LINK types in this order:
Lastly, I've always been afraid of the user experiencing confusion between
Back/Forward navigation and Previous/Next navigation. Placing both in the Go
menu would certainly demonstrate whether there was confusion. I can see someone
thinking Previous/Next is redundant with Back/Forward and believing that
First/Last are for jumping to the first and last page in their browsing history.
So, if for any of these reasons we can't put LINKs in the Go menu, we can still
incorporate my other enhancements. "Search this site" in the Search menu, etc..
Oops...the order of LINK types to sacrifice in the name of keeping the Go menu
short should have been:
And to avoid any confusion, I'm not suggesting any sort of dynamic behavior
here. I'm talking about leaving the items out entirely.
Link toolbar bugs should not go to me, but you probably know better who the
correct owner is.
Actually, I can do this one. Don't know if it's gauche to be both reporter and
I think it's perfectly acceptable to report a bug and assign it to yourself.
Otherwise you end up fixing things without telling anyone else!
I found the MachV menu spec. Actually, I found three but the Go menu seems to be
the same in all of them:
I'm not sure who made them. My best guess is German Bauer so I'm CC'ing him and
MPT for UI input.
Thanks for the links, alex.
Here's how I'd integrate LINK support with the MachV proposal:
Up one level
Site Just Visited 1
Site Just Visited 2
Site Just Visited 3
Site Just Visited 4
Visited 2-7 Days Ago
More Than A Week Ago
That's 16 items, the same as the MachV proposed menu. I sacrificed some of the
"Visited N Days Ago" submenus to make room for LINK menu items. Submenus for
anything beyond 2-3 days back suffer from diminishing returns. Most people have
a reasonable chance of remembering what they did today, yesterday, and before
yesterday. From my experience, everything beyond yesterday starts blending
together. Similarly people will have good success remembering whether they did
something this week or before this week.
So I've demonstrated that (some of) this enhancement can coexist in the Go menu
with the MachV proposal. The question remains of whether they should. I'm not
certain. The LINK items seem somewhat out of place with the history navigation
emphasis of the MachV Go menu. Again I'm concerned about confusion over the
meaning of Previous Page and Next Page.
I can't think of any good reason for duplicating the contents of the Links Bar
in a menu. We list author style sheets in a submenu; but they're things which
the user may want to toggle quickly, and which aren't important enough to have
UI in the content area for. Images are displayed in the content area, and we
don't have a menu for those. Frames are displayed in the content area, and we
don't have a menu for those. A HREF links are displayed in the content area,
and we don't have a menu for those. Now LINK links are displayed in the content
area (modulo bug 102990), so there's no point in having a menu for those. This
just seems like a way of making the `Go' menu even *more* complicated than
German's design, for no benefit.
No suprise that I object to bug 102990, so now the argument becomes: Back is in
a toolbar *and* in a menu. Bookmarks are in a toolbar *and* in a menu. Open
location is in a toolbar, and in a menu...
If the "content area" camp wins and bug 102990 becomes the UI for LINKs, then
your argument is valid. Otherwise, if the "chrome" camp wins, the precedent is
to have the functionality available from toolbars and menus.
I've read through all your comments, and there are some good input. Here is what
I say about the duplication of back and forward (and other duplicated elements
in the GUI):
These buttons and menus have always been duplicated, all the way since I first
tried the pre-Netscape browser, Mosaic, I believe, back and forward has been
both in the menu and in the toolbar. Therefore there is a good presedent for
keeping them there.
Dynamic menus are bad, so I'm pleased to see that no-one suggests it for this
Therfore, to the problem at hand, the site navigation bar. I belive it should be
kept in the content area. The flicker mentioned by someone is apparent in the
navigation bar today, so wheter it gets into the content area or not is irrelevant.
Another reason for keeping it in the content area is to always show it if it is
there, and to integrate it with the engine, so that other projects using the
engine will show the menu, regardless of if they know about this feature or not.
I remember I tried using links in the head after reading my first HTML spec. It
was back in the Mosaic days and I was disappointed that this really cool and
useful feature wasn't supported. Now that it is (and in many browsers) I think
it is important to let people see it.
It's just like the table, the frame, and dare I say it the blink and marquee, if
it offers something new (and this time allready in the specs!) which is useful,
people will use it.
Haven't worked on Mozilla for several months and this is unlikely to change soon.
Filter "spam" on "guifeatures-nobody-20080610".
The SeaMonkey team won't devote any resources on this. Closing as WONTFIX. In addition this sounds like extension fodder as well as a UI nightmare.