User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401 Mozilla interprets the LinkType "START" in a way that I believe is not fully standards-compliant. Reproducible: Always Steps to Reproduce: 1. Select Menu Item VIEW=>SHOW=>Site Navigation Bar=>Show Always 2.Visit URL given above. Actual Results: The site navigation bar has the "First" button (next to a Rewind icon) grayed out Expected Results: *What I expected: Given that the "START" link-type is set in the REL attribute of a LINK tag on that page, I expected the First button (with its obviously intended Rewind meaning) to be active with the value of the <LINK REL="START" ... > as its destination. (Specifically, "http://www.augart.com/Literature/Doomed-Lensmen/" ) **The code in question is implemented at:http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/linkToolbarHandler.js#78 **The HTML 4.01 standard describes the semantics of various values for %LinkTypes at http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links Admittedly, the wording of the standard is open to interpretation. I interpreted it to mean that the logical point to start browsing the collection or sequence would be the target of the LINK REL=START. You will note that there is neither "FIRST" nor "LAST" nor "UP" nor "TOP" defined in the standard. **Dave Hodder, in <http://lists.w3.org/Archives/Public/www-html/2001Oct/0027.html>, has proposed "FIRST", "LAST", and others. You can see the response to that proposal in the threaded view on the list. In the context of Dave Hodder's proposed FIRST and LAST tags, then of course START becomes free to use in other contexts. However, my <em>point</em> here is that if someone is implementing using only the %LinkTypes described by the HTML 4.01 standard at http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links, then START is the only logical %LinkType to use to point to the point from which one starts browsing the story. And, then icon that looks like a music player's rewind-to-start icon is the logical one to use for START. **The original page I modified to make the sample URL is: <http://www.augart.com/Literature/Doomed-Lensmen/chapter1.html>. If you look there at the example URL I give above, you can see the context in which I used the LINK REL feature. **There is an exposition of these %LinkTypes and the different documents that have proposed them at: <http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html>. There is also a discussion of implementations of those types at: <http://homepages.paradise.net.nz/tomrobin/HTML_Link_Types.html>. **My Conclusion: The Right Thing should happen for people implementing exactly according to the HTML 4.01 spec. **Suggested fix: ***I would like to modify linkToolbarHandler.js so that there are buttons named "Start", "Next", and "Prev". The existing menus for Document and More can remain. ***The (current) "Top/ Up/ First / Previous / Next / Last" scheme should not be displayed unless there is internal evidence in the document (the presence of links with those names or their synonyms) that the document author was using these extensions. Otherwise people get the subtle impression that something is missing from the document (if half the navigation bar is grayed out). We don't want to make authors look bad who refrain from using nonstandard extensions. ***For people who want to use the TOP / UP/ FIRST and LAST %LinkTypes in a standards-compliant way, someone needs to write a "profile" that authors using them can include in their document, as described in the HTML 4.01 spec: <http://www.w3.org/TR/1999/REC-html401-19991224/types.html#idx-link_type-2>.

Fixed by checkin for bug 173674. But... > Mozilla interprets the LinkType "START" in a way that I believe is not fully > standards-compliant. There is no real standard for what "rel" values mean... *** This bug has been marked as a duplicate of 173674 ***

Boris: I half-agree with your statement in comment #1, that « There is no real standard for what "rel" values mean... ». The document <http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html> summarizes the currently-described link types and the different documents that have done so. Of those documents, certainly the majority of them are things like an expired IETF draft (1996) and the draft HTML 3.0 standard. Other link types, such as FIRST and LAST, are only documented by two email messages to the www-html@w3.org mailing list. As you say, «no real standard». *However*, the HTML 4.01 specification <http://www.w3.org/TR/html4/types.html#h-6.12> and the HTML 3.2 specification <http://www.w3.org/TR/REC-html32.html#link> both are current W3C recommendations (<http://www.w3.org/TR/#Recommendations>, <http://www.w3.org/TR/#html401>, <http://www.w3.org/TR/#REC-html32>). These are unarguably "real standards." They are the only ones that describe link types. Does this seem reasonable to you, or am I missing some information that would help me understand a bigger picture here? If so, I'd appreciate enlightenment.

None of those standards normatively describe link types. All the text is informative.

Repopened for original intent of bug 173674. See discussion there before commenting.

-> default owner.

Choess, this is all yours.

Since the discussion's moved to this bug, I want to make sure we all agree that the text describing the conventional interpretations of link types is indeed normative. The recommendation says: This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. And: At times, the authors of this specification recommend good practice for authors and user agents. These recommendations are not normative and conformance with this specification does not depend on their realization. These recommendations contain the expression "We recommend ...", "This specification recommends ...", or some similar wording. I looked carefully, and couldn't find the words "recommend" or "informative" anywhere in section 6, which contains subsection 6.12 that discusses the conventional interpretation of link types (http://www.w3.org/TR/html4/types.html#h-6.12).

Related bugs: bug 2800 and bug 103053. Not exactly sure if there are any _real_ dependencies, so I'll leave depend/block for others to set.

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420

Moved the "start" to the group with "first".

Pushed to comm-central: http://hg.mozilla.org/comm-central/rev/3dd223a8308b