57399 - should support 'rel' and 'rev' of <A> element (e.g. default next link for each page)

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Mike Coleman]

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.

Comment 1

[Scott Brodmerkle]

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.

Comment 2

[sairuh (rarely reading bugmail)]

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

Comment 3

[Hixie (not reading bugmail)]

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.

Comment 4

[Matthew T (active 1999-2002)]

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.

Comment 5

[Hixie (not reading bugmail)]

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.

Comment 6

[Matthew T (active 1999-2002)]

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?

Comment 7

[Hixie (not reading bugmail)]

That might be one possibility, yes.

Comment 8

[Viswanath Ramachandran]

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

Comment 9

[Hixie (not reading bugmail)]

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

Comment 10

[Karl Ove Hufthammer]

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.

Comment 11

[Chris McAfee]

rfe, over to pchen

Comment 12

[bsharma]

qa contact updated.

Comment 13

[Gervase Markham [:gerv]]

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

Comment 14

[Tim 'Tool-Man' Taylor]

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.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

ok, reopening

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 17

[Peter Trudelle]

marking future

Comment 18

[John Rutherford]

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

Comment 19

[Asa Dotzler [:asa]]

->default assignee

Comment 20

[habere-et-dispertire]

Attachment: user agent test for <a rel="next"> support

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

Comment 21

[Tobias Herp]

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.

Comment 22

[Georg Maaß]

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.

Comment 23

[Tobias Herp]

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

Comment 24

[Tobias Herp]

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

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 26

[Xanthor Sccas]

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