Rel="first" and "index" breaks specs and implementations

In the thread about "up" and "up up up", I started to wonder why Ian did 
not suggest using "top" instead of "up up up" - after all, for the 
example in the draft [0], the "up up up" could be replaced by "top", 
which has support in at least 3 implementations - namely Opera, 
Seamonkey and iCab. In fact, as "start" is understood in those 
implementations, he could even have used "start" - as 
Opera/iCab/Seamonkey consider "start" and "top" as synonyms.

Then I started to recheck what the draft says about this, and found that 
it defines "begin" and "start" as synonyms for "first"[1]. And 
"contents", "top" and "toc" as synonyms "index". [2] Thus in the draft, 
unlike in implementation, "top" and "start" land in different categories.

The latter breaks with the HTML 4[3] and XHTML[4] link relations, where 
"index" is independent from "contents"/"toc". HTML 4 and XHTML are here 
supported by implementations, namely iCab[5] and Opera, which both 
separate "index" from "content/toc". Seamonkey, which has built-ink 
<link@rel  support as well, consider "top" and "start" as synonyms which 
are different from both "index" and "first". Neither of 
Seamonkey/Opera/iCab implements "index" as the draft suggest. They all 
seem to give "index" an interpretation taken from indexes in books and 
the like. And they all also agree to have a independent "toc/content".

With regard to "first", then Seamonkey's support fort "start/top" is 
close to iCab which considers home/start/top as synonyms. That "start" 
and "home" are considered synonyms is supported by the notion of 
"startpage" as synonym for "homepage" in many languages including German 
(where iCab is made). Even Opera considers "home" and "start" as 
synonyms and different from "first". As for specifications, then I think 
it is in line with HTML 4 and XHTML then they do not know anything about 
"first".  We find that e.g. HTML 4 uses the word "first" when it 
describeds "start":

   "Refers to the first document in a collection of documents.
    This link type tells search engines which document is considered
    by the author to be the starting point of the collection."

For "first", then it seems like iCab/Opera/Seamonkey has given "first" a 
very literal meaning - namely "page 1", so to speak. If we compare with 
ordinary books, then the front/cover page would be the "start" page. To 
reach the "first" page you have to turn the cover. I don't think we gain 
anything by smashing "start page" and "first page" together. And I do 
not consider HTML 4/XHTML to disagree with iCab/Oper/Seamonkey's 
interpretation of "start".

For example,  a multipage article may have an ingress/teaser on the 
"start" page, while the actual "first" page of the article might be on 
another page.

iCab has documented the link relations and synonyms that it supports, 
and I find these to be very much in tune with HTML 4 and XHTML - I hope 
that HTML 5 will not end up much different [5]:

home, start, top
contents, toc
begin, first
prev, previous
end, last
find , search
author, made

In a summary, I suggest that HTML 5 draft starts to discern between 
"index" and "start", in order to respect HTML 4 and XHTML definitions. 
Further I recommend to separate "start" and "first" in order to support 
the predominant interpretation of what they mean. Finally, I recommend 
looking at UA implementations, namely Opera, Seamonkey and iCab and 
standardize their behavior. In fact, these three implementations are 
very similar - they only differ in the details (they do not support the 
exact same synonyms always - as seen above).

leif halvard silli

Received on Tuesday, 1 September 2009 01:20:07 UTC