- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 17 Nov 2010 11:34:11 +0100
- To: "David Singer" <singer@apple.com>, "Roy T. Fielding" <fielding@gbiv.com>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "Maciej Stachowiak" <mjs@apple.com>, "Jonas Sicking" <jonas@sicking.cc>, "Ian Hickson" <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>
On Wed, 17 Nov 2010 03:36:07 +0100, Roy T. Fielding <fielding@gbiv.com> wrote: > As mentioned before, there is no reason for any difference in syntax. > In fact, there is none in practice. The only reason that this is an > issue at all is because the draft contains incorrect statements and > unimplemented algorithms, apparently based on bugs in a single browser. > The solution is to remove the contradiction from the spec by restoring > the original text that defined meta and http-equiv. It is not true at all that browsers follow HTTP for <meta http-equiv>. E.g. <meta http-equiv=content-type content=text/xml> will not be honored. Not all HTTP headers supported at the HTTP layer are supported in <meta http-equiv> either. Only a couple. Furthermore, per HTML4 <meta http-equiv> was some preprocessing instruction for servers, that never got implemented. So restoring the original text -- assuming you are referring to HTML4 -- would not work either. -- Anne van Kesteren http://annevankesteren.nl/
Received on Wednesday, 17 November 2010 10:35:03 UTC