mpt at myrealbox.com
Sun Sep 12 07:38:32 PDT 2004
On 12 Sep, 2004, at 9:33 PM, Anne van Kesteren wrote:
> We probably know the [list of link types] from HTML 4.01 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.
> Currently HTML 4.01 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, developed by GMPG.
> 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 which lists commonly used link-types. I believe
> all of them should be included in the new specification.
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.
More information about the whatwg