[whatwg] link-types

[Anne van Kesteren]

>> We probably know the [list of link types] from HTML 4.01[1] and I  
>> think that list should be extended by WHATWG for HTML 5.0. Besides  
>> extending the current list of values,
> 
> Why does the list need extending? The current list already includes  
> redundant items. For example, having "chapter", "section", and  
> "subsection" has the same lack of scalability as the fixed <h1>~<h6>  
> hierarchy we have already tried to get away from. And the distinction  
> between "Start" and "Contents", if it was heeded at all, would  
> unnecessarily encourage the existence of splash pages (rather than  
> having a site's table of contents on its front page).

A yes, 'section' and 'subsection' are indeed a problem. They are quite 
useful though and I can't think of something that could replace them. 
'start' and 'contents' are different. 'start' defines where search 
engines should start indexing, typically at the root of the site, '/' 
and contents is the same as 'toc' or table of contents, which probably 
has a different URI.


> The presence of redundant items doesn't mean the list shouldn't be  
> extended, but it does mean good reasons should be provided for each new  
> item. Each addition complicates both the spec and its implementations.

Agreed. They should be specified with detail as well. So it is very 
clear where you should use them and where not.


>> ...
>> I also think that we should change "user agents may provide access to
>> linked documents through a navigation bar" to 'should', since they are
>> only useful if UAs do something with it.
> 
> Well, "do something with it" is not necessarily "provide access to" it;  
> that would be inappropriate for rel="stylesheet" and rel="icon". But in  
> general, yes, links are pretty useless if UAs don't expose them.

Agreed. (|rel="alternate stylesheet"| should have UI of course, but that 
is pretty obvious.)


> For <a rel>, it doesn't matter so much, since current UAs display the  
> link noticably and reliably anyway. But except for Lynx, current UAs  
> don't render <link> noticably and reliably, making it pretty useless.

It would be nice if the UA would have some kind of build in shortcuts 
for <a rel="next"> to name an example. If I read a document and press 
'ctrl+n' the UA would spider (of already has spidered and indexed) the 
document to look for all |rel="next"| and returns a list of possible 
locations. If there is only a single location the UA would take me there 
immediatly.

I guess such mechanisms should apply to both A and LINK elements.


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