Closed Bug 2800 Opened 26 years ago Closed 23 years ago

No UI for HTML2 "LINK" element

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 87428
Milestone:
mozilla1.0

People

(Reporter: ian, Assigned: drbrain-bugzilla)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: helpwanted, Whiteboard: [Hixie-P2] PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt)

Attachments

(13 files)

Suggestions for implementation of UI for LINK element
13.40 KB, text/plain
Details
LINK GUI proposal ("screenshots" w/ explanations)
20.38 KB, image/png
Details
a diff of the changed files against the 07-18 tree
6.33 KB, patch
Details | Diff | Splinter Review
a list of the changed files and where they might go (but probably not) in the 7-18 tree
1.15 KB, text/plain
Details
Fully functional patch
39.53 KB, patch
Details | Diff | Splinter Review
Another patch for LINK element UI
35.89 KB, patch
Details | Diff | Splinter Review
Christopher Hoess' linktoolbar.jar (instructions below)
8.62 KB, application/x-java-archive
Details
Chris' latest update of linktoolbar
8.76 KB, application/octet-stream
Details
testcase: GNU make manual, 2492 anchor elements
467.18 KB, text/html
Details
testcase: GNU make manual as above, with 131 anchor elements with REL attributes
459.88 KB, text/html
Details
Tim Taylor's heavily modified version of linktoolbar.jar
8.13 KB, application/x-java-archive
Details
screenshot: Tim's linktoolbar with GNU make testcase loaded
16.18 KB, image/png
Details
Tim's changes + previous comment changes in XPI
7.95 KB, application/x-xpinstall
Details 
Test URIs:
 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link1.html
 http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link2.html

Expected Behaviour:
 http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3

For this bug to be completely fixed, the UI must be up and running. However,
as a start, NGLayout could actually understand and parse the LINK
information, and then when it comes to implementing it in the UI, it'll be
just a matter of making links and titles available on a menu.
*** Bug 2801 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → REMIND
QA Contact: 4110
Summary: HTML2 "LINK" element not supported → No UI for HTML2 "LINK" element
*** Bug 3173 has been marked as a duplicate of this bug. ***
From 3173:
>
> "I'd suggest either a dockable pane containing a list of the available
> navigation elements, or an icon (as on the menu bar) or small glyph (as
> sometimes appear on the status bar i.e. the security icon) to indicate
> that there is additional navigational options. This can be clicked on to
> give further options. The two could of course be combined... so that
> clicking on the glyph brings up the navigational box which can be
> minimised to become just a glyph again"
>
> The bug report is suggesting something very reasonable, but it's more of a
> feature request than a bug because the HTML4 spec suggests how this
> information could be used, but doesn't really mandate I'm changing the
> severity to "enhancement" and marking it REMIND so I don't
> forget about it, but we probably won't implement it for version 1.0
>

[ Changing summary, transfering QA contact from 3173 ]
Status: RESOLVED → VERIFIED
Verified RESOLVED-REMIND
I have attached some additional information which may be useful when this
feature is implemented. It is also available on the world wide web at:
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt
Status: VERIFIED → REOPENED
Since bug 1995 is now under consideration, and it is very similar, I am
reopening this bug.
Resolution: REMIND → ---
Troy, you may wish to reassign this bug to german/don/shuang in UE, as this
will probably require a spec before it can be implemented.

Note that I have already written a preliminary spec which is available at:
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt

Note further that this feature has already been partly implemented in the Lynx
browser for some time.
Assignee: troy → german
Status: REOPENED → NEW
Re-assigning to German for a UI spec
Note to rick/kipp/peter: Any generated content attached to the <link> element
should act as a link. See bug 6306.
Blocks: html4.01
Status: NEW → ASSIGNED
Priority: P1 → P3
Target Milestone: M10
latering to m10 and downgrading setting priority to p3. Likely candidate for
exposing this functionality will be the what's related panel inside the sidebar.
*** Bug 10747 has been marked as a duplicate of this bug. ***
Target Milestone: M10 → M16
Later.
QA Contact: chrisd → claudius
Reassigning QA contact to claudius@netscape.com. This seems to be a UI issue.
this will be past beta 1. If we for some reason do not get it into 5.0 we will
have to move it to 5.1
Component: Layout → libPref
The following internet-draft specified a proposed set of link relations. You
might find it interesting, even though it expired ages ago.

<A
HREF="http://www.groveware.com/~lee/papers/draft-ietf-html-relrev-00.txt">http://www.groveware.com/~lee/papers/draft-ietf-html-relrev-00.txt</A>
My two cents: using a sidebar panel for this would be a bad idea.

Ideally, the LINK attribute should be a way of implementing consistent 
navigation, without including global navigation links on every page (and 
stuffing up search engine indexes in the process). And some of these links are 
pretty important (author, next document, previous document, etc). A majority of 
people are going to have their sidebar hidden, so if LINK uses a sidebar panel, 
they'll seldom be noticed.

I'd suggest a pane which pops up at the bottom of the window for a document 
with LINKs; with icons for the semi-standard RELs, and a generic icon for any 
others.
OS: Windows 98 → All
Hardware: Other → All
Ack.

But wait, what if I want the links to appear at the top of the content window?

Pref, pref!
Then you drag the link bar to the top of the window, of course! (Once we have 
toolbars which can do that, that is.)
I think the browser should make a toolbar across the top of the page where I 
could give links to sections of my site.  It would be nice if I could provide a 
graphic for each link also, an icon or gif.   
This tag is also used for external stylesheets.  It might work to have 
everything with a rel= of "stylesheet" or "alternate" in a menu where it is 
more out of sight, and everything else in the toolbar.  
NCSA Mosaic uses this tag to make a toolbar.  Go to 
http://www.nemontel.net/~2ezfarm/cursor/index.html to see an example of using 
this tag.  
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend
Perhaps this would be better implemented as a collapsible frame, rather than a 
toolbar. It's a subtle distinction, but a frame would work better for a frameset 
and its frames, all of which had their own sets of LINK elements. With a toolbar, 
the toolbar elements would change every time you switched focus from one frame to 
another. You'd also have difficulty in getting at the LINKs for the frameset 
itself (since you can't give the frameset focus).

BTW, what is this doing in Preferences: Backend? Shouldn't it be in one of the 
HTML/DOM/Layout categories?

It occurs to me that these items should be added to the bottom of the 'Go' menu,
if Netscape 6/Mozilla has one (don't have a working build on this machine to 
check).

I'm not saying that they shouldn't also be some other more obvious UI as is 
being discussed above, just that these would make a lot of sense on the go menu.
(Go site home, go next etc)

Please see also bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=33684

which discuses an 'UP' button. I think an Up button is a great idea, but rather 
than simply chopping off the end of the URL as suggested on 33684 it should 
interact with the <link> tag to do something smarter.

One would simply grey it out for pages without the right <link rel=" " > tag 
defined - web sie authors would swiftly start thinking "hey that's cool, how do 
I get it to work on my sites"

This has the potential for *hugely* increasing the usability of the web. No more 
guessing where the next/previous/contents/index/search/site hompage links are 
hidden. (Though these could still exist, naturally). 

Not to mention this would make life easier for the makers of speech & other 
accessibility technology browers. (I know I've written one).

But it needs to be supported in a major browser like Mozilla to give the site 
authors out there incentive to support it. Otherwise you have a vicious circle 
that no one will use the tags, because none of the browsers have a UI for it, 
and none of the browsers have a UI because no one uses the tags :-(

based on the last comment, I thought you might like to see this, radha.

Aside from "Go" menu, I think there should be smaller navigation buttons 
(only textual?) below the location bar for this purpose:

^[________________________________________________]Go
<Up> <Previous> <Next> <Contents> <Index> <...>

If we get rid of funny gray strip, there is just enough room for these buttons 
below the location bar.

(Be sure not to increase the height of toolbar as it is already big enough (too 
big?)
For a good example of a browser using LINKs well, here's an article about LINK 
types with many iCab screenshots: 
http://www.euronet.nl/~tekelenb/WWW/LINK/index.html
In the screenshots at http://www.euronet.nl/~tekelenb/WWW/LINK/index.html
the LINK element toolbar is way too prominent, IMHO.

If both the browser's main toolbar and the LINK toolbar are rendered 
graphically, how to make eg. the browser's generic "Back" clearly distinct from 
the "Prev/Previous" LINK button?  Or the browser "Home" from the LINK 
"Home/Start/Top"?

The drop-down menu - see the last screenshot on the mentioned page - feels like 
a better solution to me.

See also Jakob Nielsen's review of (and some improvement suggestions to) the 
iCab LINK interface: http://www.useit.com/papers/icab.html
> the LINK element toolbar is way too prominent

That's because it's shown all the time, when it should only be shown when there 
are LINK elements in the page.

> how to make eg. the browser's generic "Back" clearly distinct from the
> "Prev/Previous" LINK button?  Or the browser "Home" from the LINK 
> "Home/Start/Top"?

By using different icons. And possibly by not allowing page authors to change the 
icons, either (though they might be able to change the colors).

> The drop-down menu - see the last screenshot on the mentioned page - feels like
> a better solution to me.

I don't think so -- just like putting it in a sidebar panel, that implementation 
would suffer from the problem that much of the time it would not be visible. LINK 
navigation should be shown *whenever* it is present -- it shouldn't require extra 
clicks.

I think those iCab screenshots are pretty nice.
Jakob Nielsen's setup where the link toolbar is small and *out of the way of* 
the other navigation buttons is interesting. Being all the way "over there on 
the right" seems, to my mind to be enough to differentiate it from the back and 
forward buttons.

I think the best way to do this would be to recognise a few of the "standard" 
rel="foo" names and use icons for those, but also use labels (the first 2 words 
of the rel ?). Buttons for which there is no icon would simply use the rel text 
label.

Home is the real problem - its confusing to have 2 home buttons, one for the 
site and one for the user's home page. What we'd probably want to do is make 
the label for the button 'Site Homepage' and try to think of a different icon.
Ideally we'd want to work out the site name "NBC Homepage" but there's not 
really a good way to work this out, unless we were to specify some meta tags 
that authors could use to enrich the information presented in the <link 
rel="foo"> tags. 

Can anyone think of a better term than Site Homepage? I was messing around with 
ideas like 'Front Door' but nothing quite seems to click (plus you need 
something you can localise).

Also - as the iCab toolbar shows, there's no reason not to have the icons *and* 
a more self explanatory drop down menu too. Its not like the drop down wastes a 
lot of space... 

So what do we need to do to get something built for this so we can play with 
ideas and gather feedback from the community? I'd like to see this happen in 
time for commerical Netscape 6. I can build on Linux and I'm willing to throw 
something together but I'm not exactly familiar with the codebase....

What do the netscape people think? Anyone got time to work on this, or to help 
me out a little? Is this the sort of thing that we'd be able to try out without 
writing C++ or is it going to take a little code to get it going?

The iCab toolbar seems nice. 

As I suggested above, it should be put under the url bar on the navigation
toolbar . In this way we have large back,forward, ... buttons on the left and
small icons below the url bar for LINK element UI.
We probably will not be able to make this one into this verison at all. Move to 
later milestone for future consideration.
Target Milestone: M16 → M30
Based on the discussion here, I created and attached a couple of imaginary 
screenshots of a proposed LINK GUI.  As you can see, it's kind of a compromise 
between the full button bar and the drop-down menu.

Some open issues:
 - Is the current set (Home, Prev, Up, Next) the optimal "most common" LINK
   navigation set?
 - Should "Previous" be abbreviated to "Prev"?
 - Is "Site navigation" an appropriate term to start with?
 - The UI still appears a bit cluttered to me when Personal toolbar and the
   "Site navigation" toolbar are both visible.  How could we improve this?

Opinions?  Comments?  Volunteers for an implementation? (We do want this before
Netscape 9, don't we?-)
| - Is the current set (Home, Prev, Up, Next) the optimal "most common" LINK
|   navigation set?

I think author/e-mail should be included too (rel="made"). This is supported in Lynx (just hit c to write an e-mail to the author of the page), and is a *very* useful feature.

| - Should "Previous" be abbreviated to "Prev"?

If 'author' is included, it probably should be.

| - Is "Site navigation" an appropriate term to start with?

'Site links'?
I like all this discussion, but can I please ask that you all read 
my "Suggestions for implementation of UI for LINK element" document which I 
wrote around a year ago? The latest copy is available here:

   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt

Important things to note from that document are the "rel" and "rev" attributes,
the "hreflang", "type" and "media" attributes, and the "alternate" keyword, as
well as a host of other issues.

Any implementation which does not take all of these issues into account are 
not complete solutions.
Component: Preferences: Backend → User Interface: Design Feedback
Great discussion.  As usual, whenever I think of an enhancement for Moz, other
people are already working on it :)  The screenshot attached here is a great
start, IMHO.  The other thing I am worried about is how to work the glossary
in.  I think it might be nice to add a "Lookup term in glossary" button for each
term that appears in the glossary, but really I haven't done enough
investigation to see if there are standard formats for glossaries.  My gut says
"no", therefore Moz would have to be pretty smart about linking.  

Perhaps Moz could extract every anchor from the glossary and use the resulting
anchor names as terms to highlight in the document.  

Suggestions?
adding self to CC:
I am currently attempting to implement this using just XUL, JavaScript, and 
DOM.  (I'm learning as I go, but it's easier than I thought)  I posted a 
document that describes some of the issues and problems with the design that I 
have encountered while reading the specifications and discussions.  In 
addition, I've described some of the options for implementation.  Hopefully I 
can get some feedback on these issues so we can finally add this HTML 2.0 
feature to Netscape.

http://www.prismelite.com/linktag.txt
| ------- Additional Comments From Tim Hill 2000-05-18 19:30 -------
|
| [ ... ] so we can finally add this HTML 2.0 feature to Netscape.

Great!
Pragmatically, in order to get page authors think that using LINK is a good idea, 
we really need the following. I'm proposing a couple of non-standard HTML 
extensions here; this isn't something I do lightly, but I really think it's 
necessary if LINK is ever going to have widespread use.

* LINK elements, when present, must always be visible. They must not be hidden in
  a menu, and they must not be hidden if the document happens to have been
  subsumed into a frameset (my LINK-reliant site must not lose all navigation if
  it happens to have been chosen as an AskJeeves answer, for example). That's why
  I say that LINKs should be a floating frame at the top of the document/frame --
  I think the W3C's statement, quoted by Tim, that LINKs `are NOT rendered with
  the document's contents' can be interpreted as meaning that LINKs should not
  scroll with the document's contents (just like toolbars don't).

* An (optional) LINKS element needs to be introduced which contains the LINK
  elements, and which is stylable in the same way as lists are -- it can be given
  background color, background image, etc. This is necessary in order for authors
  to have *some* degree of visual control over the navigation, without losing
  the general consistency in navigation that was the whole point of LINK in the
  first place.

* A NOLINKS element, akin to the NOFRAMES element, needs to be introduced to
  surround traditional navigation elements in HTML documents. This is necessary
  in order for pages containing LINKs to remain backward-compatible with browsers
  which don't support LINK, without having two sets of navigation on those
  browsers which do.

I agree with your first point.

Concerning your second and third points: There's no reason to have a LINKS 
element not a NOLINKS element, everything that you have described can already 
be done using CSS as is stands.

However, I'm not sure we want to allow the author to style the UI at all... I
mean, you're the one who keeps saying we want consistency in the UI and all 
that. Skinnable, yes, but if the look and feel of the links buttons/bar/
whatever change each time a user changes site, usability must suffer, no?

Tim: I'm working on answering your questions.

I don't think the LINK UI should be skinnable by a web page. Consistency is very important, and of the points of having the LINK element, is being able to have consistent (and therefore easy to use) navigation across web sites.
* Any implementation of LINK at all will be far, far more consistent than what we
  have now (which is a bunch of A HREF links in arbitrary places).
* We need to make LINK stylable to some extent, if a decent proportion of page
  authors are to consider it good enough (read: cool enough) to use instead of
  their traditional navigation (a bunch of A HREF links in arbitrary places).
* All that really needs to be stylable is the color (of the LINK label text), the
  background color/image (of the links bar), and the image used for the Home link
  (e.g. the site's logo -- consistency here is provided by the fact that the Home
  link is always the first link in the links bar).

| We need to make LINK stylable to some extent,
| if a decent proportion of page
| authors are to consider it good enough (read:
| cool enough) to use instead of
| their traditional navigation (a bunch of A HREF
| links in arbitrary places).

*Instead* of? They shouldn't use LINK instead of their traditional navigation, but in addition too. One reason is that only Lynx, iCab and Mozilla support LINK, but there are other reasons. Navigation is extremely important to a web site. Using only LINK will not be satisfactory. Often, the navigation is organized in a tree structure, which makes it much more easy to use than just LINK elements. A site can't (and shouldn't) rely on just LINK elements, but should use them in addition to its normal navigation bars.

| All that really needs to be stylable is the color (of the
| LINK label text), the background color/image (of the links
| bar), and the image used for the Home link
| (e.g. the site's logo -- consistency here is provided by
| the fact that the Home link is always the first link in
| the links bar).

What will be gained by this? The real advantage of a LINK navigation bar is that it'll look exactly the same on all web pages, therefore greatly improving the usability and making navigation both easier and faster (you don't have to "learn" a new way of navigating for each web site you visit).
LINK is part of HEAD, not of the BODY, and should not be styleable by the page 
just like the TITLE isn't.
Ian and I are hammering out a spec for doing this. We're in agreement on about
75 % of it so far. I'll attach it when we've finished.

Hi all,
Though this bug is assigned to me, I have not looked in to it, because I have 
other higher priority features/bugs assigned to me. Some of you have actively 
discussed specs and possible implementations. If anybody is interested in taking 
over this bug and implementing it, please go ahead. I think it will be a while 
before myself or somebody else will implement it.
Thanks,
Radha

Tim, since you are working on this I'm reassigning it to you. Feel free to 
assign it to me if you don't want it, I can find someone else to deal with it...
;-)
Assignee: german → tim
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M30 → M18
Accepting.  Moving target milestone from M30 to M18 (I can hope :)  ).  I'm 
waiting for the spec from Matthew and Ian, but working on the basic 
XUL/JavaScript implementation in the meantime.
At 2000-05-04 02:56, Antti Näyhä said:
> In the screenshots at http://www.euronet.nl/~tekelenb/WWW/LINK/index.html
> the LINK element toolbar is way too prominent, IMHO

Please notice that the primary nav buttons have been set to text-only rather
than graphical.

Great discussion here.  I'd love to see LINK support by Netscape beta/PR2.

There is also the possibility of multiple LINKs with the same REL value.  I
could set REL="next" HREF="my-next-doc.html" and also a REL="next"
HREF="webring.cgi?nextsite" for example.  The toolbar widgets would need to
expand into menus in this case.  The TITLE attribute could be used as the text
here, with HREFLANG info appended (if applicable).  If the user has tooltips on,
these could pop up when the user mouses over the button, too.

At 2000-05-04 04:35, Matthew Thomas said:
>> the LINK element toolbar is way too prominent
> That's because it's shown all the time, when it should only be
> shown when there are LINK elements in the page.

I disagree.  It should always be visible, so that authors and users will know
the feature is there for use.  The number of authors making use of LINK is small
now, but it will grow if its a known feature.



| I disagree.  It should always be visible, so that
| authors and users will know
| the feature is there for use.  The number of
| authors making use of LINK is small
| now, but it will grow if its a known feature.

I agree with this comment. If the LINK toolbar is always visible, "all" web sites will begin using the LINK element. This is a Good Thing!
Depends on: 42066
We now have a more detailed spec for this:
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt

Comments welcome. Sooner rather than later though, please, since Tim is already
working on this and we don't want him to have to redo it five times... ;-)

Its all gone a bit quiet! Great spec guys, now all we have to do is get the damn 
thing built :-)

To that end - I'm really a Java coder, C++ is not my strong point, and I'm no 
expert on the Mozilla source base, however I am willing to help.

I'm assuming adding the links toolbar to the xul has been easy enough - its just 
a matter of adding a new <toolbar> to the appropriate xul file, right?

So now it needs wiring up so the buttons actually *do* something. I assume this 
is gonna involve C++ whether we like it or not. (Javascript might be OK for a 
demo, but you're gonna have to catch documentLoad events and act on them).

This file shows a patch for nsWebShell.cpp that  the Java DOM guys have for 
getting document load events on Solaris:
http://lxr.mozilla.org/mozilla/source/java/dom/nsWebShell.cpp.patch

I doubt this is necessary in this case - presumably we can just add to code that 
already gets called on the document load event. Has anyone figured out where this 
might be?

Once we're notified that the page is loading we need to:

i) get a reference to the document
ii) walk the dom to find the links: something like

document.getElementsByTagName("LINK") though one could walk down into the HEAD 
element first.

iii) Process the LINK tags in accordance with the spec

Next get a reference to our XUL toolbar and somehow:

iv) enable/disable each button
v) build the popup menu
vi) wire each button and menu item so it opens the appropriate URL

To be honest, if we knew where this code needs to go and how to go about getting 
references to the objects we need, a spit and duct tape version could probably be 
hacked up in a day or 2. Error handling would take longer ;-)

Anyone know the guts of Mozilla well enough to be able to add any pointers to 
this bug? (sure wish there was some "getting started with these 10000 c++ files 
document :-| )

I'd be willing to do some the of typing, but my time for exploration is 
distinctly limited. I'm a fair C coder, but Mozilla seems to need some fairly 
funky C++ and it'd be a learning curve.


(this comment was also to be made available in 
x-minbari-warrior-caste-windswords-clan but transmission time at sublight speeds 
was deemed to be excessive ;-)



Been doing some heavy digging:

This file looks interesting - certainly there's a lot of logic for dealing with
LINK tags in here - its seperating out the rel=stylesheet ones from the others:
http://lxr.mozilla.org/mozilla/source/layout/html/document/src/nsHTMLContentSink.cpp

Still, I'm in two minds as to how we would implement the fix for this bug - and
the problem is that I fundamentally don't understand the Moz architecture. 

e.g.

maybe we want to be way down at this level in the Content Sink or maybe we want
to be several layers up in the code watching for document load events and
searching the DOM for the links. I dunno. 

Someone needs to hit the newsgroups and start asking impertinent questions ;-)
Don't Panic (TM). Tim is working on this, but (as I understand it) it's a slow 
job, and a proper implementation is dependent on a number of unfixed bugs (Tim, 
does the dependency list need updating?). If you want to help out, e-mailing 
Tim is probably the best thing to do.
I did hack up a quick version of this in a few days.  Now I'm working on the 
non-hack version :)  I put up a web site at http://www.prismelite.com/linktag/ 
if you'd like to track my progress.  I might put up the source soon so people 
can test it.

You can find out when a document has finished loading by using:
contentArea.addEventListener("load", onloadfunc, true);
Ideally, I'd prefer to be notified whenever a LINK tag is created or destroyed, 
rather than using getElementsByTagName.  But notification doesn't appear to be 
possible through JavaScript/DOM (DOM2 supports node mutation events but Mozilla 
doesn't support it yet)...

Since LINK tag support is kind of Layout (as well as kind of Front End), the 
implementation might be a bit nicer if done from C++... but unless someone is 
willing and able to do that (not me!), I'm going ahead with my JS 
implementation.  The main area where JavaScript is deficient is in getting 
notifications of new LINKs.
Whiteboard: http://www.prismelite.com/linktag/
http://www.w3.org/TR/REC-html40/types.html#type-links has a list of standard 
link types and this note:

"Authors may wish to define additional link types not described in this 
specification. If they do so, they should use a profile to cite the conventions 
used to define the link types. Please see the profile attribute of the HEAD 
element for more details."

(The profile attribute is defined at 
http://www.w3.org/TR/REC-html40/struct/global.html#adef-profile)

Do you guys think this is something we should care about?  Or should we just 
carelessly show all link types except those with the word 'stylesheet' - 
recognized or not - in the UI?
I sent an email to Ian regarding the link spec.  Hope you got it.

Antti brings up a good concern.  There should be some sort of general LINK 
handling feature in Moz, perhaps similar to iCab's "all LINKs" menu.  If the 
author put it there, it must be something important, and ought to be accessible 
in some way.  Also, browsers can outlive specs...more standard REL types may be 
added and this should be allowed for.  

I don't quite follow why we wouldn't want stylesheet types to be available 
though.  Perhaps web developers would like to see the text of the stylesheets; I 
know I would.  I think I mentioned this in the email to Ian, too.
Our current spec does say to show all links, except stylesheet:
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt

I guess we could decide to show stylesheets as well. Matthew: Is there any
particular reason to avoid those?

Tim: One thing though is that "stylesheet alternate" does not mean that the link
is an alternate version of this document. So we need to take that into account
even if we _do_ show stylesheets.

I still think we need a decent LINK API. See my comments in bug 7515.

BTW, Tim: You rock. ;-)
Depends on: 7515
Whiteboard: http://www.prismelite.com/linktag/ → PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
REL type "alternate" should always indicate a secondary option of the other 
indicated REL type.  If "alternate" is the _only_ REL type, then it indicates an 
alternate web page (different language maybe, or whatever). 

For instance, you could have "next" and "next alternate" LINKs.  The former 
indicates the next page in the 'typical' sequence, the latter the next page in 
an 'alternate' sequence.  I alluded to this in my comment on 2000-06-08 12:06.  
The Next button would have a default action, but could also open a menu since 
there is more than one option available.

Similarly you can have "stylesheet" and "alternate stylesheet" LINKs that the 
user could switch between.  This might be messy when multiple stylesheets are 
meant to be used concurrently.  I might want one stylesheet the always applies, 
and additional ones that the user can switch between, one of which may be 
applied by default by not specifying "alternate".  If I switch to the alternate 
one, will it...
1. Be applied in addition to the other two
2. Replace the other current secondary style
3. Replace both current style sheets
This bit is outside the scope of this bug (2800) but it's a valid concern.  I 
don't know how Moz currently applies (multiple) styles.  
Tim Larson wrote:
> REL type "alternate" should always indicate a secondary option of the other 
> indicated REL type.

Woh -- hang on, what makes you think this? References, please! What you say is
the OPPOSITE of what the HTML4 spec says.

   http://www.w3.org/TR/html4/types.html#type-links


> Similarly you can have "stylesheet" and "alternate stylesheet" LINKs that the 
> user could switch between.  This might be messy when multiple [...]

HTML4 is *VERY* precise about this issue. Mozilla implements it correctly, as is
shown by my ImportTest suite (you can only see this from Viewer at the moment).

Unfortunately, the HTML specification remains somewhat vague on what multiple 
link types in the same "rel" attribute mean.  It just says "rel" is defined as:
<!ENTITY % LinkTypes "CDATA" -- space-separated list of link types -->

"alternate" used by itself refers to an alternate form of the current 
document.  "alternate stylesheet" uses "alternate" to modify the meaning 
of "stylesheet".  What exactly the following values would mean is debatable...  
Does it apply to all other rel values?  Some?  The ones before?  The ones after?
rel="alternate next copyright"
rel="next alternate copyright"
rel="next copyright alternate"

Even though HTML uses "alternate" to modify the semantics of "stylesheet" (I 
think it SHOULD have used "alternate-stylesheet"), I hesitate to introduce rel 
values (such as "alternate") that modify others, yet look syntactically the 
same as normal values.

The way it's designed now, you can already generate a menu for the "next" 
button by including more than one LINK with rel="next".

The primary reason to hide stylesheets in the Link Navigation menu is that most 
users don't care about viewing the source code for stylesheets.  In addition, 
the list of stylesheets will eventually be accessible from View > Use 
Stylesheet.  For web developers though, stylesheet source should be accessible 
from the "View Source" window.
Ian Hickson wrote:
> http://www.w3.org/TR/html4/types.html#type-links

Hmm, I have been totally misreading that part for some time, then.  I stand 
corrected.  By some mental lapse I thought that alternate referred to the object 
of the LINK, and thus extended to all REL types.  (Made sense to me at the 
time.)  Tim Hill's comment sums it up I suppose.

> HTML4 is *VERY* precise about this issue. Mozilla implements it correctly 

As I haven't seen a mechanism for switching style sheets anywhere in Moz yet, I 
guess I'll have to take your word for it.
I doubt there's much point in putting stylesheets in the menu.

Mozilla's View->Use Stylesheet menu will (when it works!) allow you to switch 
between stylesheets quite nicely, actually reading the things is only of 
interest to developers, and they know how to find the names and download them 
with "View Source".

This is a new feature that could be of great benefit to end users, and we need 
to avoid cluttering the interface with "geek friendly" features so that it 
remains easy to understand and use. (Especially those geek features where the 
geeks know there's already a way to do it.)

As for C++ vs. Javascript I have no vested interest in doing it either way.
I'm surprised it can be done in JS at all though! (New respect for Mozilla).
Where on earth do you put the script s.t. it's called for every page loaded? 
Its not in a web page obviously...

I guess whether a C++ implementation is necessary depends on 

i) are there anyu issues that simply aren't solvable from JS. Tim seems to 
think there might be

ii) Is this the only component in Mozilla that works this way? If everything 
else like this is implemented in C++ following some standard pattern we would 
want the implementation we have to use the same pattern, so as to simplify 
maintainence.

iii) Is the JavaScript version too slow?

In any case I applaud Tim for getting this done... We should certainly work out 
all the issues we need to solve with the JS version then present this to the 
relevent module owners to see if we can get it included, or whether they feels 
it needs to be implemented in C++.

I have real hope this will get into NS6 now. Beta 3 anyone?
lordpixel wrote:
> Is this the only component in Mozilla that works this way? 

Well... most of the interface is written in JavaScript, actually. JavaScript for
the work and XML and CSS for the interface. Scary huh. ;-)  Look in the "chrome"
directory for proof...


Tim Larson wrote:
> As I haven't seen a mechanism for switching style sheets anywhere in Moz yet, 
> I guess I'll have to take your word for it.

Run "viewer" and look in the menus.


RE: the stylesheet thing -- on thinking about it, I think it is best to leave
the stylesheets out of the menu, and leave the showing them business up to
View Source or Page Info. It's too geeky to be part of the standard UI.

I think we should maintain a list of recognized "navigational" rel/rev values, 
and _only_ show a LINK element in the Navigation menu if the rel/rev value is 
found on the list.

Some examples of LINKs that make absolutely no sense in the Navigation menu:
 - style sheets
 - P3P Profiles: the draft uses <link rel="P3Pv1" href="URI">
 - TrueDoc fonts: <link rel="fontdef" src="URI">
   (note, though, that this is using a non-standard 'src' attribute and
   such things should be done with CSS anyway)
 - RDF sitemaps
 - a lot more to come in a few years, probably.

It wouldn't be reliable to solve the problem another way around (by having a 
list of "non-navigational" rel/rev's) since new link types are being born all 
the time.

Of course, "non-navigational" LINKs might be shown in another place, such as 
View -> Page Info.

PS. I just noticed that the 'href' attribute is not required in HTML 4.  Thus, 
it should be added to the spec that all LINKs with no href attribute should be 
ignored while constructing the Navigation menu.
I agree, the problem is LINK can serve two purposes -- presenting a human-
understandable User Interface and being a machine-readable link to other 
files.  And so far, it's been used mostly by software 
("stylesheet", "fontdef", "P3Pv1", "schema.dc", "shortcut icon"). 

Possible solution...  Only display items in the Navigation menu that specify 
a "title" attribute.  Exception: stylesheets would not be shown in the 
Navigation menu, title or no title.  Exception: the "title" attribute for the 
standard navigational items (top, up, previous, next, possibly others) could be 
left unspecified or blank and still appear (i.e. as "Next" instead of "Next: 
Chapter 3").  Advantages: 
1. Good backwards-compatibility.  Most LINK tags intended for machines don't 
have title attributes, as far as I know, so they'd automatically be hidden.
2. Extensibility.  New REL values could still appear in the UI.  Specifying a 
title probably means that you wanted it to be read by a human.  
3. Consistency.  This is similar to the way persistent stylesheets vs. 
preferred/alternate stylesheets are treated in the HTML spec.
A test version of the LINK tag interface is now available...
http://www.prismelite.com/linktag/
First off, I'd just like to saw congratulations and WOW!
Great job. Now what we need to do is push this to final quality and get it landed 
with the help of the module owner.

However, the first stage of that is for me to tell you all the bugs I found.
We should also decide whether to keep using this bug or whether to open new bugs 
to cover any issues.
I'm testing on Mac OS and I can also test on Linux, though less frequently, so if 
any other Linux users want to get involved that would be great:

Here are some problems:

****We need to confirm whether these are Mac specfic, so people get reproducing!
****This issue alone will probably force us to open new bugs. If issues are
****plaform specific we should use Bugzilla to track this accurately

* Crash with mailto: links. This html, which Lynx browser users will recognise
is commonly used to specify the author of a page:

<link rev="made" href="mailto:whoever@foo.com">

When linktag 0.5 hits this it generates a button calle Author, and add it to the 
Site menu.

a) bizarrely, the Author button seems to have a drop down menu. Why?

b) When I select the mailto: link the browser crashes. Messily.
This could be a general bug in mailto: support but I could not find any such
bug. Are other people seeing this problem.

Note: I may not have any mail accounts set up in Mozilla, so it could be trying
to launch the new account wizzard. Please also try to check this possibility.


I decided to split each bug out into a seperate comment, at least.
Apologies for all the spam!

* Tooltips: These should behave like other Mozilla toolips, appending the title=
"" atribute to the URL when possible. (i.e. when both exist) and using 
"Location: URL" if we decide to display any links that do not have titles set.

Regarding the crash with mailto: links...

...cannot reproduce this on Windows NT 4 Workstation running SP 6a. The mail composer came and launched the account wizard successfully. No crash.

See http://www.brookers.co.nz/catalogue/ for the page I used to test this.
* The icons on the Link toolbar highlight on Mouse over even when the button is
disabled

* icons look *really cheesy* on the classic skin :-)

* Site menu doesn't look like a menu on Modern skin. No down arrow

* Why is this menu called site? I don't think a new user would understand this.
How about "Site Links"

* Is there a reason the Site menu comes first? For some reason I always though it
would be the last element in the toolbar, as it seems more obscure than the
Top and Up buttons, which is what I expected to be first 

* Why doesn't the toolbar load until I go to a page that has <link> tags?
Once I've visited one page it stays up. Is this by design or is this a bug?

* Why is the icon for the site menu a circle? No icon may be better

* Position of the toolbar. One of the things I liked about the iCab
implementation (links to screenshots are elsewhere in this bug) is that it was
right aligned. This kept it completely seperate from the other controls (no way 
to confuse Top with Home or Next/Previous with Back/Forward) because several 
inches of space seperate them.

For the sake of simplicity, I'll describe using the modern skin.
Could we:

i) right align the toobar within the blue stripy area such that its right hand
edge aligns with the right hand edge of the address box (i.e. its under the 
search button

ii) Can we move it into the grey area, so it sits under the throbber, right up 
against the right hand edge of the window? That way it doesn't (imediately) get 
in the way of the personal toolbar.

Trouble is I'm not sure how flexible Moz's toolbars will eventually be. If 
they're as good as the ones in MS Office and IE then the links bar should be a 
seperate bar that the user can drag around and put where they please. I'd still 
prefer under the throbber for the default though. Thoughts?

Final note:
Apologies for all the spam. I think this bug is going to have to spawn children 
very soon.

Also, I'm not trying to be mean to Tim here. I think the work he's done is 
wonderful. I'm trying to play devil's advocate and question everything.

Ok, I know I said the last comment would be the last for tonight, but this is 
important.

It seems linktag 0.5 is not playing nicely on the Mac with build 2000071810 at 
all. I tried clicking the same mailto: link in Mozilla 2000071810 with linktag 
0.5 added, and without and in the one with linktag it crashes, in the one without 
it works perfectly. 

n.b. this was not a mailto: link in the links toolbar. It was an "ordinary" 
mailto: link in an <a> in the page.

This does not look good. Someething is obviously getting screwed up.
Can someone delete all their mail profiles from Mozilla so that when they go into 
Moz Mail&News the account creation wizard pops up autmoatically?

I want to see if that will trigger a crash on Win32 and Linux.

That said - LinkTag should not be causing unrelated parts of the browser, like
 <a href="mailto:foo@bar.com"> foo</a> to crash under any circumstances.

I can give you stack crawls if need be, but I figured they'd be little use as its 
written in JavaScript.

I really think we need to have a discussion/debate in the 
netscape.public.mozilla.ui newsgroup (this bug is getting rather long) about 
what the "default" LINK items should be.  There's plenty of disagreement about 
that right now :)  Another big issue is where the toolbar should be positioned, 
how big it should be, when it should appear (only when there are link tags is 
the designed behavior), icons/text, etc.  

I think I've had a crash before with mailto and no account configured, but I 
doubt it's due to me (though crazier things have been known to happen).  I 
can't reproduce it anymore.  If you can repeat it consistently, with the EXACT 
same conditions for no linktag / linktag (i.e. registry and profiles deleted), 
let me know.

The Author button is actually a menu, so if you included multiple authors it 
would display them all.  There are many skin-related issues remaining including 
the ones you mentioned.  The site icon is a circle, and the icons are cheesy 
because I'm not an artist :)  The icons and text wording can easily be changed 
though, since it was designed to be skinned and localized.
OK, I did a full regression test on the mailto: links, deleting all the
registries and profiles between attempts and it does indeed look like a false
alarm. Sometimes Mozilla does crash when trying to invoke a mailto: link but it
has nothing to do with Link Tag per se.

A couple of other notes: I'm up for a discussion in the UI newsgroup. Should I
just start it anytime or should we arange a time for a few of us to get together
an begin, to gets things kicked off in a lively fashion?

I truly believe the Links toolbar should be on all the time.

Two things about the author menu -

i) the menu always appears blank to me. It works, in that it tries to start the
Mail and News compoent when I select the first item, but there is no text

ii) I thought the plan was that when a menu button on the links bar only had one
entry it would act as a button, without the menu appearing? Is there some bug
which blocks this?

Oh, and Mathew T - are you going to put this into Aphrodite when its done?  
Things seem to have stalled againand doing a diff against a recent navigator.css 

is also making me worry this is bitrotting.



One thing I forgot to mention before: 



I don't seem framesets as a big problem.



I figure do one of two things:



i) Ignore <links> in the <frames> and just go with what's in the <frameset>



or



ii) Start by adding everything in the frameset, then add/overwrite with any links 

from the sub frames.



Why not? There's no signifcant existing implementation to be incompatible with, 

and since, like so many things about framesets, the semantics are undefined, why 

not just do what feels best?



Chances are most people won't add <links> to both the frameset, their main frame 

and their navigation frame, but if they do we should either just use the frameset 

(to a user its the main document no?) or try to include everything and simply 

clobber links from the frameset if they're repeated in the body.



The first approach assumes the frameset is the master document and overrides 

everything else the second assumes that "deeper" documents are better. Actually 

I'm leaning towards the second option because rel="previous" and rel="next are 

likely to be set for the documents in the frameset.


I've just tried the test version, and I think it's great. This is one of these 
features which will make Mozilla "cool".

Ordinary users don't notice better standard supports, small bug fixes or 
similiar new features, but they'll notice LINK support, search panel in sidebar 
and themes support. This is what'll make Mozilla feel like a much better 
browser.

I've always used the LINK elements on all my web pages (well, Lynx supports 
them), and they feel so much easier to navigate using the Mozilla LINK support. 
This *needs* to be implemented in the nightlies soon ...

Also, should there be a separate button for rel="Bookmark" links? These can be 
used to create a table of contents for a (single) web page, or just for links 
to sentral parts of a page (not site). For an example, see the W3C home page 
<URL:http://www.w3.org/>. Very useful!
Be aware that since the 17th of July build that linktag is known to be compatible 
with, there have been some changes (nothing major) to navigator.css.

Since linktag replaces this file, you're actually "damaging" any more recent 
build in the sense that you're undoing those changes while applying the linktag 
changes.

This is bitrotting as we watch :-(

There seems to be a phenomenal lack of interest from anyone at Netscape in 
getting this in for 6.0, given it blocks full HTML 4.0 compliance, this is 
surprising. Lets face it, I think by this stage we can forget about this being in 
6.0. Beta 2 was supposed to be feature complete, so the only stuff getting in now 
is work thats being champione by someone at Netscape, which definatey rules this 
out.

:-(

I wouldn't complain that there's a total lack of interest from Netscape when all
the people from Netscape cc:ed on this bug have absolutely nothing to do with
the UI.  cc:ing ben.
>I wouldn't complain that there's a total lack of interest from Netscape when all
>the people from Netscape cc:ed on this bug have absolutely nothing to do with
>the UI. 

Agreed. Mea culpa. 

We should definately start a thread about this in xpfe and ui newsgroups (any 
others?). I'll do it if no one else feels they can, but I think people other than 
me may have a better grasp of the issues. Let me know...

fwiw Hixie is @nscp. cc'ing blaker (also nscp).  for reference versioned diff's 
are much preferable to replacement files.

Hixie does this get a cssX keyword?
Keywords: helpwanted, nsbeta3, patch, review
I am working on a source patch against current CVS right now.  Let me know if I
am duplicating effort.

FYI, my patch will implement the link widgets as their own toolbar.  There
simply isn't enough room to jam them underneath the Location input on the
navigation toolbar.  IMHO.
I've got it working on the new Modern skin.  For some reason, the icons aren't
being styled in, but I'm working on it.

Give me some feedback on this screenshot:
http://atari.saturn5.com/~jwb/linktag-modern.gif
Excellent work, Jeffrey. It's own toolbar is exactly what LINK needs. The most 
obvious problems from the screenshot:
(1) the toolbar should appear below the Bookmarks Toolbar, not above it. (This is
    because it should only appear when there are navigation links to show,
    otherwise users won't notice when the links are active. And we don't want the
    Bookmarks Toolbar to be jumping around, depending on whether the Links
    Toolbar is visible or not for a given page.)
(2) `Site' should be `Site home'.
(3) It looks as though all the items are menus. If so: that's wrong -- they
    should only be menus if there is more than one link with the same rel/rev
    value. If not: then get rid of those triangles.

Sorry for the non-CVSed "patch", I only recently got a proper tree and C++ 
compiler setup.  I've also been busy working on a few other things...

I did try to bring the subject up in another bug about having a LINK tag 
toolbar, but didn't get much response there.  I agree that the navigation 
toolbar is over-crowded, especially with all of the other buttons being added 
to it.  But should the content area really shift up and down every time you 
enter and exit a LINKs page?  I found this annoying.  We already have enough 
chrome.  The second issue to decide is what the default buttons should be.  
i.e. "Top", "Up", "Previous", "Next", etc.  The third issue to address is what 
the link tag buttons should look like on each of the skins.  Should we re-use 
an existing button style class that will look good on both Classic and Modern, 
or do Link Tag buttons need their own unique button style class?  Both Modern 
and Classic are in a continual state of flux.  It's nice to re-use existing 
style rules as much as possible, but Link Tag buttons have special requirements 
over plain buttons... in addition to a graphic on the left side of the button, 
a drop-down arrow on the right side of the button should be visible if the 
button is a button-menu, but otherwise it should leave a blank space.  Finally 
I have a few more bugs to squash in the code itself.  If someone wants to work 
on the skinning portion of this, I'd appreciate the help.
Tim: Using your javascript, I don't ever get the icons I see in your screenshot.
 Each button has the little diamond next to it (see my screenshot).  Is this one
of your known problems, or something messed up in the style system?

I'm > 75% done with the conversion to a CVS patch, and I am also converting the
GIFs to PNGs.
One other thought: The amount of content here almost makes it more useful as 
part of page info in a sidebar.

I don't remember which bugs discuss sidebar features maybe mpt can mention 
them.

I also need to see if we have support for autohiding the sidebar, because if we 
did, this sort of stuff would me much more useful.

Ben any thoughts or comments?
Re: the shifting content area, I don't really think that's a problem. At least, 
it's as much of a problem as any other issue with content moving around during 
progressive display of a page. We *want* something obvious to change between when 
a page uses these links and when it doesn't, otherwise users just aren't going to 
notice.

Re: the sidebar idea, see my comments in this bug on 2000-02-01. (And
auto-showing the sidebar would make the content shift around even *more* than 
with a toolbar.)

Re: the page info idea, LINK elements (and their HTTP equivalent) are what I 
refer to as `intrinsic' links in the `Links' tab of <http://critique.net.nz/
project/mozilla/general/component/info/>. But if we restrict the UI for LINK to 
that, we're only really being useful to Web developers, not Web surfers.

I've rolled the patch forward to current CVS.  See my patch at
http://atari.saturn5.com/~jwb/linktag/

What you get from this patch is a functional linktag toolbar in the modern skin
only, with the wrong icons.  Actually, you don't even get the icons because I
didn't include them in the diff.

Anyway the port forward was pretty easy.  I'm going to wait for the dust to
settle around the Modern 2 skin before I pick up this work again.  Once the
skins settle down, we need to:

1) Maintain the patch against current CVS
2) Change the icons to PNG
3) Find out why the icons aren't being switched properly in linktag.js
4) Make the drop down menus look like other Mozilla drop down menus
5) Get checkin approval
6) Checkin

When is our best shot for getting this in the product?  My gut feeling is either
right now, or just after we branch for the next milestone release.
Regarding comments by Matthew Thomas (2000-08-27 17:06), I think the LINK
toolbar needs to be present at _all_ times.  (Others have said this before.)
LINK is an incredibly useful feature that's been ignored since HTML2.  Awareness
needs to be raised.  Right now so few sites implement it that it's very likely
no one will ever notice that Mozilla supports it.  If, OTOH, an iCab-like
approach of "graying out" inactive buttons were used, people would say, "Hey,
what is this?  How can I make it work for me?"  Heck, this is exactly what
people are doing with the completely non-standard MSIE favicon.ico thing.
Please don't hide LINKs in the sidebar, either.  I minimize the sidebar all the
time, because it grabs _way_ too much content area.  If the space the extra
toolbar chrome will use is a concern, make it possible to toggle it off in a
preference panel, or minimize it like you can the other toolbars.
> If, OTOH, an iCab-like approach of "graying out" inactive buttons were used,
> people would say, "Hey, what is this?  How can I make it work for me?"

Web developers would say that. But end users would just see a bunch of links that 
(99 percent of the time they looked) were disabled. So they'd turn the toolbar 
off, because it apparently didn't do anything.

And I think Web developers are going to work out the coolness of LINK by 
themselves, without us taking screen real estate away from users in the meantime.

> We *want* something obvious to change between
> when a page uses these links and when it
> doesn't, otherwise users just aren't going to 
> notice.

Exactly! I actually like the way it's currently implemented (with the LINK bar 
appearing below the location bar). It would be nice if it were a separate 
toolbar too, as long as it appears/disappears on web pages using the 'link' 
element. It should IMO *not* be just grayed out. This will cause people to 
disable the toolbar, and those that wouldn't probably wouldn't notice that it's 
not grayed out on page using the 'link' element.

One other suggestions related to the rel="bookmark" attribute. There could be a 
button for an automatically generated table of contents. This should be a 
simple drop-down menu (like the other buttons) showing all the headings 
('h1', 'h2', 'h3' &c.) in the document (with 'h1' centered, 'h2' left-
aligned, 'h3' left-aligned and indented, 'h4' left-aligned with more indention 
&c.). This will greatly encourage web page authors to use real heading elements 
instead of <font size="5">Headings</font>. Should I open a separate bug for 
this?
> Web developers would say that. But end users would just see a
> bunch of links that (99 percent of the time they looked) were
> disabled. So they'd turn the toolbar off, because it apparently
> didn't do anything.

A good chunk of the early Mozilla adopters _are going to be_ web developers.
Even if they're not, seeing the feature work even _once_ is going to get some
exec's brain clicking, and he'll tell the web team to make it work.  That's how
the IE favicon thing is growing.  So if Mozilla is going to implement the LINK
UI anyway, make it customizable.  (Note IE doesn't let you turn off the
favicon.)  Make it a three-way option [always on, only when LINKs present,
always off] if you want.  I'll just set mine to "always on".  Does this meet the
requirements of not stealing real estate now, yet allowing for coolness when
developers catch on?  I hope so.

Regardless of the initial state of the toolbar, when it _is_ visible the
standard LINKs (whichever they end up being) that are not available on the page
should be grayed out.

Might want to use "Main" instead of "Site Home"--keeps it distinct from the 
user's Home page.
The LINKs can be in the sidebar, as long as it's available from a toolbar too. 
The perfect place for it in the sidebar is of course the What's Related panel.
Reading the discussion of using frames vs using toolbars, I can see the
arguments for both, so it seems that we need a pref. I think the available
options should be (the wording is bad, but you get the idea...):

* As a frame above every frame that provides LINKs
This would add the 'toolbar' in the form of a small frame above every frame that
provides LINKs (other than stylesheets).

* As a toolbar (always on)
This would put the toolbar immediately below all other toolbars. It would
display at all times, and the frame that applies would be chosen by the
following algorithm:
- If no visible frames have links, display only the standard buttons and disable
them all.
- If only one visible frame has links, use that frame always.
- If more than one visible frame has links, then choose one arbitrarily when the
page first loads
- When a frame with links gains focus, take the links from that frame
- When a frame loses focus, *do not* change the links unless the focus was
transferred to another frame with links.

* As a toolbar (appearing when needed)
This should be the default. The same algorithm as above should apply, except
that if no visible frame has links, the toolbar should be hidden. In addition,
if possible, a "lazy" algorithm should be used to determine when to display this
toolbar - create only when it is known for *certain* that (at least one of) the
currently displayed frames has links, and take it away only when it is known for
certain that no frames do. Thus, when navigating between pages that all have
links, the toolbar would not disappear and reappear between page views.

I think the coloring should match the page canvas if a "frame" is used, but
match the rest of the toolbars if a "toolbar" choice is used.

Thoughts? Any comments on ease of implementing this with the current toolbar
implementation?

Changing the icons can be done later. Fine-tuning the wording of the links can be 
done later. But now can we just check in this baby? (Please?)

I'd suggest ignoring link rel="icon" in the same way as we ignore
link="stylesheet", for forwards-compatibility with bug 32087. But that's not a 
blocker for this to be checked in, really.

I understand your frustration.  Since it seems that new modern skin has landed,
I am proceeding on my work to port the patch forward on both modern and classic
skins.  I expect to have this work complete by September 11.  If I don't post my
patch here by then, ping me again.
Just a warning. I've picked up from the newsgroups that September 14th seems to 

be the last possible day to get anything checked in to make beta 3. Don't know 

this for certain but a couple of comments have suggested this.


> I expect to have this work complete by September 11.

Well, it's September 12 now. Is is finished?
Okay kids, the patch is ready.  I have implemented the linktag toolbar in
classic and new modern.  The link widgets are in their own toolbar, which can be
toggled with view->link toolbar.  The toolbar disappears when there are no LINK
elements.  I also ditched the icons because they looked goofy on both skins.

Anyway, lets leave the details for later.  When need to get this checked in
today, in the next few hours.  I volunteer to own this thing from now until we
ship.  All I need is a quick review, and checkin approval from brendan or
waterson.  Who should review this patch?
Attaching the patch to the bug would be a good start.  Perhaps 

ben@netscape.com should review?
Reassigning to Jeffrey.  I'll try to help out since linktag.js is mostly mine, 
but I'm a bit too busy right now to work on this.  Should this go in right 
before nsbeta3; how long a period before the final release?  Is there really a 
UI feature freeze?
Assignee: tim → jwbaker
Status: ASSIGNED → NEW
Accepting.  The patch is attached.
Status: NEW → ASSIGNED
> Is there really a UI feature freeze?

YES! See 'UI Freeze' in n.p.m.seamonkey.
Patch looks pretty good to me.  One question (maybe I'm just missing some of the 
code).  Why do you tear down the tooltip's text element and recreate it each 
time?  Can't you just set the <text> element's value without having to destroy 
and recreate it?

This might be a useful resource for designing the menu organization specifics:
http://fantasai.tripod.com/qref/Appendix/LinkTypes/

"ltdef.html" is a list of definitions quoted directly from the sources; makes it 
easier to look things up. "alphindex.html" is an alphabetical index for it.
Has this been checked in? (with the UI freeze and all?) Look at the number of 
votes for this bug...
I solicited review from ben and hewitt, but I'm still waiting.
Let's vote ;-) 19->20
Is the question concerning the tooltips' text David Hyatt asked solved?
This looks like a completely new feature, and the feature cutoff deadline is
long past.  Marking nsbeta3-.
Whiteboard: PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt → [feature][nsbeta3-]PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
That's pretty cute.  Ignore the bug report for 20 months, ignore the existant
patch for two months, let review for the latest patch slide past the feature
deadline, then claim that the deadline is gone.

This is the only thing I hate about working on Mozilla: Netscape management.

Meanwhile hewitt, nbhatla, and company have a blank check nsbeta3+ approval to
completely overhaul (read: destroy) the modern skin, right before and continuing
through the "feature freeze".  Very nice.

Get back to me when the Open Source product and the bad management product are
on two different branches.

Its also required for Netscape's stated goal of HTML 4.0 compliance.
No scratch that, its required for HTML 2.0 compliance. Sheesh!

Sad. Very sad.

Sorry, but this isn't Netscape's fault this time.  This branch has been a long 
time coming.  As the patch was created by a Mozilla contributor, it didn't have 
to be nsbeta3+ to get it checked in.  Had you finished it and checked it in 
before today, it would be in Netscape 6.

And, for what it's worth, the blank check theme bugs have been minused or 
marked fixed today.

On a brighter note, per your request Jeffrey, it's time to get back to you -- 
as of today, Mozilla and Netscape 6.0 are in separate branches, and will 
continue to be until Netscape 6 rtm.
That's BS.  Even as a m.o contributor I still need review and approval for the
checkin, otherwise the process would go all to hell.  I didn't get review from
anybody, so I couldn't exacly just check it in.

There is an inherent conflict between the open source side of this project and
the AOL side.  The open source people are going to want to ship it when it meets
its stated goals.  The AOL people want to ship it by date X.  Luckily now that
it is branched we can perhaps both get what we want.

That is, *if* I can get a module owner to review the damn thing.
[Last comment before this moves to other communication methods...]

It is not BS.  Hyatt said the patch looked good on 9/15 (meaning you were 
probably inches from an r=hyatt) and just asked a simple question.  You never 
answered it, so there went that potential reviewer.  All you had to do to get 
approval was email brendan or waterson (the checkin rules have changed slightly 
now); both of them are very good about email, and respond quickly.

There is no conflict between AOL and Mozilla.  The whole purpose of the branch 
is so that Netscape can go off and pursue its goal for a stable build to ship 
soon, and Mozilla can continue on the long, winding road to 1.0.  You can still 
check this patch into the Mozilla branch.
So hopes of an HTML 2 compliant Netscape 6 are shot all to heck because of 2 
days and a missed email?

Great.  Wonderful.  I'm thrilled.  *sigh*
Additionally, there are only 14 bugs with 23 votes (which this bug currently 
has) or more.  Of these, 3 seem to be basic compliance issues: this one, bug 
22529 (25 votes), and bug 33032 (32 votes).  Of those three, this is the only 
one that has had a working patch ready to go for over a month.

Excluding a perfectly good patch because an arbitrary deadline was missed on 
account of one email seems awfully small-minded to me.  People want this 
feature.  The specs demand this feature.  It's sitting here on a silver platter. 
 Get it in!
I have to agree with hyatt that recreating the content nodes for the tooltip 
every time seems a bit strange.  If they're already there, why not just reuse 
them?  It's faster, and it doesn't rely on JS garbage collection to get rid of 
all the elements you're creating (and in the future things could change so that 
such elements don't go away until the document does -- see my proposal in bug 
52732).

If you want to be completely paranoid, you could change that bit of code to 
something like the following totally untested code written in the bugzilla bug 
entry form...:

function linktagToolTip(ttnode) {
  if (ttnode.getAttribute("class").indexOf(LINKTAG_BTN_CLASS) == -1) return 
false;
  var tt = document.getElementById('linktagtooltip');
  var ttbox;
  var txt; 
  if (tt.childNodes.length != 1 || tt.firstChild.tagName != "box") {
    while ( tt.childNodes.length > 0 )
      tt.removeChild( tt.firstChild );
  }
  if (tt.firstChild) {
    ttbox = tt.firstChild;
  } else {
    ttbox = document.createElement("box");
  }
  ttbox.setAttribute("orient", "horizontal");
  if (ttbox.childNodes.length != 1 || ttbox.firstChild.tagName != "text") {
    while ( ttbox.childNodes.length > 0 )
      ttbox.removeChild( ttbox.firstChild );
  }
  if (ttbox.firstChild) {
    txt = ttbox.firstChild;
  } else {
    txt = document.createElement("text");
    ttbox.appendChild(txt);
  }
  txt.setAttribute("value", linktagGetLocalTitle(ttnode.link, 
ttnode.getAttribute("data"), false, false));
  if (!tt.firstChild)
    tt.appendChild(ttbox);
  return (true);
}

But if these are the only things the tooltip is used for, couldn't you just put 
them in the XUL and do a GetElementById for the innermost one, and just change 
that?

The tooltip creation code can probably be replaced -- not sure why that was 
there.  Although I seem to remember some problem I had where the tooltip 
wouldn't resize correctly if I just set its text property, but that might have 
been fixed.
So are we going to try to land this on the trunk for Mozilla0.9?

Taking QA per managerial policy.
QA Contact: claudius → py8ieh=bugzilla
I agree with jce2@po.cwru.edu - let's do something here.  What needs to happen, 
and who needs to do it?  How can we bring it to the attention of that person?  
Let's get it in so it can be in the next Milestone builds.

FWIW this is now in the top 7 bugs.
Keywords: mozilla0.9.1
According to http://www.mozilla.org/roadmap.html, what needs to happen first is
that the bug owner submit the patch to reviewers@mozilla.org. I'm not clear on
what happens next or whether the patch on this bug is in a state that's ready to
be submitted...

I could be misunderstanding the roadmap, of course. Anyone have any other ideas
on what is necessary to get this into the trunk (and by extension, into M18?).
Well, the first problem is that whoever wrote the patch is now (apparently) very
pissed off and isn't responding to any of the bug replies.

Jeffrey, are you willing to submit your patch for super-review?

Second of all, Ben Goodger supposedly had problems with the patch (9/14/00), but
he hasn't commented on his problems in this bug. Ben, if you're listening, could
you please add your comments to this bug?

First we need peer reviews. We've had some of those, and I think that some of the 
suggestions need to be incorporated. This is actual work that needs doing.

Then we need a module owner review:
http://www.mozilla.org/hacking/reviewers.html

Doesn't make it clear who would own this as its both XUL, CSS and "Skins" in some 
sense. i.e. its general UI.

However Hyatt says its Ben Goodger, and I concur.

We also need a super review. That would probably be Ben G again, so no doubt we 
can collapse the two into one.

So - we need someone who's Javascript is good enough to handle this to take 
onboard the tooltip adjustments, then when that is done we need to get some og 
BenG's valuable time. 

If Jeffrey's too busy, any other volunteers?

Okay kids I'm working on this bug again and I intend to get it on the tip.  I
have to update the patch again because of torrential committing in the modern
skin, and then take a good look at the javascript that runs this thing.
Apologies for the delays in my commentary. I applied a version of this patch on 
my W2K machine about two weeks ago and found the following problems (some are 
serious, some are nitpicks):

- it did not work 'out of the box' (and I was unable to get it to work)
  (I applied the patch, loaded one of Hixie's tests, the toolbar dropped down
   but contained nothing)
- the code was difficult to follow. 
  (Few comments and no high level overview as to how the feature works, 
   numerous global variables that were mostly indistinguishable, convention is
   to label global variables with 'gVarName' - I know a lot of the existing
   code doesn't do this, but we should be fixing that ;) 
- there were js warnings
- UI issues 
  (the toolbar should appear directly above the content area since it relates
   directly to the webpage, not between the navbar and the personal toolbar.
   the toolbar should also be disabled by default. Starting the browser for
   the first time, the toolbar appeared, blank, and after my homepage 
   (mozilla.org) finished loading, the toolbar went away. This is broken. It
   should be /shown/ when a page with link is loaded.) 

I await a newer version of the patch that addresses these issues. This is a 
great feature. Keep up the good work!

Thanks,

Ben
adding Don Melton to the CC list as he is the module owner for Navigator. 
Thanks for the comments, Ben.  The original patch was put together to try to get
it in before the 2000-09-15 UI freeze.  Since we no longer have pressing time
constraints, I am going to pretty well rip out Tim's javascript (sorry) and
replace it with something readable and in the accepted style.  The attached
patch won't currently work because of skin and event changes since it was
submitted.
I have attached my latest version of the LINK UI to this bug.  Changes since the
last version:

1) Patch applies cleanly to 2000-10-16 trunk
2) Updated to understand jar packaging
3) Cleaned up linktag.js, while reducing its size by %15 and removing warnings
4) Merged the "Top" widget into the "Up" widget
5) Made all widgets menu-capable
6) Moved to standard tooltip handling (no more tearing down the tooltip box)
7) Made the View->Toolbars->Link Toolbar preference sticky
8) Made sure that the toolbar doesn't appear and disappear at startup

Issues which still remain:

1) The menubutton arrows point the wrong direction.  This is really a problem
with the menubutton XUL widget itself
2) I don't know if the build works on windows.  I updated jar.mn, MANIFEST, and
makefile.win, but I don't have a windows box + compiler to test it with.
3) I think I might want to move strings from linktag.properties to a DTD
somewhere.

So, please apply this patch to your tree and report the results.  On windows,
please contribute and build system hackery which I have overlooked.
Target Milestone: M18 → mozilla1.0
I forget to mention that the actual loading of the URLs is wanky.  First, we are
using appCore and we should transition to using the proper XPConnect stuff, but
I don't know what that is.  Second, loading mailto: URLs doesn't work properly.
Jeffrey: FYI, there were some specs written for this a few months back, 
which are mentioned in the above comments... Just want to make sure you've
read them to see if there is anything interesting in them:
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
   http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt
Yes I've read those fine documents.  We're baby-stepping to that goal. 
Currently we do everything in that spec except distinguish between rel and rev
links, and paint a useful status line.

Is there a canonical way to make a menu item change the status line, or should I
simply use an event listener to set the status manually?
Jeffrey: Excellent!

Ben: Do we still have to do status bar stuff manually? I know it used to be that
way, but I was kinda hoping some attribute would be added at some point...
I'll try this out tonight. 
Ian, yes, currently (unfortunately). Convention on windows is to display a 
statusbar message when navigating around in menus. We do not support this 
automatically at present, and as a result we do not do it at all. 


I'm still seeing results similar to what Ben saw in his earlier comment: the
toolbar drops down appropriately at Ian's link pages, but there's nothing on it.
 Any ideas?
Blake: when you say that there is nothing on the toolbar, are you saying that
there is absolutely nothing there, or that all the buttons are disabled?  Also
please tell us what platform you tested on.

I installed VMWare so I can test on Windows, but I fear it may take quit a while
to compile mozilla inside windows inside a virtual machine :(
There's absolutely nothing there.  Just a toolbar and a grippy.  win98, new 
trunk build.
Okay I know what the problem is.  linktag.properties was left out of the build
process, and that's where all the strings live.  The buttons are probably
*there*, but I bet they are only a few pixels wide and you can't see them.  I
plan to merge linktag.properties into navigator.dtd in the next revision.  In
the meantime please apply this patch in
mozilla/xpfe/browser/resources/locale/en-US/ and rebuild xpfe:

Index: makefile.win
===================================================================
RCS file: /cvsroot/mozilla/xpfe/browser/resources/locale/en-US/makefile.win,v
retrieving revision 1.14
diff -u -r1.14 makefile.win
--- makefile.win	2000/09/15 06:59:30	1.14
+++ makefile.win	2000/10/18 03:50:20
@@ -33,6 +33,7 @@
 	.\NetSupportConfirmCheckYN.dtd \
 	.\navigator.properties \
 	.\askViewZoom.dtd \
+	.\linktag.properties \
 	$(NULL)
 
 

Anything happening here? Will this get fixed/checked in for 0.9.1?
OK, with jwb's latest change, this works.  But it breaks many things for me, 
like mousewheel scrolling and typing in textfields (!), because the toolbar 
appears to take focus.  Try some -moz-user-focus rules.

And people argued when this got minused for rtm...?
Here are some problems I spot at a glance:

* The toolbar doesn't dropdown/work at http://www.bath.ac.uk/%
7Epy8ieh/internet/eviltests/link1.html, but it does at http://www.bath.ac.uk/%
7Epy8ieh/internet/eviltests/link2.html -- is it supposed to work at the former?

* The toolbar buttons should look be in the normal state again if you mousedown 
and then drag the mouse away (e.g. they should only be pressed 
in :hover:active, not just :active)

* You can check and uncheck Link Toolbar in View > Toolbars, but if you're not 
on a page that it can be used on, that won't do anything.

* The toolbar seems to steal focus, so key and mousewheel events to webpages 
are broken (!)  Toolbar buttons should never take focus.

* You get the standard page context menu when right-clicking on the toolbar.

* If you go to View > Toolbars > Link Toolbar even when the toolbar is shown, 
checking and unchecking the item does nothing (except print "toggling toolbar 
LinkTagToolbar" in the console, which probably isn't necessary once we have all 
the kinks in this patch worked out)

* `Link Toolbar' should have an access key in the menu

* You're able to drop links on the link toolbar, but not on normal chrome 
toolbars.  (Good luck with this one :-)

* Whatever happened to the original design, which had this toolbar more like a 
toolbar and less like an integrated part of the page?  I agree that, since this 
is page navigation, it should probably be visually related to the page (then 
again so is Back/Forward and those are on toolbars), but using standard 
toolbars has benefits (like easily providing grippies, and fixing the link-drag 
ability and context menu popup, along with the focus).  And if you use the 
standard toolbars, it'll pick up the same color as the rest of the chrome (and 
the system) in at least some skins (e.g. Classic).

More comments later, I haven't even looked at the code yet.
The Linktag toolbar is just a regular <toolbar chromeclass="toolbar">, the very
same as the personal toolbar.  If it has all sorts of odd behavior, then bugs
need to be filed against XP Toolkit/Widgets.  I think I did a pretty damn good
job, given that the XUL reference for toolbars hasn't been updated in over 6
months, and is incomplete and wrong.

I don't have any of the problems you have when I use the Linux build.  The menu
works fine, turning the bar on and off as expected.  Of course, it doesn't make
the bar appear on a page with no links.  That's the design intent.  I don't have
any event binding problems with the toolbar.  I don't get any context menu when
I right-click on it.

Is there really this giant divide between unix and windows XPT/W?  Are you sure
that patch applied without any rejections?
Blake, addressing all of your comments, as tested on Linux debug build pulled
2000-11-01-22

* The toolbar work fine for me at Hixie's link1 and link2 pages.

* If you poke the button and then drag off the toolbar, the button returns to
normal state

* By design

* Key events and mousewheel both work fine

* I get no context menu on the link toolbar

* The menu entry for the Link Toolbar toggles the toolbar, as expected

* Will fix

* The toolbar does not respond to drag & drop, as expected.

* This is the original design, mostly.

Since our observations are so different, I can only assume that my patch doesn't
work properly in the Windows build environment.  Most likely, one or more files
is missing from your jars.
Jeffrey Baker sez:
> The menu works fine, turning the bar on and off as expected.  Of 
> course, it doesn't make the bar appear on a page with no links.  That's 
> the design intent.
Does this mean there's no way for developers to make the LINK bar always on?  I 
was really hoping that this pref would be a 3-way.  (See discussion circa Aug 
28.)  How much extra work would that be?
Considering that this three-way preference
(always-on/always-off/on-only-when-relevant) behavior is almost certainly
confusing for new users *anyway*, how about the following as a behavior to
minimize confusion:

When View->Toolbars->Link Toolbar is selected:
  IF page has links:
    IF toolbar is visible (ie pref is always-on OR on-when-relevant):
      Change pref to always-off.
    ELSE (toolbar is not visible; pref is always-off):
      Change pref to on-when-relevant.
    END IF
  ELSE (page has no links):
    IF toolbar is visible (pref is always-on):
      Change pref to on-when-relevant.
    ELSE (toolbar is invisible; pref is always-off or on-when-relevant)
      Change pref to always-on.
    END IF
  END IF

(I think there should be something in a preferences panel that makes these three
choices explicit, though, otherwise it's confusing).

The benefits of this scheme are:
- Selecting the View menu item always visibly toggles the presence of the toolbar.
- If the user has the toolbar on without realizing what it does, sees the
buttons are always disabled, thinks it's useless, and toggles it off, it will
still reappear when it actually *becomes* useful.
- If the user then turns it off even though the buttons are now active, it will
stay off for good.
- The same "two-step process" can always be used to make the toolbar always
visible, even if it is originally turned on on a page that does have links.

I think that that if a "checkbox"-like menu item is really needed for this (and
it probably is, for consistency with the other toolbars), something like this
algorithm is the only way to make all possible choices available through that
menu (and of course, most users wouldn't think to look in Prefs for this,
especially since no other toolbars are in prefs).

Thoughts?

Stuart,

This makes a lot of sense to me. Actually, the only thought I have in order to
make this menu item as clear as possible, is to make a sub-menu:

View->Toolbars->Link Toolbar->Always on
                              Always off
                              On when relevant

Where the currently selected item has a check mark in front. This way you don't
even have to check the algorithm you mentioned.
I really think that making the same menu item do two different things, 
depending on what the current page happens to include, is asking for trouble.

The Link Bar is not a toolbar, it is content which is specified in the page. 
(E.g. in the unlikely event that two frames in a frameset have independent sets 
of LINKs, each frame should have its own Links Bar at the top of it.) Offering 
an explicit option to hide the Links Bar when LINKs are present, makes as much 
sense as offering an explicit option to hide A HREF links when *they* are 
present.
If Mr. Baker has truely quit mozilla development (per his comments in bug
40828), then we need to assign this bug to someone else to get traction.

Good idea.
Assignee: jwbaker → nobody
Status: ASSIGNED → NEW
I'll take it.
Assignee: nobody → blakeross
The functionality for this toolbar needs to also go in the "go" menu. I know not
many people use this menu, but it is the logical place to put Page navigation
functions. I don't know whether this has been discussed, but it could be easily
implemented as a section in the menu with the necessary choices. The choices
could be greyed out if not available. This would make it easy for those people
who don't want a toolbar (Always Off) to be able to still access those features.
> I know not many people use this menu

Then it should be removed.
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: mozilla1.0 → mozilla0.9
I use the "Go" menu all the time.  It's extremely useful for navigating the 
history more than one page at a time.  I also think this would be another good 
place for LINK nav to go in addition to the toolbar.
Priority: P2 → P3
Target Milestone: mozilla0.9 → mozilla1.0
Blocks: 62399
Just if someone is interested:
I dedicated a web page to the topic 'HTML LINK-element':
http://www.subotnik.net/html/link.html

It is written in German language, but beeing mainly a list of links to English
sites it might be usefull for you even if you don't understand my words.
Keywords: helpwanted, mozilla0.9.1, nsbeta3, patch, review
Whiteboard: [feature][nsbeta3-]PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt → PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
after reading comments from mpt & alecf in 23095 and remembering the ever-present 
competetion, I thought that this might be done like the IE5 Auction Assistant, 
sliding down over the content area, rather than a toolbar extending over the 
sidebar, which it is not relevant to.
Keywords: patch
Keywords: review
*** Bug 67850 has been marked as a duplicate of this bug. ***
From bug: 67850
In the HTML spec, I think, the link tag can provide help for a particular page 
by specifying a help page url through the href attribute
e.g. <link rel="help" href="help.htm" />

For various reasons, this could prove useful if implemented by the browser. 
Perhaps under help in the top menu bar, the option 'help for this page' could 
appear if this tag was present in the document head.

Would seem an easy enough thing to implement (sorry, middle of college stuff or 
I'd do it myself!).As far as I remember, there are a whole load of things that 
<link> can refer to (rel='contents' for a sitemap, rel='glossary', 
etc.).Seperate bug reports for those, I suppose, if this one seems sensible.But 
they seem like useful tags to support in some fashion.

Do we have a plan for this bug? We should get at least a bare-bones UI (even if
just a list in PageInfo) for .9 so we can make sure it works for 1.0 

should someone nominate for .9 so it gets on people's radar? (0.9.1 seems like
some people might miss it.) Also, nsbeta1 and top100 might be good bets.

And another thing, this is not an enhancement. This is a legitimate bug in
Mozilla's handling of HTML2.0. severity should be upped.

I wish I had the power to make these changes... Oh well...
Thanks.
I agree with moving it to 0.9 even if it's just for the purpose of getting it on
more peoples radar, top100 - no because I doubt it affects any top 100 site
(because we've got the situation that no top browser supports it so sites don't
bother), nsbeta1 - no because I don't consider myself in a position to tell
Netscape what to do, but upping severity as this is a HTML compliance issue.
Severity: enhancement → normal
Keywords: mozilla0.9
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: ian → zach
Target Milestone: mozilla1.0 → mozilla0.9
Target Milestone: mozilla0.9 → mozilla1.0
> (E.g. in the unlikely event that two frames in a frameset have independent
> sets of LINKs, each frame should have its own Links Bar at the top of it.) 

I think that's more trouble than it's worth.

One, it's not as usable as having a consistent UI in a standard place.  Two,
it's going to interact poorly with page authors that designed their framesets
and frame contents with specific dimensions in mind.  Three, framesets are being
phased out of (X)HTML.  Four, as you pointed out the occurance of multiple frame
contents with navigation LINKs is an edge case.

adding self to cc:, shoulda done it when I posted my comment, sorry for the spam
I have created an add-on toolbar that is in its first incarnation, it is posted at:
http://segment7.net/mozilla/linktoolbar/

I don't have much time to work on it, but at least it is a start.  Patches and
suggestions are appreciated.
Unfortunately, this is not something I have time to do in the near future.  
Does anyone who's been more active on this issue (Eric?) want to take this and 
shepherd it along?
Keywords: mozilla0.9, review → helpwanted
I'm attaching a .jar file containing Eric's toolbar with some of my revisions.
Still to do:
HTTP headers still don't work.
Needs a dtd for l10n.
Doesn't work with Modern theme.
Need to make "rel" value appear before title of "misc" links.
Whiteboard: PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt → [Hixie-P2] PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
Christopher Hoess: Are you actively working on this? Also, you said you were
going to attach a .jar, but didn't... 

Gerv
I suppose so, for low values of active.  One of my changes managed to break the
.jar just as I was about to post it, and I had to leave the computer for the
weekend...anyway, it's working now.

Eric: I've had a change of heart, I'm just going to throw the .jar up here-it
would look kinda weird posting a diff to a patch that isn't Bugzilla-available.
 I have some ideas on putting link-type + title in for "misc" links, but I'm not
sure when I'll have time to work on this again-I will definitely have some time
after the 11th, though.
Sigh...OK, Bugzilla keeps timing out whenever I try to upload an attachment, so
the .jar is now at <http://www.stwing.upenn.edu/~choess/linktoolbar.jar>.  If
anyone can get it attached to this bug, feel free to do so-and Eric, feel free
to roll it into your .xpi, too.
Reassigning to Eric, who's working on this way more actively than I am.
Assignee: blakeross → drbrain-bugzilla
Status: ASSIGNED → NEW
I have updated the Link Toolbar again: it's still at the previously posted link
(on my personal homepage), but I'll try to get it sent as an attachment ASAP
(I'm behind a proxy).  It now has a proper DTD for L10N, and
I've changed a little more of the parsing that assigns titles to the popup
menus.
Still to do: HTTP headers, goofs up chrome in modern theme.  I'm also looking
for suggestions here on condensing the buttons: of the various HTML4 defined
link types, only chapter, section, and subsection have been placed under "Misc".
 The toolbar is kind of wide (I'm sure it breaks on some people's screens), and
I'd like to know which ones people think I should condense.  (If I condense,
say, "appendix" and "glossary" into "misc" as well, then those links would
appear as "appendix: title of link", "glossary: title of link", etc. in the
popup.  Of course, the grouping of appendix, glossary, chapter, section, and
subsection might get a new button called "document" or something.)  Please let
me know of any suggestions for reducing the number of buttons in a user-friendly
way.

In the next round of improvements, I think I'll also test a (partial?) fix for
bug 57399, by simply adding all anchor elements to the array of links.  Once the
bugs with HTTP headers and modern breakage are worked out, I'll try to rearrange
the file packaging so this is an integral part of the browser chrome and not an
add-on.
> Please let me know of any suggestions for reducing the number
> of buttons in a user-friendly way.

Here's a process of elimination I think will help determine which link types
should have buttons.

First group the link types by utility:

  Home                                       # high utility
  Up
  Previous, Next
  First, Last
  Contents, Index, Glossary, Appendix
  Copyright, Chapter, Section, Subsection
  Help, Bookmark                             # low utility


Then decide which group to stop adding buttons for.  Everything below the bar
goes into "misc":

  Home                                       # high utility
  Up
  Previous, Next
  First, Last
  ----------------
  Contents, Index, Glossary, Appendix
  Copyright, Chapter, Section, Subsection
  Help, Bookmark                             # low utility

You can place the bar whereever you like.  I selected the placement above
because it represents a good compromise between utility and screen space.

In ranking utility, think about what navigation is commonly employed by websites
today or what navigation is recommended.  For instance:

Home is both a highly recommended and a commonly used navigation link.

Up is recommended, but not as common.  However, with increased appearances of
"breadcrumb trail" navigation, Up is becoming more common.

Next and Previous are common and probably recommended when appropriate.  If I
had to choose between them and Up, I would rather have Up.  A single Up button
has greater "utility density" than Next and Previous buttons.

I'm not a big fan of First and Last buttons, but I think people are accustomed
to having them when Next/Previous navigation is present.  However,  I wouldn't
complaining if they ended up in "misc".

The remainder are either uncommon, not recommended, or both.  Furthermore, were
Contents to have a button, so should Index, Glossary, and Appendix.  That alone
makes them belong in "misc".

Another way to think about it is to imagine that providing a button will spawn a
Web revolution with page authors adding LINK elements corresponding to the
available buttons.  Assuming that, which buttons would provide the most benefit
for most users.  Thinking this way I come up with the same results as above.
> First group the link types by utility:
> 
> Home                                       # high utility
> Up
> Previous, Next
> First, Last
> Contents, Index, Glossary, Appendix
> Copyright, Chapter, Section, Subsection
> Help, Bookmark                             # low utility

While agreeing with your methodology, I disagree with a bit of your your 
ordering. There are several important points.

How common a <LINK> is is not something which should affect its utility. If we 
decide it's less common and give it less prominent UI, then this will be a 
self-fulfilling prophecy.


I haven't seen the current Link Toolbar yet, and can't remember all the 
arguments about whether buttons should disappear (shorter toolbar) or get greyed 
out (muscle memory) when there are no links of that type. However, Help, for 
example, seems to me to be an ideal candidate for a disappearing button which is 
always on the right hand end of the line of buttons (right hand end of the 
toolbar for Mac).

What do Bookmark links do? If all they do is provide the URL that should be 
bookmarked for this resource, then they do not need links toolbar UI at all. 
Using them is the responsibility of the File Bookmark command.

I'll have a look at the current design and comment further :-)

Gerv
> What do Bookmark links do? 

They're internal bookmarks. See <URL: http://www.w3.org/ >. They're especially
useful for speech browsers (and Lynx), since you can skip directly to the part
of the page that interests you, bypassing navigation bars, TOCs &c.
> How common a <LINK> is is not something which should affect its utility.

I wasn't clear.  I wasn't referring to the commonality of LINK element links.  
was referring to the use of A element links.  For example, most sites have
markup like this somewhere on the page:

<a href="http://foo.com/">Home</a>

That's what I was referring to as a common occurance of a Home link.

Look at how authors are linking today.  Figure out what the most common
relationships they're making between documents.  Pretend that they've been using
LINK elements to do this.  Create an interface that helps users navigate the
most common and useful of these LINK elements.  Then hope that authors actually
/do/ start using LINK elements to specify the associations they've been making
all along.

Following that formula I just don't see how other associations are more
prevalent, useful, or important than Home, Up, and Next/Previous. Perhaps
Copyright is, but that can just prominent placement in the Misc or Other menu. 
Afterall, it might be prevalent, but most users have no need for the copyright
info (i.e. it has low utility).

I realize this is probably quite a bit more work.  But what I'd like to see is a
dynamically-sizing toolbar.  Put all the "standard" buttons on it, go ahead. 
Any nonstandard LINKs can go under "Misc".  If the user shrinks the viewport so
that the rightmost end of it is cut off, replace those buttons with entries at
the top of the "Misc" menu.  If you order the buttons from most useful (left) to
least useful (right) this would work great.

I'd second Gerv's suggestion that the "Help" button be anchored to the right end
of the bar, regardless how big the window is and what other buttons are showing.
 If a window is as small as possible, the two buttons I'd want to see are "Home"
and "Help".

The option to iconify the toolbar would be great.  I like to retain full
functionality while maximizing screen real estate.  I like iCab's toolbar.

I like the idea of button the LINK relationship in the "Misc" menu along with
its title.  Note that iCab uses ">" or "<" to indicate whether it's a REL or REV
relationship.  I don't know if we'd need to go that far.

Whatever order is decided for the buttons will become a self-fulfilling prophecy
for how authors will implement LINK in their pages.  ("Ditto Gerv.")  Therefore
it's very important that we pick the right ones.  Modifying tim@tool-man's list,
I'd suggest the following order.

Home, Help      # anchored to the left and right, respectively
Up
Previous, Next
First, Last
Author
Contents, Index, Glossary, Appendix
Chapter, Section, Subsection
Copyright
Bookmark
Non-standard-ones

The first four groups (aside from Help) comprise your basic "directional" nav. 
The others are more "conceptual" nav.  While copyright links are common, the
average user probably won't have much use for it.

If Mozilla gets the ability to customize it's toolbars, this would be one that
users might use that alot on.  Some users may read sequential articles often,
and want to use the First/Prev/Next/Last buttons the most.  Other users'
navigation style may be to always refer to the Home/Chapter/Section page and
start drilling down again.  Maybe a user likes to contact the authors of pages
he reads, and places the Author button prominently.
This is an RFE and MUCH lower in my list of priorities than just getting this
feature into mozilla's default installation in *any* form, but long-term, I'd
like to see this work in conjunction with bug 22056 so that the link-bar could
be used in icons-only mode. We'd need a set of icons that are somehow visually
distinguishable from the normal back/forward progression - perhaps "next" and
"previous" could borrow from the visual look of the "Next" button in mailnews,
for example.

But being able to use this toolbar in icons-only mode would allow a
significantly larger number of links to appear on it without filling the width
of the screen...
> [...] so that the link-bar could
> be used in icons-only mode. We'd need a set of icons that are somehow visually
> distinguishable from the normal back/forward progression [...]

And it would be nice if the User would be able to set his own icons for the
link-bar, independent of the current Theme.
OK, here's my current thinking:

Seven buttons.
1) |< Start
This is what people have been referring to as the "Home" button.  (One of the 
specs/draft specs at fantasai's page reserves the "home" keyword.)  Recognizes 
keywords start, begin, top, origin, and first.
2) < Prev
Recognizes keywords prev and previous.
3) ^ Up
Recognizes keywords parent and up.
4) > Next
Recognizes keywords next and child.
5) [icon of page with writing on it, arrows coming from each side] Document
Catch-all for conceptual links about this document.  Recognizes (in order): 
search, help, navigator, contents|toc, index, glossary, bibliography, chapter, 
section, subsection, appendix, copyright, disclaimer, trademark, footnote, 
biblioentry.  Labels each of them in an appropriate manner.
6) [perhaps a pencil, or a "stick figure"?] Author
Recognizes keywords author, made, editor, and publisher.  Labels them 
appropriately.
7) Other
Alternates with no other rel keyword or an unrecognized rel keyword, properly 
labeled.  Links with unrecognized rel attribute, labeled with the value of the 
attribute and their title.

Tim (L.), I think you have some interesting ideas here but I'm a bit wary of some 
of them.  I'm not sure "Help" is worth having its own button, because I think 
very few sites have a resource appropriate to be linked in with rel="help".  
However, in my proposal, "Search", "Help", and "Navigator" (navigational aids) 
will always be at the top of the "Document" menu if they exist, so they'll still 
be relatively easy to find.

There seems to be considerable enthusiasm about an all-iconic, iCab type toolbar.  
Personally, I'm kind of cool to the idea (the iCab toolbar screams "mystery meat" 
to me), but it seems reasonable, once but 22056 is fixed.  If someone in the 
viewing audience would like to supply icons as described above, it would be Much 
Appreciated; my drawing abilities aren't up to it.

The "dynamic toolbar" is cool, and I think implementable, but again I'd want to 
run it past mpt; I'm worried about the usability consequences.

I also want to add two menu items to the "Go" menu, as in Hixie's proposal, to 
store the "rel" and "rev" values.  (The toolbar doesn't do "rev" right now, 
although I will probably have to ad-hack in support for rev="made", since I 
understand that's used by other browsers to indicated authorship.)

Christopher,
You're right, we should be calling it "Start" instead.  "Home" is reserved.

I definitely think "Help" is worth a button of its own.  My personal site has
virtually no content (though I have big plans!) but already two help pages: one
for help using the site ("Hi, I use valid HTML/CSS and LINK tags to enhance your
user experience.  Get a browser that supports this.") and an "about" page
describing the purpose of the site ("Hi, this site is for Stuff I Like[tm] but
all I have now is a resume.")  If I only had two additional navigational aids
available, they'd be "Start" to get back to a fixed location from which I can
(theoretically) get anywhere else, and "Help" to give me some pointers for when
I am totally confused and don't even know where I'm trying to go.  "Help" would
be especially useful for web applications.  This would reduce the need for
hyperlinks spawning JavaScript popup windows (and whatever else), which I see
more of all the time.  Just click the page's "Help".  Implement the standard
HTML, and you reduce the need for scripting and improve the accessibility.

OK, I didn't know 22056 existed.  That part is a RFE that can wait.

I don't know how the "dynamic toolbar" as I described it would be a usability
problem.  I think _not_ having something like this would be a usability problem.
 If you can't access the buttons because your window is too narrow, how do you
use these features?  Maybe you slide them into the "Misc" menu, maybe you put
all LINKs in the "Go" menu for redundant secondary access.  Sliding them into
the "Misc" menu keeps them in the toolbar, which I like.

I forgot all about "Search" and "Alternate".  They should exist too, in the same
group as "Contents, Index, Glossary, Appendix" in my last post.  I like your
idea of putting the more "conceptual" LINKs under a "Document" menu.  This might
be less cluttered than throwing all LINKs into a "Misc" menu.  A couple basic
"directional" buttons, document (most other standard types) stuff, author, help,
and misc (non-standard types) stuff.  This is a total of about 8 buttons, your
list plus "Help".  Not bad.  Better than the ~20 my list is up to now!  With 20
standard LINKs, maybe your idea is better than the "dynamic toolbar" from a
usability perspective - a small set of button-menus with logically grouped LINKs.
Latest changes:  <URL:http://www.stwing.upenn.edu/~choess/linktoolbar.jar> has
been updated again.  (If someone would like to attach this to the bug [I'm
behind a proxy], please feel free to do so.)  The toolbar now has Start, Prev,
Up, Next, Document, Author, Other, and Help buttons, implemented as described in
my last comment with the exception that the Document menu isn't sorted yet.  (I
should be able to do this relatively trivially, but I'm getting tired of hacking
this; I'll throw that in with the next set of changes.)  The document menus also
recognizes "sibling", "child", "next", "end," and "last".  Various
non-human-readable link types are filtered out.  Adding links to the "Go" menu
will occur when I repackage this for inclusion in the mainstream chrome.

For those in the viewing audience who want to know how to install, just pop the
.jar into your chrome directory.

On to HTTP headers!
> Latest changes:  <URL:http://www.stwing.upenn.edu/~choess/linktoolbar.jar>
> has been updated again.

I downloaded and installed that JAR, but it doesn't contain the changes you
described.  HTTP HEAD shows that linktoolbar.jar was updated Wed, 20 Jun, but a
diff shows it identical to the linktoolbar.jar I grabbed on Tue, Jun 19.

FYI, I've been modifying linkToolbarOverlay.xul and linkToolbarOverlay.js
myself.  Not sure what I'll do with it when I'm done, since I've already broken
several "hacker" rules by changing the line terminator, indentation, and braces.
 I'm currently doing some refactorings to "Replace Switch with Polymorphism" and
"Replace Conditional with Polymorphism" since I'm an OO-head.  I guess I could
just release it as a competing JAR...

Has adding the stylesheet selector been talked about and discarded? (Bug 6782
deals with this.) I think that putting it with the rest of the <LINK> tags would
be a good idea. I actually want a full menu thing in the toolbar, but that's not
going to happen.
There is already an alternate stylesheet UI, under the View menu.
Tim T.: it should be good now.  I uploaded the new jar to my home directory
rather than my web page by mistake.  I'm afraid your hacking may be for naught,
as I've gutted a lot of the parsing code and replaced it.  It's pretty ugly code
right now, but I'll clean it up as I keep working.

Peter: I was planning to leave the stylesheet selector in the menus; you don't
really browse to a stylesheet like these other links, you load it.

Tim L.: My UI concerns WRT the dynamic toolbar were because I know one of mpt's
pet peeves is UI where items appear and disappear.  It may confuse users when
they resize their screen and some buttons disappear.  I think with the current
scheme, that's less of a problem, anyway.

One other thing I thought of, once this bug gets done, is to file a bug against
Evangelism to promote it.  I.e., see if they can arrange some
developer.netscape.com articles or material elsewhere so people know how and why
to use <link>.
Christopher: OK, I completely understand the concern of UI element disappearing 
or moving without reason.  But if you shrink your window enough that the 
buttons fall off the right hand side, they "disappear" anyway.  Putting those 
options in a menu keeps them accessible, at least.  

But I'm starting to believe that the 20 (or so) LINK types we'd want accessible 
is just far too many to fit individually on a toolbar.  We should probably make 
the couple most useful individual buttons, and group the rest as logically as 
possible in menus, as you suggested.

In addition to displaying the rel type and title in the menus, the lang 
attribute would also be useful for rel=alternate.  Maybe instead of 
saying "Alternate: TheTitle (Spanish)" it could say "Spanish: TheTitle".

The evangelism idea is great.  There are several resources already online, like 
Tekelenberg's.  I'd bet he'd add Mozilla screenshots when this is ready.
I've added Christopher's latest linktoolbar.jar as an attachment.  To try it
out, download the attachment to <your-mozilla-dir>/chrome/linktoolbar.jar.  Be
sure to specify the filename or you'll end up with a file named
"showattachment.cgi".
Shouldn't this work on MacOS (9.1 D and Build ID: 2001061308) as well?

I tried with each 'chrome' directory sherlock finds on my disks, even created a
new user to get fresh prefs and put it in this user's chrome directory. No extra
toolbar arises :-(

BTW which _should_ be the right directory? There is at least one active chrome
in the programm's folder and in the documents folder:

Mac-HD:Mozilla:Profiles:Michi 3:wozyjwbl.slt:US:chrome:linktoolbar.jar
Mac-HD:Internet:Internet Programme:Mozilla:Mozilla Folder:chrome:linktoolbar.jar
Wow, you people have been busy, I'm merging the changes of Christopher Hoess'
version into my own that has a few UI functionality improvements.

Just to weigh in here I am returning the "contents" and "index" links.  I feel
it is very important to have a direct link back to both the contents and the
index of the current document you are in for quick lookup of information.  In a
reference book I find myself often switching between the content of the book and
the index when searching for information, especially when there is no useful
search feature (W3C specs for example...)

This really is turning into a UI debate that should be carried out in the
newsgroups, we should probably move it there.  Our primary focus here is to get
a working, commitable toolbar, not to debate about what links should and should
not be on it.  Lets get this bug fixed _/*THEN*/_ file bugs against it to get
the set of links we want on it.
Eric: I'm afraid I've created some more changes to sort the "document" and
"author" menu and implement Tim L.'s suggestion for alternate/translation. 
Sorry to spring this on you, but I was halfway through the fix when I saw your
update.

I agree that the discussion of exactly which buttons we should have should go to
the newsgroups: if someone sees mpt on IRC, could they solicit his opinion as well?

Do "UI functionality improvements" include "fixing that hidous breakage w/
Modern"?  I don't know enough about XUL to know how to fix that.  Also, was the
HTTP header code ever hooked up?  I've had some trouble figuring that out... 
(just wait till we get to Evil Link Tests 5 & 6).

The DTD for L10N isn't actually working right now, you have to put the DTD in
en-US.jar, so I figured I'd leave localization to the final packaging.

Glad to have you back, Eric.
I attached two versions of the GNU make manual.  The first attachment is the
same as the manual published on GNU's website:

<http://www.gnu.org/manual/make/html_mono/make.html>

The second attachment is a modification to add REL attributes to the anchors in
the Table of Contents.  There are 4 link elements and 131 anchor elements with
REL attributes, mostly divided into Chapter, Section, and Subsection.  I used
both versions to test performance on documents with thousands of links and also
as a sanity check for the various linktoolbar UIs.

Lastly, I've attached my own rendition of a Link Toolbar along with a screenshot
for people who don't want to install the chrome.  Here's a rundown of the
changes off the top of my head:

* rewrote most everything to use OO code that can easily accomodate
rearrangements of the toolbar, including changing items between buttons,
menubuttons, menus, or menuitems.

* UI improvements.  Borrowed XUL and CSS from the Personal Toolbar, reused icons
from existing chrome.

* removed code that wasn't used (yet), like the HTTP header parsing.

* lazy initialization of the language dictionary.  Not created until an HREFLANG
attribute turns up on a link element.

* added profiling code for time consuming methods.


Things that need improvement:

* The button icons I found are an improvement, but not good enough.  It
shouldn't use the Home or Bookmarks icons.  All icons should have variants for
hover, active, and especially disabled.  It's difficult to tell when a button is
disabled if its icon doesn't change.

* It takes 2.2 and 1.6 seconds on a 750 MHz Athlon to process the GNU make
manual with and without REL attributes respectively.  During that time the
browser is completely unresponsive.  Ideally, the code to handle links would run
in a seperate thread.  I have no idea if this is possible with just XUL and
JavaScript.

* The toolbar doesn't even start to get built until after the page has loaded
completely.  On a slow connection it'd be faster to navigate by links in the
page instead of waiting for the toolbar to populate.  Ideally the toolbar would
update incrementally as the document is loaded.  No idea of the feasability of this.

* Removal of some kludged CSS selectors to get the styling to work.  Need better
XUL-fu to do it right.

* Of course, support for LINK HTTP Headers :)

* automatically initialize the JavaScript link handling objects from the XUL. 
Currently you have to mirror changes to the XUL in the JavaScript code.  It's
only in one place, but it would be nice if you could just change the XUL for
things like:

    + move something into or out of the More menu
    + change a button to a menubutton or vice-versa
    + change a menu to a menuitem or vice-versa

and just have it work.  Time spent building the menu handling objects is small
compared to handling a document with lots of links.  A little more automation
probably won't impact performance noticeably.
Tim T.: Wow, what a change!  I think you can fix the auto-generation from XUL 
problem by doing a document.getElementsByAttribute("class", "button-toolbar 
bookmark-item") to create a nodeList.  Loop through the nodeList, trim the 
preceding "link-" from the id of each element, and that value can 
replace "top", "up", "first", etc.
[...]
> doing a document.getElementsByAttribute("class", "button-toolbar
> bookmark-item") to create a nodeList.  Loop through the
> nodeList, trim the preceding "link-" from the id of each element,
> and that value can replace "top", "up", "first", etc.

Excellent!  Oh how I wish that function existed in the DOM, then this would work:

  function getChapterLinks() {
      return window._content.document.getElementsByAttribute(
              "REL", "Chapter");
  }

FYI, I'm going to be away from my computer all weekend, so you won't be seeing
any activity from me on this bug until Sunday or Monday.  First on my list is
making disabled variants of the icons and getting tooltips to work.  Also adding
code to disable the More menubutton when all its children are also disabled. 
That way an enabled More menu is an indicator that links are available.  I'm not
sure of the usability implications of disabling a top-level menubutton.  Right
now you have to open the menu just to determine if links are present.  That's
gotta be poor usability as well.

Ok, I've incorporated all of Tim's changes into the link toolbar package (
http://segment7.net/mozilla/linktoolbar/index.html ).  This URL will work for
those of you who have never installed the link toolbar before.

I've updated the logic for anchors which have no title.  It now grabs all the
#text nodes in side the anchor and sets it as the label, see
http://www.w3.org/TR/1999/REC-html401-19991224/ for an example (chapters menuitem)

I've also attempted to get localization to work but I've had no luck.  If
somebody wants to take a crack at it go ahead, I'll try again when people are awake.

You can turn the toolbar on and off via the View | Toolbars menu.
Status: NEW → ASSIGNED
OK, here we go:

1st point: the toolbar should not be visible unless page has <LINK> elements. 
I would guess that there is no way you are going to get this UI into Mozilla, 
using up valuable vertical screen space, unless it's only visible when it's 
necessary :-)

The underlining on the menu is wrong in Classic - it goes all the way to the 
right. 
The look and feel of this menu should be as close to the Personal 
Toolbar's Bookmarks menu as possible. 
We shouldn't be using the Home icon for Top - it's conceptually wrong. 
I think you want double-headed arrows for First, Last and Top and single headed 
for Up, Previous and Next. I think this is a common VCR-like idiom.

Disabling:
The icons should have greyed-out versions. 
Those toolbar items which are greyed out should not underline on mouseover.
"More" should be greyed out if it's empty.

The arrows on Next and last should be to right of text, and you should have a 
vertical bar in the centre, like on the Personal Toolbar to the right of Home. 
Rough ASCII art:

H Top ^ Up | <- First < Previous | Next > Last -> | X More (X Bookmarks ? Help)

There needs to be at least one pixel less spacing between the icon and its text 
than between adjacent buttons. Otherwise associating an icon with its text is 
hard, because the buttons do not have raised edges.

"More" menu:
Things which are not present should be hidden, not greyed out.
Remember to hide the separator if you hide all the items in a section.
You should, in general, avoid separators with single items in each division.
"Appendices", "Glossaries", "Indices" should all change to the singular 
(Appendix, etc.) and become standard menu items (rather than cascading 
sub-menus) if the sub menu has a single item. 
Similarly, if the Miscellaneous Menu has only one or two items, they should move 
to the main menu. That might be a bit harder.

"Help" should disappear (see below) and the Authors/Copyright section should 
move to the bottom.
I don't know what "Alternates" is - do you mean translations and stuff? If so, 
how about "Other Versions"?
SubSections should be Subsections. There are no StudlyCaps in English ;-)

What about hotkeys? It would be cool to do Ctrl-Alt-Left Arrow to move to the 
next logical page. Is that part of this bug?

I realise that we have to cater for those on 640x480 but I have a 1024x768 
screen and there's a lot of wasted grey screen space. The default Personal 
Toolbar is almost twice as wide. Can we not have this current layout for small 
and a different layout for larger screens? 

As discussed before, a Help button which appears if there's help, at the right 
hand end, would be good. Also a Bookmarks menu like the Personal Toolbar one, 
called "Page Bookmarks" for rel="bookmark". 

Are there any W3C guidelines on how Chapter and Section rel links are to be 
used? For example, in the testcase, you get a Chapter link and then Section 
links inside it. It would be good to reflect this in the UI - as in, the Chapter 
menu had submenus for each chapter listing the Sections (top element being 
"Beginning of Chapter") and the Sections were submenus for subsections (if they 
existed), top element being "Beginning of Section". See what I mean?

...
Chapters -> Chapter 1 -> Beginning of Chapter
...                      --------------------
                         Section A
                         Section B
                         ...
            Chapter 2 -> Beginning of Chapter
                         --------------------
                         Section Q         -> Beginning of Section
                                              --------------------
                                              Subsection Q.A
                                              Subsection Q.B

That'll do to be going on with :-)

Gerv
> "More" menu:
> Things which are not present should be hidden, not greyed out.

I *think* I disagree. I like that all items are visible. This is the way menus 
work in the rest of Mozilla (and other applications). (Though I realize this 
isn't a very good argument. :) )

Some comments:

If 'title's are available for a link, they should be displayed as a tooltip.

Unknown link types should IMNSHO not be recognized. See Antti Näyhä's comments 
from 2000-07-0 for an explanation why. I have this problem at my Web site, e.g. 
<URL: http://www.gratis-kvalitetsdataspel.org/omtalar/blocks-plus.html 
>, 'schema.DC' and 'schema.AC' are displayed.

We need a new bug for this. It takes ages to load the page to see the latest 
comments. We can call it 'Better UI for HTML2 "LINK" element' or something like 
that. Or we can have a newsgroup discussion.
He's right. This bug is horrible. Resolving as dupe (to maintain dup chain) of 
new clean bug 87428. Eric - hope this isn't a problem for you :-)

Everyone - if this bug is bugging you, feel free to remove yourselves from the 
CC list of the new bug. Please do not add a comment when you do so, so that 
people can filter the spam. Thanks.

Gerv

*** This bug has been marked as a duplicate of 87428 ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 23 years ago
Resolution: --- → DUPLICATE
Gervase Markham wrote:
> 1st point: the toolbar should not be visible unless page has <LINK> elements.

There are several comments posted above on this topic.  Both sides
claim usability improvements.  At this point, it would take a usability study
to prove who is correct.  In lieu of such a study, working code trumps
comments :)

FYI, I agree with Tim Larson and favor the "always on" link toolbar.

> We shouldn't be using the Home icon for Top - it's conceptually wrong.
...
> The icons should have greyed-out versions.

Agreed.  All the icons need several improvements.  It would help out greatly
if someone would attach an archive containing improved icons.  Things to
include:

  * normal, hover, active (mouse button depressed), and disable icons for
    all buttons and the More menu
  * versions for Classic and Modern themes

Microsoft PowerPoint is the most common application I can think of that uses
first, previous, next, last style navigation.

> Those toolbar items which are greyed out should not underline on mouseover.

It works that way already.  At least, it should.

> The arrows on Next and last should be to right of text

Currently, the buttons are using the personal toolbar styles.  LINKs are
essentially predefined bookmarks, so it's appropriate to use the same
styling.  I'll check if the personal toolbar styles include a button with an
icon on the right and see how it works.

> "More" menu:
> Things which are not present should be hidden, not greyed out.

  Karl Ove Hufthammer wrote:
  > I *think* I disagree. I like that all items are visible. This is the
  > way menus work in the rest of Mozilla (and other applications).
  > (Though I realize this isn't a very good argument. :) )

Adaptive menus have poor usability.  Karl's argument /is/ a good argument.
UI consistency == good.

> "Appendices", "Glossaries", "Indices" should all change to the
> singular (Appendix, etc.) and become standard menu items (rather than
> cascading sub-menus) if the sub menu has a single item.

I considered doing this, but decided against it for the same reason that
adaptive menus are bad.

When UI elements move around or disappear the user gets confused.  It also
prevents the user from becoming habituated to the interface.  For instance,
they would have to perform a different gesture to get to the first chapter
depending on whether there was one or more than one chapter LINK.

This is the general argument against moving items into or out of the "More"
menu, or removing something instead of disabling it.

If your curious where these notions of consistency, adaptive menus == bad, and
habituation come from, do a search for "Jef Raskin".


> What about hotkeys? It would be cool to do Ctrl-Alt-Left Arrow to move to
> the next logical page. Is that part of this bug?

Good idea, create a bug for it :)

> I realise that we have to cater for those on 640x480 but I have a
> 1024x768 screen and there's a lot of wasted grey screen space. The
> default Personal Toolbar is almost twice as wide. Can we not have
> this current layout for small and a different layout for larger screens?

More != better.  Sometimes more is worse.  I tried putting Help on the toolbar
itself.  I didn't like it for several reasons, one of which was clutter.

My goal was to use up no more horizontal space than the top menubar (excluding
the Debug and QA menus).

The problem of power users with high resolution monitors would be solved if
Mozilla toolbars worked like Internet Explorer toolbars instead of Netscape 4.x
toolbars.  In other words, you could place two short toolbars side-by-side and
save vertical space.  Someone's probably already created a bug for that enhancement.


> As discussed before, a Help button which appears if there's help, at the
> right hand end, would be good.

Like I said, I tried it out because enough people wanted it.  Here's why I
decided against it:

0. clutter
1. no other menu, not even the top Help menu, works that way
2. putting Help on the toolbar will cause confusion between it and the
   top help menu.  I'm not convinced that putting it in a submenu is much
   better.  I'd rather call it something else, but nothing has come to mind

> Also a Bookmarks menu like the Personal
> Toolbar one, called "Page Bookmarks" for rel="bookmark".

0. clutter
1. "Page Bookmarks" is alot of horizontal real estate.  I debated between
   "Prev" instead of "Previous" to save space (I settled on avoiding
   abbreviations), but "Page Bookmarks" is too long.
2. Bookmarks is on the "low utility" end of the scale, hence its position
   deep inside the More menu

> Are there any W3C guidelines on how Chapter and Section rel links
> are to be used?

Not that I found.  However, I didn't look hard.  If someone turns up
something official please share.

> Chapters -> Chapter 1 -> Beginning of Chapter
>                          --------------------
>                          Section A
>                          Section B
>                          ...
[snip]

I agree that would be a better organization.  Unfortunately, there is
nothing in the HTML spec to indicate those relationships.  We could guess, but
we'd guess wrong alot of the time and display incorrect relationships. I
encourage someone to prove me wrong :)
Yeah, I realize it has moved to bug 87428, and I realize I'm supposed to discuss
in n.p.m.ui..  It annoys me each time people divert discussion to the
newsgroups, and, for what it's worth, I disagree with moving to a new bug, too.

I'd rather make progress than debate, so I'll be a good citizen and post to bug
87428 from now on.  But not without saying good-bye first.

    Twenty-eight hundred
    Taken from us in your prime
    Ian still loves you

Verifying, not the normal use for a duplicate but this page takes a while for to
load even over a cable connection so it'll be a pain for modem users.
Status: RESOLVED → VERIFIED
Blocks: 96683
No longer blocks: 96683
Blocks: 103053
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
Good news boys: in the span of less than 3 months, Hixie managed to conceive of the <a ping>, slap it into a WHATWG draft, and land the patch with hardly any discussion.  We've departed our long Ice Age and entered the brave new world of instant checkin.  So if anyone wants to work on this <link> UI again, this time it might take slightly less than seven years.
Alternatively, you could help clav update the current extension so it works with Firefox 1.5...
http://extensionroom.mozdev.org/more-info/linktoolbar

If anyone is thinking of taking this up again, with a view to getting some UI permanently into Firefox, I would counsel that less is more. Don't think "how can I provide UI for all the possible uses of <link>", but "What simple UI would get the most bang for the buck and be useful to the average user"?

Gerv
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: