Subject: [link draft] Changing the model for links

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Apr 2009 09:10:58 +1000

I've been discussing the link draft with Ian Hickson, who points out  
that in HTML4, there's a difference between

<link rel="stylesheet" href="a"/>
<link rel="stylesheet alternate" href="a"/>

and

<link rel="stylesheet alternate" href="a/>

(see <http://www.w3.org/TR/html401/present/styles.html#specifying-external 
 > for the background of why these are different)

In the current link draft, there isn't any way to express the  
difference between these; the underlying model is

[ context ] ---[ relation type ]---> [ target ]

where 'relation type' is singular.

To accommodate this use, the model would need to be something like

[ context ] ---[ list of relation types ]---> [ target ]

noting that there may be more than one list of relation types between  
any context and target.

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

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

The practical impact of making this change is that serialisations of  
links won't be able to collapse multiple relation types between two  
URIs into one link; they'll have to be separate to allow this  
interpretation.

So, for example, if you have link types ['w', 'x', 'y z'] between A  
and B, it will have to be serialised as

   Link: <B>; rel="w"
   Link: <B>; rel="x"
   Link: <B>; rel="y z"

in HTTP headers, NOT

   Link: <B>; rel="w x y z"

because that's ambiguous.

The alternative is to say that the 'stylesheet alternate' combination  
isn't specific to how it's serialised, but is tied to the occurrence  
of the links. I.e., when both relations are present in links between  
the same resources, these special semantics take affect. However, this  
does seem to directly conflict with the HTML4 language (see link  
above), so I don't think doing so is viable.

Comments?

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Apr 2009 11:26:11 +0200

Mark Nottingham wrote:
> (see 
> <http://www.w3.org/TR/html401/present/styles.html#specifying-external> 
> ...

Clarifying... Did you mean:

   <link rel="stylesheet" href="a"/>
   <link rel="alternate" href="a"/>

and

?

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Apr 2009 19:36:09 +1000

Yes, of course... :)

On 08/04/2009, at 7:26 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> I've been discussing the link draft with Ian Hickson, who points  
>> out that in HTML4, there's a difference between

---

From: Phil Archer <[email-masked]>
Date: Wed, 08 Apr 2009 11:01:24 +0100

My initial reaction is a long groan. This is an aspect of HTML 4 of 
which I'd been blissfully ignorant. OK, wise up...

Here's a possible case using white space separated lists of rel values:

Link: <powder1.xml> rel="describedby mobileOK" ...
Link: <powder2.xml> rel="describedby dc" ...

This is meant to imply that powder1.xml is a POWDER document that 
contains a mobileOK claim and that powder2.xml is a similar document 
that contains a bunch of Dublin Core descriptors. In other words, /both/ 
relationship apply.

That's rather different from the "alternate stylesheet" construct, or, 
indeed the "up up" one where one rel value contextualises the other.

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.

For me, the biggest hole in Link in this respect is the lack of support 
for media types. Not being able to write

Link <styles1.css> media="handheld" ...
Link <styles2.css> media="screen" ...

is a real downer but I know this has been raised before.

Phil.

Mark Nottingham wrote:
> In the current link draft, there isn't any way to express the difference 
> between these; the underlying model is
> 
> 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).
> 
> 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).
> 
> links won't be able to collapse multiple relation types between two URIs 
> into one link; they'll have to be separate to allow this interpretation.
> 
> So, for example, if you have link types ['w', 'x', 'y z'] between A and 
> B, it will have to be serialised as
> 
>   Link: <B>; rel="w"
>   Link: <B>; rel="x"
>   Link: <B>; rel="y z"
> 
> in HTTP headers, NOT
> 
>   Link: <B>; rel="w x y z"
> 
> isn't specific to how it's serialised, but is tied to the occurrence of 
> the links. I.e., when both relations are present in links between the 
> same resources, these special semantics take affect. However, this does 
> seem to directly conflict with the HTML4 language (see link above), so I 
> don't think doing so is viable.
> 
> Comments?
> 
> -- 

-- 

Phil Archer
http://philarcher.org/www@20/

i-sieve technologies                |      W3C Mobile Web Initiative
Making Sense of the Buzz            |      www.w3.org/Mobile

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 08 Apr 2009 12:14:56 +0200

> the fact that this doesn't exist in HTML 4 is the biggest obstacle.

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.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Phil Archer <[email-masked]>
Date: Wed, 08 Apr 2009 11:23:23 +0100

Anne van Kesteren wrote:
> 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.

Yes, I understand that. I'm trying to suggest a general way forward. If 
"alternate stylesheet" is the only contextual relationship already 
deployed (?) then an exception can perhaps be made for that but the 
introduction of "up up" and, no doubt, others in the future, needs to be 
disambiguated. As it is now, we have two different meanings of rel="x y" 
depending whether X and y happen to be alternate and stylesheet or some 
other values.

If such a formalism were to be introduced then "alternate stylesheet" 
can be deprecated and who knows, might one day even disappear along with 
<FONT> ;-).

-- 

Phil Archer

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 08 Apr 2009 12:26:40 +0200

> depending whether X and y happen to be alternate and stylesheet or some  

Yes, you'll have to know the actual values. You'll need to know those  
anyway though to know what the link relation means.

> can be deprecated and who knows, might one day even disappear along with  

Things do not disappear on the Web :-)

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Apr 2009 20:53:53 +1000

On 08/04/2009, at 8:26 PM, Anne van Kesteren wrote:

> On Wed, 08 Apr 2009 12:23:23 +0200, Phil Archer  
> <[email-masked]> wrote:
>> Yes, I understand that. I'm trying to suggest a general way  
>> forward. If "alternate stylesheet" is the only contextual  
>> relationship already deployed (?) then an exception can perhaps be  
>> made for that but the introduction of "up up" and, no doubt, others  
>> in the future, needs to be disambiguated. As it is now, we have two  
>> different meanings of rel="x y" depending whether X and y happen to  
>> be alternate and stylesheet or some other values.
>
> Yes, you'll have to know the actual values. You'll need to know  
> those anyway though to know what the link relation means.

What's the status of "up up", etc. in HTML5 these days? If we can  
grandfather in "alternate stylesheet" and not encourage other  
combinations, that may be a good way forward.

Also, has testing been done around UAs with regard to serialisation in  
HTML? I.e., which of these qualify as an alternate stylesheet  
according to implementations?

<link rel="alternate stylesheet" href="a"/>
<link rel="stylesheet alternate" href="a"/>
<link rel="stylesheet" href="a"/><link rel="alternate" href="a"/>

Again, if "alternate stylesheet" is grandfathered in and "up up" is  
supported by saying that all forms that result in two links to the  
same target with 'up' as the relation, it's a lot easier to get there.

>> If such a formalism were to be introduced then "alternate  
>> stylesheet" can be deprecated and who knows, might one day even  
>> disappear along with <FONT> ;-).
>

Yup, absolutely, but we don't need to invent new variations of <font>  
just because the old one is there...

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 08 Apr 2009 13:03:19 +0200

> combinations, that may be a good way forward.

Not sure what the status is.

> HTML? I.e., which of these qualify as an alternate stylesheet according  
> to implementations?
>

The first two.

> supported by saying that all forms that result in two links to the same  
> target with 'up' as the relation, it's a lot easier to get there.

That doesn't really work. E.g. it's quite likely that pages have "up"  
links both as data in <link> but also within the page using <a>. You don't  
want those to add up I think.

>>> can be deprecated and who knows, might one day even disappear along  
>>> with <FONT> ;-).
>>

It's called style="" :-)

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Apr 2009 21:16:07 +1000

On 08/04/2009, at 9:03 PM, Anne van Kesteren wrote:

>>
>> Also, has testing been done around UAs with regard to serialisation  
>> in HTML? I.e., which of these qualify as an alternate stylesheet  

Hmm. HTML4 doesn't even really give license to do the second form; is  
that consistent behaviour across all browsers?

> That doesn't really work. E.g. it's quite likely that pages have  
> "up" links both as data in <link> but also within the page using  
> <a>. You don't want those to add up I think.

Good point.

So, I'm very interested in whether 'up up' is a good idea, whose idea  
it is, who wants to implement it, and who already has.

More to the point, does anybody really need 'up up up up up up up',  
which is what this implies?

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 08 Apr 2009 13:26:44 +0200

> that consistent behaviour across all browsers?

HTML4 is a very vague specification. If you read it literally "alternate  
stylesheet stylesheet" should not specify an alternate stylesheet either.  
I don't think that was the intent. Though actually, it also says 'Adding  
the keyword "alternate" to the rel attribute makes it an alternate style  
sheet:' which does not imply an order.

The behavior is consistent as far as I know.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Apr 2009 14:48:38 +0200

> don't think doing so is viable.

It seems that the use of rel="alternate stylesheet" actually is a bug in 
HTML4, in that it's not consistent with the definition of the 
"alternate" link relation:

"Alternate
     Designates substitute versions for the document in which the link 
occurs. When used together with the lang attribute, it implies a 
translated version of the document. When used together with the media 
attribute, it implies a version designed for a different medium (or 
media)." -- <http://www.w3.org/TR/html401/types.html#type-links>

So the meaning of "alternate", when combined with "stylesheet", really 
changes from the default meaning.

Proposal: acknowledge this inconsistency, and contain it to the HTML 
syntax, thus

   <link rel="alternate stylesheet" href="/foo.css" />

becomes something like

   Link: </foo.css>; rel="alternate-stylesheet stylesheet"

in an HTTP header (mapping "alternate" to "alternate-stylesheet" if and 
only if it's used together with "stylesheet").

BR, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 8 Apr 2009 10:45:26 -0700

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.

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

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

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

> relationship. It just means that alternate is special when stylesheet is

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

---

From: Ian Hickson <[email-masked]>
Date: Wed, 8 Apr 2009 18:37:23 +0000 (UTC)

Note that in HTML, the following:

   <link href="a.css" rel="stylesheet">
   <link href="b.css" rel="stylesheet">
   <link href="a.css" rel="stylesheet">

...is visibly different to the following case:

   <link href="a.css" rel="stylesheet">
   <link href="b.css" rel="stylesheet">

...and is script-detectably different to the following cases:

   <link href="b.css" rel="stylesheet">
   <link href="a.css" rel="stylesheet">

   <link href="a.css" rel="stylesheet">
   <link href="a.css" rel="stylesheet">
   <link href="b.css" rel="stylesheet">

   <link href="b.css" rel="stylesheet">
   <link href="a.css" rel="stylesheet">
   <link href="a.css" rel="stylesheet">

Similarly, the position of <link> elements relative to other elements 
(e.g. <style>, <script>) and HTTP Link: headers is relevant to behaviour.

> is a real downer but I know this has been raised before.

Yeah, it seems like we would want provide attributes like media=""... 
HTML5 introduces sizes="" for one rel-type, if HTML is to use the same 
model so that you can set favicons from Link headers also, then we'd have 
to include this too.

On Wed, 8 Apr 2009, Mark Nottingham wrote:
> 
> What's the status of "up up", etc. in HTML5 these days?

Tentative. (The section is marked "last call for comments".)

I think it would be very unfortunate to lost this feature just because the 
underlying model can't describe it, though.

> <link rel="stylesheet" href="a"/><link rel="alternate" href="a"/>

The first two. I don't know of any software that does special things with 
rel="" for serialisation, so I haven't tested anything on that side.

> target with 'up' as the relation, it's a lot easier to get there.

I don't think that would really work, I think it would be quite plausible 
for example for pages to have breadcrumb links at the top and bottom of a 
page.

Also, note that as defined in HTML5 the breadcrumb mechanism is scoped to 
the current paragraph. This is something else that might be hard to 
express in a common data model.

On Wed, 8 Apr 2009, Mark Nottingham wrote:
> 
> So, I'm very interested in whether 'up up' is a good idea, whose idea it 
> is, who wants to implement it, and who already has.
> 

Link types in general aren't that widely used, sadly. The idea with the 
new rel-up/rel-index feature in HTML5 is to enable breadcrumbs to be 
expressed; quite a lot of people have asked for ways to do this. I don't 
know if what we have now is the best way to do it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 8 Apr 2009 13:42:56 -0700

But this is a different issue. UA applications use this as an include directive, which makes the order matter. The question is, what do browsers do with links with rel='stylesheet' and other values they do not understand?

EHL

On 4/8/09 11:37 AM, "Ian Hickson" <[email-masked]> wrote:

---

From: Ian Hickson <[email-masked]>
Date: Wed, 8 Apr 2009 21:04:13 +0000 (UTC)

On Wed, 8 Apr 2009, Eran Hammer-Lahav wrote:
>
> But this is a different issue. UA applications use this as an include 
> directive, which makes the order matter. The question is, what do 
> browsers do with links with rel='stylesheet' and other values they do 
> not understand?

They use the style sheet.

A page with, say, <link rel="icon stylesheet" href=...> will use ... as 
a stylesheet and a favicon. I don't guarantee that every browser will do 
this for every combination of rel types, because this is an area where 
bugs are common and testing defficient. But for 'stylesheet' it is pretty 
widely implemented correctly, I believe.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 8 Apr 2009 14:10:04 -0700

So what do browsers do about alternate stylesheet?

EHL

---

From: Ian Hickson <[email-masked]>
Date: Wed, 8 Apr 2009 21:41:49 +0000 (UTC)

> So what do browsers do about alternate stylesheet?

They treat the presence of the keyword "alternate" as a modifier to the 
keyword "stylesheet", and ignore the keyword "alternate" for the purposes 
of creating links for link toolbars and so forth is "stylesheet" is also 
present.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Apr 2009 09:40:00 +1000

On 09/04/2009, at 4:37 AM, Ian Hickson wrote:
> [snip]

Making this explicit shouldn't present a problem. What's the preferred  
precedence in HTML5?

> model so that you can set favicons from Link headers also, then we'd  

Yet again, the draft allows content-specific extensions like media.

Is there an argument that 'media' is generic to all links, and is  
there a content-neutral way to describe it? If so, we can get it in  
there...

> Tentative. (The section is marked "last call for comments".)

Ack. I'll make a comment.

> underlying model can't describe it, though.

I think we're hearing more than that -- that it's bad practice to make  
relations behave like this, because it's tying them to a very specific  
syntax, and making them operate in a way that's very specific to the  
relation type.

>> in

Interesting; <http://www.w3.org/TR/REC-html40/present/styles.html#h-14.3.2 
 > doesn't sanction the second form, so browsers are already taking  
license with the (very weakly implied) model in HTML4.

>> same

Sure, but what's the actual use case, beyond being able to mark them up?

> express in a common data model.

No, it works just fine; you just need to define the context of the  
link as the paragraph.

> know if what we have now is the best way to do it.

OK. If you can show us why they want it, or put us in touch with them,  
it would be most helpful.

Cheers,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 8 Apr 2009 18:26:56 -0700

> Making this explicit shouldn't present a problem. What's the preferred

Are you referring to the order of precedence between HTTP Link and HTML
Link?
 
> there a content-neutral way to describe it? If so, we can get it in

I think Link is getting ready to ship, and don't think we should extend it
at this point. If someone wants a media extension, I would suggest writing a
new I-D for it.

EHL

---

From: Phil Archer <[email-masked]>
Date: Thu, 09 Apr 2009 09:43:13 +0100

Eran Hammer-Lahav wrote:
[..]

> at this point. If someone wants a media extension, I would suggest writing a

Agreed. I'll look into this a bit and see what the feeling is. The main 
demand will be from the mobile community in which I'm immersed in my W3C 
role now.

Phil

-- 

Phil Archer

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Apr 2009 10:33:36 +1000

Just a heads-up;

I'm going to release a new draft of Link soon, and document my  
preferred approach: grandfathering in "alternate stylesheet" as  
meaningful when they're serialised together, but discouraging other  
such special relationships (e.g., "up up").

I'll then take that to the HTML5 WG as an issue to see if we can come  
to some agreement about it.

Cheers,

On 08/04/2009, at 9:10 AM, Mark Nottingham wrote:

> noting that there may be more than one list of relation types  
> between any context and target.
>
> 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).
>
> Also, the HTML5 folks plan to use this model for other purposes  
> (e.g., "up up" to indicate a parent of a parent).
>
> The alternative is to say that the 'stylesheet alternate'  
> combination isn't specific to how it's serialised, but is tied to  
> the occurrence of the links. I.e., when both relations are present  
> in links between the same resources, these special semantics take  
> affect. However, this does seem to directly conflict with the HTML4  
> language (see link above), so I don't think doing so is viable.
>
> Comments?
>
> --