Closed Bug 103469 Opened 23 years ago Closed 10 years ago

Need unified spec for rel=""

Categories

(Documentation Graveyard :: Web Developer, defect, P3)

Product:
Documentation Graveyard
Component:
Web Developer
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: choess, Assigned: choess)

References

(
URL
)

Details

Attachments

(1 file)

First draft of a potion of the rel-rev spec
10.21 KB, text/plain
Details 
"Standard" values for the "rel" attribute of <link> and <a> have been proposed 
in at least four different documents (see the above URL).  These documents 
sometimes conflict with each other and are confusing.  I'm working on a draft 
document that collates all link types still useful (i.e., eliminating "banner") 
and defines which are equivalent to which; when I've finished, I'll attach it 
here for discussion.  We need this to resolve some UI problems which really 
hinge on which types we recognize and how.
Blocks: 103053
Status: NEW → ASSIGNED
Depends on: 90966, 102972, 103436, 103456
Priority: -- → P3
Target Milestone: --- → mozilla0.9.6
QA Contact: sairuh → claudius
We should start with the IETF WebDAV relrev draft and go from there, we may want
to  ask that working group for a stamp of approval too.

Moving to Documentation
Component: XP Apps: GUI Features → Web Developer
Product: Browser → Documentation
Target Milestone: mozilla0.9.6 → ---
Version: other → unspecified
I disagree.  We should start with the current link toolbar implementation and go
from there.  We already started with various "official" specs, recommendations,
or contributed specs three years ago with bug 2800.  Then we debated them, and
eventually implemented something.  Please don't do an end run around all this
work just because you disagree with some of the mappings.

If we want documentation, I'll be happy to write up a "guide to using LINK" that
corresponds to this implementation.  If you want a spec, I'll copy-and-paste the
switch statement that maps REL values to link types and reformat for
non-programmers.
Tim, I think our current implementation could use a little work-it's regressed a
bit since the most detailed spec was worked out in 87428. Anyway, I've attached
a draft for comment; I'll be announcing it on the newsgroups shortly for discussion.
No longer depends on: 90966, 102972, 103436, 103456
(sorry about the spam, I had the dependencies hooked up backwards, and bugzilla
won't let you change that in one step :( )
Blocks: 90966, 102972, 103436
I am nost confused about what Next means in a hierarchy (same parent of
flattened)? Will write a mail to w3c and post link here.

IMO, it is very important that we do this stuff right. Ad-hoc implementation
will lead to the same mess we had with HTML. In other words, this bug is very
important IMO. I agree that we should get IETF and or w3c on the hook, if possible.
MY post about "next":
<http://lists.w3.org/Archives/Public/www-html/2001Nov/0006.html>

> We should start with the IETF WebDAV relrev draft and go from there

In the case of "next", it is by far the most well-thought. I wonder, why the
authors of the HTML spec appearently completely ignored it.

Also compare bug 109467.
Does this bug cover a UI spec for how the toolbar should work, or just
documenting what all the link types should mean and how they should be used in
an html document?

I think we should probably have separate bugs for these separate issues. Bugs
like bug 102990, bug 103417, bug 103429 and bug 103459 can't really be resolved
without a unified UI spec to work towards. However, they don't really impact the
meaning of the link types, which seems to be what this bug is about. So I think
they're really separate issues.

If I get a chance I'd like to write up a possible UI spec; at the moment,
though, I'm not sure whether to attach it to this bug or to file a new one for
it.

Thoughts?
brainstorming a bit:

I was thinking about rel vs rev attributes, and wondering if it made any sense
for mozilla to cache this data in some fashion so that if Page_A claims to be a
parent of Page_B then when you visit Page_B mozilla could indicate this in the
links toolbar even if Page_B doesn't bother to tell you about the relationship.


Page_A claiming rel relationship X to Page_B
    is equivilant to
Page_B claiming rev relationship X to Page_A


As an example of how this might work, suppose
    http://usenetarchive.example.com/
does not have any link relationships specified. However
    http://usenetarchive.example.com/comp.lang.perl.misc/
    http://usenetarchive.example.com/comp.lang.perl.modules/
    http://usenetarchive.example.com/comp.lang.perl.moderated/
each claim that
    http://usenetarchive.example.com/
is the parent page. Suppose you visit each of those three
newsgroup pages, and mozilla caches the information that the
homepage is a parent. Next time you visit the homepage, the
links toolbar remembers that those three pages were children
of the homepage, and now reflects those relationships even
thought there is not meta information in the homepage itself.

Pros:
    gets more leverage from incomplete link information
    gives user increased ease of access to related info
    like "what's related" functionality except that the
        mechanism does not impact privacy and requires
        explicit claims of relationship

Cons:
    requires its own cache (with associated prefs, etc)
    potential performance issues
    potential for third party abuse. eg:
        /~fredsucks/ claims to be child of /~fred/
        later, user visits /~fred/ and sees bad child
    potential for too much information. eg:
        every page in usenet archive lists homepage as parent
        user visits thousands of pages researching some issue
        user visits homepage
        links toolbar lists thousands of child pages

*if* anyone thought this was worth doing, prefs could
disable the feature and hopefully eliminate any performance
issues. Perhaps the UI could distinguish between relationships
which had been specified in the currently-viewed page and any
relationships cached from other pages. Maybe the other pages'
entries could be in italics or something. That along with a
preference indicating what those italic entries were and giving
a way to turn them off might go some way to reducing the impact
of potential abuses.

[x] enable links toolbar
    [x] hide toolbar when no links available
    [x] remember and display relationships between pages
        (these links will display in italics)
        [x] for any page, remember only the most recent [_25_]
            relationships specified in other documents

That [_25_] would be a menu with a few reasonable values.

does anyone see anything in the standards which would preclude
such a function? It seems to me like a reasonable use of the
available information which would benefit users.

-matt

Foudn the following in WAI: "* Allow depth-first as well as breadth-first
navigation."
(<http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-nav-structure>, example
techniques, 12.)
It refers to document-internal navigator, but I found it interesting, because it
suppotrs my view that "Next" may mean the first child or the next sibling
(although there are childs), depending on content and user preference/mood.
If it were up to me I'd say that a "first child" could be indicated by <link
rel="child next"> and a "next sibling" could be indicated just by <link
rel="next">. If the "child next" link is first in document order, it will be
preferred over the "next" from the POV of populating the "Next" button.

Of course, that would completely exclude use of the "next sibling" link from the
UI. Resolving that issue would require making the "next" and "previous" buttons
(and "up", IMHO) work like "back" and "forward" - with little dropdown arrows
next to them, and a menu.
Blocks: 103034
I hope WHATWG is going to address this. Ian?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: