W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: ISSUE-126: charset-vs-backslashes - Straw Poll for Objections

From: Philip Jägenstedt <philipj@opera.com>
Date: Sun, 06 Mar 2011 19:27:11 +0100
To: public-html@w3.org
Message-ID: <op.vrxpjlsisr6mfa@nog>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:25 GMT