link rev should attach to toolbar button with opposite meaning - rev="previous" <=> rel="next" etc

RESOLVED INVALID

Status

SeaMonkey
UI Design
--
enhancement
RESOLVED INVALID
16 years ago
8 years ago

People

(Reporter: Carsten Klapp, Assigned: Stuart Ballard)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
The browser should probably just treat link rev as a synonym for link rel, as
far as activating buttons in the "Site Navigation Bar' goes.

e.g.:
    <link rev="previous" href="example-url" />

should also activate the "previous" button, as if the webpage author had written:

    <link rel="previous" href="example-url" />
rev and rel mean totally different things.  rev="previous" means that the
current page is the "previous" of the page being pointed to by the <link rev>

I think we should wontfix this one and implement correct handling of rev...
(Reporter)

Comment 2

16 years ago
If a browser is trying to build a table or tree structure of a web site's
documents (notwithstanding any visual rendering of such data) for site
navigation then it's true that rev and rel do become important.

I don't think the Site Navigation Bar is used (or should be used) for doing
this, it should simply display all the links specified, and completely ignore
whether a link is specified as rev or rel.

The only way I can see to properly implement the information imparted by rev and
rel would be to create another (possibly floating window with a) toolbar and
tree display of documents, which would serve as an advanced form of the "Back"
and "Forward" buttons. Instead of navigating browser history as "Back" and
"Forward" do it would allow navigation based on the known hierarchy of the site
based on whether links were specified as rev or rel. I don't think the web is
ready for this yet though, it's too easy for a web page author to inadvertently
provide conflicting information whether a link is rel or rev, so these
attributes should probably be machine generated.

Some web sites don't even use rev and rel properly either, which would mess up
any site tree the example browser above would be trying to collect information
for. However this shouldn't stop the Site Navigation Bar from displaying the
link elements which were given.
Sure.  All that is true.  My point is that having <link rev="previous"> activate
the "previous" button would be incredibly misleading (and just go to the wrong
place on a well-constructed site).  It would make more sense to have it activate
the "next" button, since if we're the previous of whatever the whatever must be
the next of us.
(Assignee)

Comment 4

16 years ago
I've pondered doing an inverse relationship, ie treating rev="previous" as
synonymous with rel="next", etc. This would at least make some sense: if page A
is previous to page B, then page B is (probably) next after page A.

I think that would be just confusing for page authors though - as evidenced by
this bug, the existence of "rev" is already confusing if someone genuinely
thinks that rev="previous" means the same think as rel="previous". In that case,
just ignoring "rev" except for grandfathering-in the common scenario of
rev="made" is probably the best thing to do.

Can you give any examples of sites that use rev= for document structure? I'd
like to see whether the site is just wrong, or whether doing the inverse
relationship I just described would do any good for it.
(Reporter)

Comment 5

16 years ago
It's been a while since I saw any web pages using link rev= and I didn't
bookmark them, I'll be danged if I can find them again.

Boris' comments make sense, it would be confusing to go to the wrong place on a
well constructed site.

So the inverse mapping idea seems to me now to be the correct thing to do...
I'll keep looking for those sites to see whether they really do use link
rev=previous or whether they do it correctly.

With that said I'm agreeable to the original proposal of "wontfix this one" and
wait for an implementation of the correct handling of rev.

Thanks for the feedback,
Carsten
(Assignee)

Comment 6

16 years ago
Lets instead resummarize this bug to track a "real" fix for rev... it could
still end up getting WONTFIXed later, but I think everyone now agrees that the
original proposal of this bug isn't a good idea, but that doing the inverse
mapping _might_ be, at least.
Summary: link rev should also invoke toolbar buttons just like link rel → link rev should attach to toolbar button with opposite meaning - rev="previous" <=> rel="next" etc
Over to sballard and confirming RFE
Assignee: asa → sballard
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: GUI Features
Ever confirmed: true
OS: MacOS X → All
Hardware: Macintosh → All

Updated

14 years ago
Blocks: 103053
Product: Core → Mozilla Application Suite

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design

Comment 8

9 years ago
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
Status: NEW → UNCONFIRMED
HTML5 defines only one rev value, |made|, because nobody uses the others. Marking invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.