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
Steps to Reproduce:
1. Select Menu Item VIEW=>SHOW=>Site Navigation Bar=>Show Always
2.Visit URL given above.
The site navigation bar has the "First" button (next to a Rewind icon) grayed out
*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,
**The code in question is implemented
**The HTML 4.01 standard describes the semantics of various
values for %LinkTypes at
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
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
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:
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:
There is also a discussion of implementations of those types at:
The Right Thing should happen for people implementing exactly
according to the HTML 4.01 spec.
***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
***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:
Fixed by checkin for bug 173674. But...
> Mozilla interprets the LinkType "START" in a way that I believe is not fully
There is no real standard for what "rel" values mean...
*** This bug has been marked as a duplicate of 173674 ***
I half-agree with your statement in comment #1, that
« There is no real standard for what "rel" values mean... ». The document
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
firstname.lastname@example.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/#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
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
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.
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
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
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.
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
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
*** Bug 556239 has been marked as a duplicate of this bug. ***
Created attachment 600765 [details] [diff] [review]
Set linkToolbar to respond to rel="start".
Created attachment 600768 [details] [diff] [review]
Set linkToolbar to respond to rel="start". (v2)
Moved the "start" to the group with "first".
Pushed to comm-central: