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...
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.
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.
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
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.
Over to sballard and confirming RFE
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
HTML5 defines only one rev value, |made|, because nobody uses the others. Marking invalid.