3.7.4. The link element (Spec Review)

Hi,

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

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

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

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

How?

"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?

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

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

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.

Best regards, Julian

Received on Sunday, 2 September 2007 18:37:40 UTC