Closed Bug 68419 Opened 24 years ago Closed 23 years ago

W3C CUAP: Implement the HTML 4 recognized link types

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 87428
mozilla1.0

People

(Reporter: gerv, Assigned: pierre)

References

(Depends on 2 open bugs, )

Details

(Keywords: meta)

[ 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.
Blocks: 68427
Depends on: 2800, 57399, 59118
Keywords: meta
Hardware: PC → All
Why hasn't this been marked as a *duplicate* of bug #2800?
Unlike bug 2800, this applies to the <a> element as well as <link>.
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
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.)
qa contact updated.
QA Contact: gerardok → bsharma
changing the component to 'Layout'.
Assignee: clayton → karnaze
Component: HTML Element → Layout
QA Contact: bsharma → petersen
Target Milestone: --- → mozilla0.8.1
Reassigning to Pierre.
Assignee: karnaze → pierre
Target Milestone: mozilla0.8.1 → mozilla1.0
Depends on: LinkUI
bug 84728 has support for rel= on anchors...
Yes; as long as that isn't dropped, fixing bug 84728 will fix this bug. Gerv
Depends on: 103053
That was indeed a dup of 87428 (not 84728...) *** This bug has been marked as a duplicate of 87428 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Does the link toolbar deal with anchors now or is it just LINK tags? If it doesn't, we need to reopen this bug.
Gerv: I understood that anchors were deliberately disabled in bug 87428. Is that correct?
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
You need to log in before you can comment on or make changes to this bug.