W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2004

[whatwg] link-types

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sun, 12 Sep 2004 21:01:05 +0300
Message-ID: <B7475F8C-04E5-11D9-BE91-003065B8CF0E@iki.fi>
On Sep 12, 2004, at 12:33, Anne van Kesteren wrote:

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

Agreed. I think the solution in Opera 7.5 is the best so far. It 
couples the link navigation with the address field so you can't hide 
the links without losing the address field. (I also think a keybinding 
for rel='next' is very useful and the lack of it in Firefox annoys me.)

> 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. Eric
> Scheid put up a (RFC) draft[4] regarding this issue, which is probably
> worth a look at when trying to solve this issue.

Are profiles really an issue that is worth looking at? Currently almost 
no one uses the profile attribute and, yet, the set of link types has 
been extended successfully without notable actual collision problems.

It seems to me the problem profiles solve is not a problem anyone is 
seriously having.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/
Received on Sunday, 12 September 2004 11:01:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC