[whatwg] link-types

[Matthew Thomas]

On 12 Sep, 2004, at 9:33 PM, Anne van Kesteren wrote:
>
> 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).

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.

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

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.

Therefore, assuming HTML5 doesn't deprecate non-stylesheet/icon rel=s  
altogether, I think it should define a way of determining which rel=s  
are intended for human consumption and which aren't (probably a  
whitelist, plus any <link> with a title= attribute, minus a blacklist).  
Then it should say something like the following:

"As with <a> elements, when <link> elements that use these  
relationships are present, UAs should render them. As with <a>  
elements, when <link> elements that use these relationships do not  
exist, UAs should not render them. UAs should not make <link> rendering  
any easier to hide than <a> rendering."

That sounds pretty elementary, but every UA that implements <link> as a  
toolbar gets this wrong.  
<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/ 
001273.html>

> Currently HTML 4.01[1] has defined a way of extending the link-types by
> using the PROFILE attribute on the HEAD element, this element points to
> a document which defines more link-type. In practice, this could be
> something as the XFN 1.1 meta data profile[2], developed by GMPG[3].  
> The problem is however that you don't know which link-type belongs to  
> which profile. If you develop a new profile which extends or redefines  
> a link-type, it becomes unclear which link-type should be used.

More importantly, IMO, if you use a relationship not defined in the  
HTML specification, it's unrealistic for a UA to render it except in a  
largely unnoticable manner (e.g. in an "Other" menu), since UAs can't  
be expected to turn metadata profiles into coherent UI designs  
on-the-fly. And LINKs using non-HTML-defined relationships are as  
useless to a general-purpose semantic processor (like Google, for  
example) as non-XHTML XML is.

> ...
> I found a document[5] which lists commonly used link-types. I believe  
> all of them should be included in the new specification.
> ...
> [5]<http://www.euronet.nl/~tekelenb/WWW/LINK/>

As far as I can see, that document doesn't list commonly used link  
types. It lists those shown in iCab's toolbar, but that's not  
necessarily the same thing. (Even if it was, the sheer number of  
distinct items iCab tries to show adds to their unnoticability, so it's  
not a good precedent.)

> ...

Agreed with your other points.

-- 
Matthew Thomas
http://mpt.net.nz/