W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > October 2001

Re: HTML friendly links to metainformation

From: Jim Ley <jim@jibbering.com>
Date: Sun, 21 Oct 2001 11:31:22 +0100
Message-ID: <00dd01c15a24$db169fa0$763c70c2@7020CT>
To: <w3c-wai-er-ig@w3.org>
Nick Kew:
>Yes they do. <LINK> support is gradually hitting the mainstream (recent
>Mozilla and MSIE variants have finally got around to doing something
>sensible). You'll lose that by putting it in a <BODY>.

MSIE??? If you mean my own suggestions of using various modifications to
IE, or is there some other support? If it's my techniques, then it doesn't
care about where they appear and serialises the DOM so it's still in
source position (so it suggests not error correction)  I've not got the
latest Mozilla to test it's support

>OTOH nothing in your example will be rendered by any existing browser -
>except the <LINK> if put in the <HEAD>.

Or in the body? and I don't see how A can be used in any case as the EARL
report isn't human readable (well there's meaning, but it's not
accessible.)  if it's audience is a machine, it does have to be hidden
from the user, but in a place where the user agents (of today, so we don't
need to wait until future UA's to use it.) and LINK in head does this, the
sub categorisation suggested by Al, also makes sense, as long as they
fallback to <LINK>

This makes sense, it will degrade so is still useful to current user
agents: (I don't like DIV being in HEAD, and I don't see how having this
outside the HEAD is helpful.)

<metadata>
 <meta keywords="accessibility, report">
 <meta scheme="EARL 1.3.7">
 <link role="meta" href="URI-reference_returning_EARL_doc"
    type="cturi:text/rdf;version=1.2">
</metadata>

(I need to see some justification of why we're breaking backwards
compatibility on the ROLE/REL issue with that.)

Jim.
Received on Sunday, 21 October 2001 07:37:15 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:10:39 GMT