201979 - Questionable interpretation of <LINK REL="START" ... > in suite/browser/linkToolbarHandler.js

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Steven Augart]

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>.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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 ***

Comment 2

[Steven Augart]

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
[e-mail] 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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Alon Altman]

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

Comment 5

[Alon Altman]

-> default owner.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Choess, this is all yours.

Comment 7

[Steven Augart]

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).

Comment 8

[Grey Hodge (jX)]

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.

Comment 9

[Robert Kaiser]

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

Comment 10

[Robert Kaiser]

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

Comment 12

[Edmund Wong (:ewong)]

Attachment: Set linkToolbar to respond to rel="start".

Comment 13

[Edmund Wong (:ewong)]

Attachment: Set linkToolbar to respond to rel="start". (v2)

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

Comment 14

[Edmund Wong (:ewong)]

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