- From: Nick Kew <nick@webthing.com>
- Date: Sun, 21 Oct 2001 20:51:45 +0100 (BST)
- To: Jim Ley <jim@jibbering.com>
- cc: <w3c-wai-er-ig@w3.org>
On Sun, 21 Oct 2001, Jim Ley wrote: > 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??? I was replying to Al - and since I don't know if Snufkin means anything to him, it seemed simpler to say 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) All I'm talking about is rendering <LINK> elements in a sensible manner, such as a toolbar (Mozilla makes this an option, and the installation default is off) or right-click menu. Of course some minority browsers have been doing that for years. > >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.) I think the metadata-in-body is a different issue. No, it wouldn't (normally) make sense to put an Earl report link in a BODY. > (I need to see some justification of why we're breaking backwards > compatibility on the ROLE/REL issue with that.) That's essentially my point too, but I'm shutting up now until I've read properly the references sbp has posted in this thread. -- Nick Kew Site Valet - the essential service for anyone with a website. <URL:http://valet.webthing.com/>
Received on Sunday, 21 October 2001 15:52:19 UTC