W3C home > Mailing lists > Public > www-style@w3.org > February 2004

Re: [CSS21] response to issue 115 (and 44)

From: Ernest Cline <ernestcline@mindspring.com>
Date: Sat, 21 Feb 2004 09:38:48 -0500
Message-ID: <410-220042621143848109@mindspring.com>
To: "Ian Hickson" <ian@hixie.ch>
Cc: "Bert Bos" <bert@w3.org>, "WWW Style" <www-style@w3.org>




> [Original Message]
> From: Ian Hickson <ian@hixie.ch>
> To: Ernest Cline <ernestcline@mindspring.com>
> Cc: Bert Bos <bert@w3.org>; WWW Style <www-style@w3.org>
> Date: 2/21/2004 4:59:07 AM
> Subject: Re: [CSS21] response to issue 115 (and 44)
>
> On Fri, 20 Feb 2004, Ernest Cline wrote:
> >
> > So is CESU-8 is to be implicitly prohibited from using a BOM,
> > unless identified as such by out-of-band info, since that would
> > cause it to be treated as UTF-8?  (I could live with that as
> > CESU-8 isn't really intended for transmission of data.)
>
> The CESU-8 specification makes it quite clear that the only way a UA
> should be able to end up using it is if it has been very explicitly given
> as the encoding. A BOM is not, IMHO, explicit.

But what about BOM followed by @charset CESU-8 ?
That to my mind is explicit.  Since CESU-8 uses the same BOM
as UTF-8 this could be considered by some to be a problem
since the algorithm as given calls for such a page to be treated as
UTF-8.  I personally wouldn't mind if that is what the standard calls
for, but if it does so, I think it should explicitly mention that is what is
going to happen in such a case, given that CESU-8 does have
semi-official Unicode status, since it is mentioned in a UTR.
Received on Saturday, 21 February 2004 09:38:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:26 GMT