7475 2009-09-01 01:57:59 +0000 Semantics of rel=first and rel=index breaks specs and implementations 2013-10-22 22:12:10 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified All All RESOLVED FIXED http://lists.w3.org/Archives/Public/public-html/2009Sep/0003 TrackerIssue, WGDecision P3 normal LC 1 xn--mlform-iua ian alexandre contributor fantasai.bugs ian julian.reschke mike mjs Ms2ger public-html-admin public-html-wg-issue-tracking xn--mlform-iua public-html-bugzilla oldest_to_newest 26766 0 xn--mlform-iua 2009-09-01 01:57:59 +0000 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 26769 1 xn--mlform-iua 2009-09-01 15:00:57 +0000 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 26802 2 xn--mlform-iua 2009-09-02 23:30:52 +0000 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". 27305 3 ian 2009-09-18 19:24:30 +0000 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. 29584 4 alexandre 2009-11-15 22:51:57 +0000 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. 30359 5 ian 2010-01-04 09:18:20 +0000 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.) 33375 6 mjs 2010-03-14 14:50:30 +0000 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. 35142 7 xn--mlform-iua 2010-04-19 12:26:11 +0000 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. 35143 8 xn--mlform-iua 2010-04-19 12:28:02 +0000 The link registry = ISSUE-27 37510 9 ian 2010-08-16 22:06:27 +0000 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. 37531 10 xn--mlform-iua 2010-08-16 23:06:19 +0000 This would break with how these link types are specified elsehwere. I think this issue is ready for the tracker. 37571 11 ian 2010-08-17 18:53:21 +0000 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. 38395 12 xn--mlform-iua 2010-09-02 13:12:53 +0000 (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 draft’s/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 Alapetite’s table. (Current link to his table: http://alexandre.alapetite.fr/divers/vrac/20091115_HTML_link_rel.html ) 38413 13 xn--mlform-iua 2010-09-02 14:09:35 +0000 (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'. 38414 14 julian.reschke 2010-09-02 14:31:24 +0000 Raised as http://www.w3.org/html/wg/tracker/issues/118. 46108 15 mjs 2011-02-28 22:16:49 +0000 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. 46164 16 contributor 2011-03-02 01:03:18 +0000 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 46165 17 ian 2011-03-02 01:03:54 +0000 Done. 95141 18 ian 2013-10-22 22:12:10 +0000 *** Bug 20931 has been marked as a duplicate of this bug. ***