I'd like there to be a way to tag one link on each page as the 'default' exit. The idea is that many pages have an obvious place to go next. For example, if you're reading a multi-page article, the next place to go is to the next page. To make this useful, I want an easy keystroke to use to follow that link. Maybe double-tapping the spacebar or something.

I think this is covered by bug 2800: "No UI for HTML2 LINK element". The LINK tag covered page group navigation such as previous, next, parent, etc.

cc'ing ian to see if this is a dup of that older bug...

Actually, this would be a sister bug to bug 2800, covering the 'rel' and 'rev' attributes of the <A> element itself (since the reporter wants to control a particular link on the page). See: http://www.w3.org/TR/html4/struct/links.html#adef-rel We need a UI spec for this, followed shortly by some test cases.

Ian, I think support for A REL and A REV is orthogonal to this bug. Wouldn't this bug be satisfied by a keyboard shortcut for going to the first specified LINK REL="next" element -- as the `Space' section of <http://critique.net.nz/project/mozilla/general/interface/keys/> has suggested for several months now? :-) I think pressing the Space bar at the end of a document with such an element should bring up a dialog (also activatable by using the space bar) reading `Advance to next document?', like the `Advance to next unread message in {folder/group name}?' dialog in Messenger.

mpt: right, that would be the part of the spec that says that when only one <a> element has the |rel="next"| attribute/value pair set, then hitting space at the end of the document would propose following that link.

So could this bug be fixed just by treating A REL/REV in the same way we treat LINK REL/REV -- showing those links in the Links Bar, in addition to their usual rendering?

That might be one possibility, yes.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.

Should we display the link type in a tooltip? If the link already contains a 'title' attribute, should we use a multiline tooltip? Example: <a href="dog.html" rel="Next" title="Information about my dog.">...</a> Tooltip: Next document: Information about my dog.

rfe, over to pchen

qa contact updated.

*** This bug has been marked as a duplicate of 87428 ***

This isn't a duplicate of bug 87428. That bug is only about supporting the LINK element (and the LINK HTTP header because it's equivalent to the LINK element). Currently bug 87428 has some code to handle REL on anchor elements, but it might be cut for performance reasons. It's not essential for resolving bug 87428. See the thread "HTML 2 <link> support" in n.p.m.ui. This is correctly a seperate enhancement. I'm marking this dependent on bug 87428, someone please reopen.

ok, reopening

SPAM. HTML Element component deprecated, changing component to Layout. See bug 88132 for details.

marking future

Sorry...Per my last update here is the Apache HTTP bug # `general/8971'

->default assignee

works in opera 7.10 (windows and linux beta 1).

I consider supporting REL attributes for the A tag a very *bad* idea. This would only yield a lot of sites which use things like <A href="somewhere" REL="next">...</A> for the only reason they don't know better, instead of using <LINK> tags which open the door to the internet for lots of blind etc. people. Unless every non-graphical browser which commonly uses the LINK tags recognises the A REL=... version as well, there is imho no reason to encourage anyone to write such stuff. If there where a possibility to vote against this feature, I'd do it.

The LINK tags are only for stuff that is not part of the content. But The A tags are part of the content and qualifying them is very usefull. It is not good to duplicate the same reference to the LINK navigation and the A navigation. If you do that browsers like Lynx display both, which is not very user friendly. An other reason is, with qualified A tags I can describe an object and its related properties and methods in plain text using the A tags to make the relations machine readable. This might be used to create an UML picture by collecting the A text into boxes which are connected by lines. Whay should I use Visio to do the drawing, if HTML gives me all the tools to express the relations machine readable? Visio is wasted work. A future version of CSS might enable us to draw arrows and lines to connect elements. When CSS comes with this, we simply can enhance our text by adding some CSS rules that do the grafical visualization of the relations. So don't block but create the future.

> It is not good to > duplicate the same reference to the LINK navigation and the A navigation. If you > do that browsers like Lynx display both, which is not very user friendly. Wrong. Utterly wrong. We are talking about well-designed HTML pages. For sake of accessibility (have a look at http://diveintoaccessability.org/) these should: 1. provide <link> tags, which provide a standard way to accomplish standard navigational tasks (rel=next, prev, up, home, search...) 2. have the textual content next in the page source (which doesn't necessarily mean it appears there in graphical browsers, when the famous "table trick" is used) 3. place the normal navigation below the textual content in the source. This has the following benefits for text-mode browsing: 1. important navi links won't scroll away, with no frames needed 2. interesting content comes next, and after reading it, you see the further links, e.g. to subpages, which can't be built with <link> tags anyway. It doesn't do any harm some links will be double. Every GUI offers more than one method to accomplish a task: e.g. to print, you can a) press Ctrl-P, or b) press Alt, F, P c) press Alt-F, P d) use the mouse in almost all english windows programs. I never heard anyone complain about this. It is important to use <link> tags, to make the internet usable at all for many, many handicapped people, and for those who just want to download a file in a ssh session on a remote machine, etc. Your suggestion would just increase the great number of badly designed, incompatible sites. Furthermore, having the textual content above the navigation in source is better for indexing by robots like googlebot. > An other reason is, with qualified A tags I can describe an object and its > related properties and methods in plain text using the A tags to make the > relations machine readable. This might be used to create an UML picture by > collecting the A text into boxes which are connected by lines. If you want to draw UML pictures, look for an appropriate XML dialect. Or build them using tables. Or use images and maps. Or make a proposal to the w3c. > Whay should I use Visio to do the drawing, if HTML gives me all the tools to > express the relations machine readable? That's not what HTML is meant for. > Visio is wasted work. No argument here ;-) > So don't block but create the future. You are not talking about the future but the past: a past, when everyone felt called upon to add lots of incompatible features to his own browser, causing the chaos we have now. There is enough to do, make Mozilla support e.g. all the cool features CSS 2.1 specifies now. I use Mozilla because it is one of the most standards compliant browsers; I'm not the only one. I certainly don't want it to do any incompatible gobbledigook. Compatibility is one of the most important things for the future of the web. I suggest INVALID.

Corrected link: http://diveintoaccessibility.org/ (sorry, written offline...)

You're just making a circular argument. The spec was designed with the idea that any application that looked at rel/rev on LINK elements should do the same for A elements. You're arguing that because some programs don't support the latter, we shouldn't. By that argument, we should also remove lots of other things whose wider acceptance on the web would be good for accessibility. You've also made the same argument twice. Please don't make it again unless you have something new to add.

(I have got working "next" and "previous" buttons with the link toolbar [http://cdn.mozdev.org/linkToolbar/] when testing attachment 122672 [details] because this extension also parses <a> elements. If that could help you...)