- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 21 Jul 2008 16:35:55 +0000 (UTC)
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Maciej Stachowiak <mjs@apple.com>, Sunava Dutta <sunavad@windows.microsoft.com>, "annevk@opera.com" <annevk@opera.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Zhenbin Xu <Zhenbin.Xu@microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
On Mon, 21 Jul 2008, Jonas Sicking wrote: > > Hmm.. I'm confused. From your and Maciejs answer it sounds like the > algorithm doesn't specify what is valid, but what is parsed? What is the > difference? What a 'AC header validator' would complain about? The difference is the same as with the parsing. This is invalid: <b>x<i>y</b>z</i> ...but still has a defined parsing behaviour. Well similarly, "http://x/y<z" is invalid, but still has a defined parsing behaviour. > If so, that doesn't really buy much as far as forwards compatibility > goes. We have to be backwards compatible with what UAs accept, not what > validators accept. Right, the parsing behaviour defines what UAs accept, as far as I can tell. > However doing something like what Maciej suggests, of stopping the url > parser at the first whitespace character, sounds like it would solve the > forwards compat issue. Agreed. > However, if the HTML5 algorithm only considers the same URLs valid as > RFC 3986 does, is there a reason not to point directly to RFC 3986 > instead? Seems like there is no reason to have more relaxed error > handling here than needed? As you said, we have to be backwards compatible with what UAs accept, not what validators (and RFCs) accept. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 21 July 2008 16:37:05 UTC