Re: 3.7.4. The link element (Spec Review)

On Sun, 2 Sep 2007, Julian Reschke wrote:
> 
> below a few comments with respect to Section 3.7.4 
> (<http://www.w3.org/html/wg/html5/#the-link>):
> 
> "The destination of the link is given by the href attribute, which must 
> be present and must contain a URI (or IRI). If the href attribute is 
> absent, then the element does not define a link."
> 
> I find this kind of language very confusing to people who are strictly 
> interested in authoring compliant content, and not in the details how to 
> handle broken content. (Of course this applies to many other sections of 
> the spec as well).

Indeed. I think we will in due course provide an alternative style sheet 
that hides the UA conformance criteria, which may help with this.


> "The type of link indicated (the relationship) is given by the value of 
> the rel attribute, which must be present, and must have a value that is 
> an unordered set of space-separated tokens."
> 
> This reads funny; how can a single instance of a set be unordered? 
> Unordered with respect to what ordering? (yes, I understand what it is 
> intended to say, but then please just state that the ordering doesn't 
> carry any semantics).

What should I call the type, if not "unordered set of space-separated 
tokens"?


> "Two categories of links can be created using the link element."
> 
> I think other reviewers commented on this earlier. The way this 
> distinction is introduced is a bit confusing and may not be needed at 
> all.

Could you elaborate on what exactly is confusing? I'm not sure how to 
improve it, because I don't really know what is wrong.


> "One element can create multiple links (of which some might be external 
> resource links and some might be hyperlinks). "
> 
> How?

I've tried to clarify this; is it clear enough now?


> "If the attribute is omitted, then the UA must fetch the resource to 
> determine its type and thus determine if it supports (and can apply) 
> that external resource."
> 
> That reads as if the UA must fetch the resource, which of course it 
> doesn't have to. It could just ignore it as well, right?

I've tried to clarify it.


> "...then a compliant UA that supported only CSS style sheets would fetch 
> the A and C files, and skip the B file (since text/plain is not the MIME 
> type for CSS style sheets). For these two files, it would then check the 
> actual types returned by the UA. For those that are sent as text/css, it 
> would apply the styles, but for those labelled as text/plain, or any 
> other type, it would not."
> 
> I think this should say "...returned by the server". Otherwise I don't 
> understand :-)

Er, yes, fixed!


> "Some versions of HTTP defined a Link: header, to be processed like a 
> series of link elements. When processing links, those must be taken into 
> consideration as well. For the purposes of ordering, links defined by 
> HTTP headers must be assumed to come before any links in the document, 
> in the order that they were given in the HTTP entity header. Relative 
> URIs in these headers must be resolved according to the rules given in 
> HTTP, not relative to base URIs set by the document (e.g. using a base 
> element or xml:base attributes). [RFC2616] [RFC2068]"
> 
> I'm a bit concerned because the spec seems to step into the HTTP WG's 
> area. So is this implemented in today's user agents? If not, how did it 
> get in here? (you know, design principles and so on :-)

Yeah, it's implemented by at least Mozilla, and also, I believe, Opera. 
The above is actually actively trying to not step on the HTTPWG's toes, 
I'm just trying to make sure that there are no cracks between the two 
specs where something (e.g. the processing order) might slip through.


> If the HTML WG thinks that support for the "Link" header, defined in 
> RFC2068 and dropped from RFC2616, should be mandatory in HTML5 UAs, then 
> I strongly recommend raising this issue on <mailto:ietf-http-wg@w3.org>, 
> so that the header gets considered for re-inclusion into RFC2616bis.

Could I ask you to do these honours? It would be great to have someone who 
can coordinate with the HTTP WG.

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

Received on Friday, 9 May 2008 06:58:24 UTC