Gervase Markham [:gerv] Reporter
	Description • 24 years ago

[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

2.4 Implement the HTML 4 recognized link types.

     Section 6.12 of the HTML 4.01 Recommendation [HTML 4.01] lists some
     link types that may be used by authors to make assertions about linked
     Web resources. These include alternate, stylesheet, start, next, prev,
     contents, glossary, and others. Although the HTML 4.01 specification
     does not specify definitive rendering or behavior for these link
     types, user agents should interpret them in useful ways. For instance,
     the start, next, prev, and contents link types may be used to build a
     table of contents, or may be used to identify the print order of
     documents, etc.

	Karl Ove Hufthammer
	Comment 1 • 24 years ago

Why hasn't this been marked as a *duplicate* of bug #2800?

	Robin Lionheart
	Comment 2 • 24 years ago

Unlike bug 2800, this applies to the <a> element as well as <link>.

	Gervase Markham [:gerv] Reporter
	Comment 3 • 24 years ago

We aren't closing W3C CUAP bugs until the issue is fixed. That way, the tracking 
bug actually makes sense (if we marked all of them dupes, the tracking bug would 
look like we'd fixed it all, unless we updated it every time. But, if we did 
that, it would generate loads of spam, because the tracking bug has 20 
dependencies.)

Trust me on this one :-)

Gerv

	Karl Ove Hufthammer
	Comment 4 • 24 years ago

OK, I understand!

The W3C talks about building a table of contents based on link types. I assume 
they mean a basic *site map*, not a TOC. A TOC would be built based on HTML 
headings ('h1', 'h2', 'h3' &c.).

The site map idea is covered in bug #2800, but is there a bug report on the 
TOC? (Amaya already implements this.)

	bsharma
	Comment 5 • 24 years ago

qa contact updated.

	bsharma
	Comment 6 • 24 years ago

changing the component to 'Layout'.

	karnaze (gone)
	Comment 7 • 24 years ago

Reassigning to Pierre.

	Eric Hodel
	Comment 8 • 23 years ago

bug 84728 has support for rel= on anchors...

	Gervase Markham [:gerv] Reporter
	Comment 9 • 23 years ago

Yes; as long as that isn't dropped, fixing bug 84728 will fix this bug.

Gerv

	Pierre Saslawsky Assignee
	Comment 10 • 23 years ago

That was indeed a dup of 87428 (not 84728...)


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

	Mike Young
	Comment 11 • 23 years ago

Does the link toolbar deal with anchors now or is it just LINK tags?

If it doesn't, we need to reopen this bug.

	Pierre Saslawsky Assignee
	Comment 12 • 23 years ago

Gerv: I understood that anchors were deliberately disabled in bug 87428.  Is that 
correct?

	Gervase Markham [:gerv] Reporter
	Comment 13 • 23 years ago

Anchors were deliberately disabled:

a) For performance reasons
b) Because there was some argument about whether rel= and rev= on an A tag were
meant in page context or local context, and therefore whether it was appropriate
to have them as part of the bar.

If we are going to implement UI for rel and rev on anchors (and there is nothing
that says we have to) then we need to decide how to do it.

Gerv