This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7475 - Semantics of rel=first and rel=index breaks specs and implementations
Summary: Semantics of rel=first and rel=index breaks specs and implementations
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://lists.w3.org/Archives/Public/p...
Whiteboard:
Keywords: TrackerIssue, WGDecision
: 20931 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-09-01 01:57 UTC by Leif Halvard Silli
Modified: 2013-10-22 22:12 UTC (History)
11 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2009-09-01 01:57:59 UTC
The current draft defines semantics for rel="index" and rel="first" that break with current specs (HTML 4 and XHTML) as well as with implementations (Opera 9.x, Seamonkey and iCab).

In a summary, the draft 

a) makes synonyms out of rel keywords that are not keywords in any other spec or implementation 

       Example: "begin" and "start" as synonyms for "first". ("First" isn't defined in specs at all yet.)
       See draft: http://www.whatwg.org/specs/web-apps/current-work/#link-type-first

b) splits keywords that otherwise are synonyms. 

        Example: "top" is split from "start" and "home" [and made synonymous with "index" instead see above]
        See draft: http://www.whatwg.org/specs/web-apps/current-work/#link-type-index 

Message to HTMLwg for more detais: http://lists.w3.org/Archives/Public/public-html/2009Sep/0003
Comment 1 Leif Halvard Silli 2009-09-01 15:00:57 UTC
Typo: 

In  a) the second instance of "keywords" was meant to be the word "synonyms" - like so:

a) makes synonyms out of rel keywords that are not SYNONYMS in any other spec or implementation 
Comment 2 Leif Halvard Silli 2009-09-02 23:30:52 UTC
Alexandre Alapetite informs about how "Link Widgets" implements "first", "index" etc:

              http://lists.w3.org/Archives/Public/public-html/2009Sep/0122.html

The "XHTML Vocabulary" 

http://www.w3.org/1999/xhtml/vocab/

The XHTML vocabulary has "last" as the opposite of "start". This contradicts how "last" is interpreted in Opera, Seamonkey and iCab, where "first" and "last" are opposites without "start" and "first" being the same thing. However, the XHTML Vocab is here seemingly in line with the HTML 5 draft with regard to how it treats "first" and "start" as synonyms.

But XHTML Vocab and the current draft still disagrees about "index".
Comment 3 Ian 'Hixie' Hickson 2009-09-18 19:24:30 UTC
Having read all the documenting materials here, I concluded as I did when I did the research to write that part of the spec in the first place: it's a huge big giant mess that nobody agrees on, and it's implemented in such a small number of software packages and used by such a small fraction of users of those packages that it would be better to dramatically reduce the number of keywords, and then map legacy keywords to their closest synonyms, than to try to continue to support the huge number of existing keywords that are in use today.

I believe that the spec provides a more coherent model for moving forwards and converging existing implementations on a single model than would be achieved by implementing the proposals in this bug and in the materials linked to from this bug.

As such, I haven't changed the spec for this issue.
Comment 4 Alexandre Alapetite 2009-11-15 22:51:57 UTC
Dear Ian,
With regard to @rel={top,index,contents,toc}, I believe that the situation before HTML5 was pretty clear and with a good consensus, but the current HTML5 draft introduces some severe incompatibilities (please note that I have no issue with @rel="first" as currently defined in HTML5, so the title of this bug could be updated AFAIC).

In order to illustrate this fact, I have attempted to summarise the major information in the following draft table:

http://alexandre.alapetite.fr/divers/vrac/20091115_HTML_link_rel.html

The problems in the current version of HTML5 can IMHO be resumed to the following:

1) The traditional concepts of "table of contents" and "index" (i.e. a list of names or topics that are referred in a book, etc., usually arranged at the end of a book in alphabetical order) have disappeared in HTML5, while they exist in HTML4, HTML3.2, are used in the wild (also in other W3C documents), and backed up by several implementations, all agreeing. (See the above table for details)

2) Those two traditional concepts of "index" and "table of contents" have been merged into the traditional concept of "top" or "home", as defined in HTML3.2 and implemented in e.g. Opera, SeaMonkey, etc. There is also a good consensus in the interpretation of "top" or "home".

3) Against all definitions, this traditional concept of "top" or "home" has been renamed "index" in HTML5. The current definition of "index" in HTML5 ("leading to the document that is the top of the hierarchy") has simply nothing to do with an index (as defined in an English dictionary, or HTML4, HTML3.2, etc.).

Therefore, I urge you to reconsider this chapter, for which I propose the following changes.

A) (6.12.3.17.1) Rename this concept "top" instead of the erroneous "index", and remove "index", "contents" and "toc" from this concept. Maybe add "home" as a synonym.

B) Reintroduce the traditional concept of "index" (i.e. a list of names or topics that are referred in a book, etc., usually arranged at the end of a book in alphabetical order), or in the worst case just drop it from the specification.

C) Reintroduce the traditional concept of "Table of Contents" (i.e. a list of the main points or information in a book, usually at the front of the book), or in the worst case just drop it from the specification. Make "toc" a synonym.

D) (Detail) Maybe add "parent" as a synonym of "top".

Should it be necessary, I would be willing to contribute my services to improve this chapter, or create documents summarizing the current situation as I have just attempted with

http://alexandre.alapetite.fr/divers/vrac/20091115_HTML_link_rel.html

Thank you for your consideration.

Best regards,
Alexandre Alapetite
Technical University of Denmark
http://alexandre.alapetite.fr

P.S.: Thanks to Leif Halvard Silli for his contributions.
Comment 5 Ian 'Hixie' Hickson 2010-01-04 09:18:20 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

Thank you for this research. It is consistent with the results I had found myself when studying this several years ago.

While I agree with you that the few client implementations that support these values have indeed been considering these as separate meanings, that in itself is not a convincing argument. It is clear that as designed so far, the feature has been a failure (virtually nobody uses it). The main way to increase the likelihood that something like this will be used is to simplify it, which is part of what HTML5 does.

In actual use, I would guess that WordPress is amongst the biggest users of this feature. According to your table, if I'm not misreading it, WordPress uses "index" (and "start") as defined in HTML5. It doesn't have separate index and toc pages. Indeed none of the other CMSes you list use "index" at all. Plone and DotClear use "contents", but it's not clear if the distinction they make is especially good from a usability perspective.

I do agree that the definitions in HTML5 rock the boat. However, given the utter mess we are starting with, and given the rarity of these features, I think it is a worthwhile cost. The alternative, IMHO, quite apart from making the feature more complicated by having more keywords, would be to just drop the whole thing altogether.

(Note that the word "index" here is not used in the printed-book sense, but in the sense of "index.html", the default page on Apache.)
Comment 6 Maciej Stachowiak 2010-03-14 14:50:30 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Comment 7 Leif Halvard Silli 2010-04-19 12:26:11 UTC
This issue is also related to the Link registry.

When Ian closed this issue, I discussed it with Julian Reschke and  Alexandre Alapetite.  We agreed to no do anything until the Link registry was ready etc. 

It goes without saying that I do not agree with the resolution of this bug. Will be awaiting the link registry for further input.
Comment 8 Leif Halvard Silli 2010-04-19 12:28:02 UTC
The link registry = ISSUE-27
Comment 9 Ian 'Hixie' Hickson 2010-08-16 22:06:27 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: No new information since comment 5.
Comment 10 Leif Halvard Silli 2010-08-16 23:06:19 UTC
This would break with how these link types are specified elsehwere. I think this issue is ready for the tracker.
Comment 11 Ian 'Hixie' Hickson 2010-08-17 18:53:21 UTC
Do not reopen bugs that are to become issues. That is an invalid use of the bug system. Please see the document cited above for details.
Comment 12 Leif Halvard Silli 2010-09-02 13:12:53 UTC
(In reply to comment #10)
> This would break with how these link types are specified elsehwere. I think
> this issue is ready for the tracker.

Suggested title of the Tracker issue: Do not break implemented link types

Suggested text of Tracker issue:  Some of the drafts/the editor's proposed re-definitions and re-canonicalizations  of some of the link types, will 'break the Web' as they represent a break with how  these link relation keywords  are generally implemented and/or specified. For a good overview over how existing specs and implementations define or canonicalize link relations, see  Alexandre Alapetites table. (Current link to his table: http://alexandre.alapetite.fr/divers/vrac/20091115_HTML_link_rel.html )
Comment 13 Leif Halvard Silli 2010-09-02 14:09:35 UTC
(In reply to comment #12)  

]] 4.12.4.18.1 Link type "first"
The first keyword may be used with link, a, and area elements. This keyword creates a hyperlink.
The first keyword indicates that the document is part of a sequence, and that the link is leading to the document that is the first logical document in the sequence.
Synonyms: For historical reasons, user agents must also treat the keywords "begin" and "start" like the first keyword. [[

Issue annotation: Summary: the problem is that 'start' is defined as synonym for 'first.  'start' is today mainly treated as synonym for "start page/home page". Start page is very common word for 'home page' in the non-English world. Thus it should be treated as synonym for 'top' instead.

]] 4.12.4.17.1 Link type "index"
The index keyword may be used with link, a, and area elements. This keyword creates a hyperlink.
The index keyword indicates that the document is part of a hierarchical structure, and that the link is leading to the document that is the top of the hierarchy. It conveys more information when used with the up keyword (q.v.).
Synonyms: For historical reasons, user agents must also treat the keywords "top", "contents", and "toc" like the index keyword.[[

Issue annotation: 
0. Ian suggest to conflate many link types which are treated as different link types in the wild. E.g Alexandre's table shows that mst user agents/user agent addons see 'top', 'index' and 'toc' as different things. Only 'toc' and 'contents' are often seen as same thing. What does Ian expect? That e.g. iCab offers a much simpler links relations toolbar in order to treat these things as synonyms?
1. 'User agents and use agent addons treats 'index' as  index page in the book sense of the word (index in a book). Only Wordpress breaks that and uses Ian's dumbed down (Apache's index.html pages) interpretation. (However, Wordpress makes scarce use of link type - and the fewer link types one uses, then of course, the more synonymous - in practically speaking - does those terms become.)
2. Since the starting point is wrong, then it becomes meaningless to say that 'top'/'content'/'toc' should be considered synonyms of 'index'.
Comment 14 Julian Reschke 2010-09-02 14:31:24 UTC
Raised as http://www.w3.org/html/wg/tracker/issues/118.
Comment 15 Maciej Stachowiak 2011-02-28 22:16:49 UTC
The HTML Working Group hereby adopts the Change Proposal to drop support for rel="" values based on the lack of interest from 
implementors and users.

http://lists.w3.org/Archives/Public/public-html/2010Nov/0042.html

Please execute the edits specified in the Change Proposal.
Comment 16 contributor 2011-03-02 01:03:18 UTC
Checked in as WHATWG revision r5924.
Check-in comment: Drop support for rel=up, rel=last, rel=index, rel=first, and any related synonyms.
http://html5.org/tools/web-apps-tracker?from=5923&to=5924
Comment 17 Ian 'Hixie' Hickson 2011-03-02 01:03:54 UTC
Done.
Comment 18 Ian 'Hixie' Hickson 2013-10-22 22:12:10 UTC
*** Bug 20931 has been marked as a duplicate of this bug. ***