W3C home > Mailing lists > Public > www-international@w3.org > January to March 2014

Re: [css-syntax] CR publication, Encodings and @charset

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 8 Jan 2014 11:43:30 +0000
Message-ID: <CADnb78iYHAodw3CK1GP7NymSGpdqkm40WZYiGyxwn8-Hu9-76w@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style <www-style@w3.org>, WWW International <www-international@w3.org>
On Wed, Jan 8, 2014 at 11:15 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
> 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.

This text seems fine, modulo that utf-16 should be utf-16le and you
then want to reorder them to sort them.


>> Note: With an ASCII-incompatible encoding, the ASCII @charset byte
>> sequence itself would decode as garbage. This mimics HTML <meta>
>> behavior.

This new note seems fine. I would clarify ASCII-incompatible as
meaning utf-16be or utf-16le within the note as the term
ASCII-incompatible is not a normative thing and keep the original
normative text plus the clarification I mentioned above.


> By the way, do we want to use the environment (a.k.a. referring document’s)
> encoding if it’s ASCII-incompatible?

I checked this with Henri a month ago or so. We do. There's no risk in
it being "ASCII-incompatible".


-- 
http://annevankesteren.nl/
Received on Wednesday, 8 January 2014 11:43:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:36 UTC