Re: [link draft] Changing the model for links

In general, the idea of combining multiple rel values to change the semantic
meaning of individual rel values is counter intuitive at best.

It seems like we can make an exception for 'alternate' as a dual purpose rel
type which alone applies to the context, and in combination, applies to the
other rel types. And deprecate this use of combinations and encourage
minting new relation types for such cases.

How would you treat:

Link: <a>; rel="alternate"; rel="stylesheet"

Either we treat each rel string as an opaque value and match strings to
known values, or we provide instructions for normalizing link information
across multiple headers. The current draft implicitly provides the latter
which is the right approach.

More comments inline.

On 4/7/09 4:10 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

> Personally, I think that it would be only in pathological cases that
> it would be necessary to know the difference between the two (i.e.,
> real world Web pages will not point to a URI as both a stylesheet and
> as an alternate for themselves, so it's safe to say that even the
> first example above means that "a" is an alternate stylesheet).

This might be true for a human reading it, but not for a machine looking for
an individual rel value match. So an application looking for alternate
representation, is more likely to ignore the stylesheet rel than to assume
it is an alternate link to another stylesheet.

> However, it is important for Link to interoperate well with HTML4.
> Also, the HTML5 folks plan to use this model for other purposes (e.g.,
> "up up" to indicate a parent of a parent).

I can't see the value of 'up up' over minting other rel types (up-2, up-3,
etc.).

On 4/8/09 3:01 AM, "Phil Archer" <phil@philarcher.org> wrote:

> Can we somehow concatenate the context and the rel type with some
> syntactic sugar, something like "alternate-stylesheet" or
> "stylesheet(alternate)" - thus preserving a single token as the rel
> value? Any syntax would do here - the key thing being that it's the
> syntax that tells you that one value is context for the other. I guess
> the fact that this doesn't exist in HTML 4 is the biggest obstacle.

I don't like the idea of introducing new syntax for relation types. We
already have registered and extension. I think between more specialized rel
types and link extensions (such as priority="10"), we can accomplish the
same result without breaking the semantic meaning of individual rels.

On 4/8/09 3:14 AM, "Anne van Kesteren" <annevk@opera.com> wrote:
 
> You realize "alternate stylesheet" is in deployment already, right? We
> cannot change the construct at this point. It does not automatically mean
> by the way that in e.g. "search contact" search and contact also have some
> relationship. It just means that alternate is special when stylesheet is
> present.

That's not the interesting fact to examine. The question is how user-agents
make use of this combination. Do they have logic for trying the stylesheet
and then the alternate-stylesheet if it fails? How UA use this combination
is much more important than the fact it is present in some content.

But I still agree we should note this so that those looking for alternate
links, will avoid using those with stylesheet rel as well.

Speaking of existing deployment, we already have plenty of clients who do
not properly parse multiple values, without imposing more rules on rel
combinations.

EHL

Received on Wednesday, 8 April 2009 17:46:14 UTC