- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Wed, 08 Jan 2014 11:15:31 +0000
- To: Anne van Kesteren <annevk@annevk.nl>, "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style <www-style@w3.org>, WWW International <www-international@w3.org>
On 08/01/2014 09:17, Anne van Kesteren wrote: > On Wed, Jan 8, 2014 at 1:13 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> This doesn't quite address their feedback. As currently written, >> Syntax doesn't allow UTF-16 *either*, unless you use a BOM for the >> Encoding Standard to pick up. You definitely can't use @charset to >> specify utf-16, at least as specified. > > And we should keep it that way :-) Just like <meta>, @charset should > only work for ASCII-compatible encodings, which means encodings other > than utf-16be and utf-16le (utf-16 as such is not a thing anymore per > Encoding). Ok. The current spec text is: > If the return value was utf-16 or utf-16be, use utf-8 as the fallback > encoding; if it was anything else except failure, use the return > value as the fallback encoding. > > Note: This mimics HTML <meta> behavior. How about changing this to: > If the return value is an ASCII-incompatible encoding (Note: i.e. > utf-16le or utf-16be), use utf-8 as the fallback encoding; if it was > anything else except failure, use the return value as the fallback > encoding. > > Note: With an ASCII-incompatible encoding, the ASCII @charset byte > sequence itself would decode as garbage. This mimics HTML <meta> > behavior. in order to clarify the intent? By the way, do we want to use the environment (a.k.a. referring document’s) encoding if it’s ASCII-incompatible? -- Simon Sapin
Received on Wednesday, 8 January 2014 11:15:57 UTC