- From: Philip Jägenstedt <philipj@opera.com>
- Date: Sun, 06 Mar 2011 19:27:11 +0100
- To: public-html@w3.org
On Sun, 06 Mar 2011 18:43:21 +0100, Julian Reschke <julian.reschke@gmx.de> wrote: > On 06.03.2011 17:19, Philip Jägenstedt wrote: >> ... >>> My goals would be: >>> >>> - either align parsing with HTTP; *or* be clear that this is specific >>> to META, and consumers will need different parsing rules for the two >>> protocol elements. >>> >>> - in the latter case, rephrase and possibly move the text we're >>> discussing so it becomes crystal clear that this is error handling, >>> and *only* applies to <meta>. >>> >>> - make sure that field values that are syntactically valid in HTTP and >>> conforming in HTML have the same interpretation. >>> >>> - clarify how the two sets described above differ (for instance, if >>> backslash doesn't do the same thing as in quoted-string it should be >>> profiled out in HTML, this may already be the case). >> >> All of this seems reasonable, if done with restraint. For example, I >> don't think there's any point in handling backslash escaping, as no >> encoding names include characters that need escaping, right? >> ... > > It's correct it's not needed for any valid encoding name. Thus claiming > it MUST NOT be done is simply silly, right? In practice, it will never > be an issue for valid encoding names, and thus I was surprised by the > claim it is. The spec shouldn't say that ignoring backslash escapes is necessary for compat (it probably isn't), but handling them is more complicated than ignoring them, so I don't think there's any reason to align with HTTP on this point unless the whole algorithm (and implementations!) is change to exactly match HTTP on all points. -- Philip Jägenstedt Core Developer Opera Software
Received on Sunday, 6 March 2011 18:27:47 UTC