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. ***

*** 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 ]

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

Since bug 1995 is now under consideration, and it is very similar, I am reopening this bug.

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.

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.

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. ***

Later.

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

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.

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.

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.

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.

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... ;-)

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!

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.

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. ;-)

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?

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?

Accepting. The patch is attached.

> 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-.

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.

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.

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.

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.

I'll take it.

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.

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.

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.

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.

*** 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.

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...

> (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?

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.

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.

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.

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 ***

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.

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