Re: CSS charset for mobile ?

Hi Pierre,

Charset encoding in CSS
If your ISP does not let you change the HTTP Content-Type sent for CSS 
files, there are two different cases:

1. if it does send an HTTP "charset" parameter in the Content-Type 
field, then there is basically nothing you can do, as this parameter 
takes precedence over any other way to express the encoding of the style 

2. if it does not send an HTTP "charset" parameter in the Content-Type 
field, then CSS Level 1 leaves you a bit in the dark. CSS Level 2.1 
notes different possibilities, in order:

Your choice is then:
  * the BOM: not recommended as some mobile browsers are just lost when 
they see that character
  * the @charset rule: do use it, even though it is not defined in CSS 
Level 1, see below.
  * the "charset" attribute in the HTML link element that references the 
style sheet. I would not rely on it, although, technically speaking, it 
would help you stick to CSS Level 1.
  * the charset of the document that references the style sheet
  * otherwise UTF-8.

In short, no surprise here, if there is no 'charset' parameter in the 
Content-Type field and you cannot add it, the '@charset "UTF-8"' 
directive is the recommended way... even though it's not available in 
CSS Level 1! Alternatively, you may simply restrict yourself to using 
only ASCII characters in the CSS content (which people usually do 
without much thinking about it) so that mobile browsers that only 
support UTF-8 can still parse and apply the styles defined in the style 

CSS Level 1 in mobileOK
mobileOK is based on the Mobile Web Best Practices, and in particular on 
the definition of the "Default Delivery Context" (DDC) that appears in 
the best practices:

The support for CSS Level 1 + @media + @import is defined there and 
should be understood as a minimal amount of support. In that regard, 
setting the charset in the Content-Type field is indeed better for it to 
be understood by (old) mobile user agents.

That said, I cannot find any reference to discussions about not 
including @charset in the list of exceptions, and my guess is that it 
more or less fell through the cracks at the time. In particular, I 
believe that it is supported by most mobile browsers, although I may be 
wrong. There is no plan to create a revision of these documents right 
now, but this looks like something to put on the table for discussion 
when it happens.

Pragmatically speaking, the best practices would have referenced CSS 
Mobile Profile 2.0 if it had been a stable W3C Recommendation at the 
time, but it was a draft when the best practices became stable and is 
still a W3C Candidate Recommendation today:

In short, when mobileOK says CSS Level 1, plus @media and @import, the 
intent is to say "CSS Mobile Profile 2.0", except that it cannot do so 
from a normative point of view.

Warning messages returned by the mobileOK Checker
In any case, please note that the mobileOK Checker only reports a 
*warning* when an included resource is served with a charset parameter 
in the Content-Type header different from UTF-8 or when it is served 
without charset parameter at all.

Warnings in mobileOK do not mean that something is wrong. They mean that 
something may be wrong, but that the mobileOK Checker is typically not 
smart enough to determine whether there is a real problem. Warnings are 
meant to draw the attention of Web authors about points of details that 
they may have missed and that may have unexpected consequences in the 
mobile world, because there are mobile browsers out there that really 
only have basic support for Web standards. Warnings do not prevent a Web 
page from being mobileOK.

If you add a @charset definition to your CSS style sheet, the mobileOK 
Checker will also report a warning because CSS allows to use properties 
or at-rules that are not defined in the spec. CSS parsers must simply 
ignore statements that they do not understand. In that case, the warning 
would alert you that the @charset directive may be ignored by some 
mobile browsers who may then try to parse the content as UTF-8, 
regardless of what the @charset directive says.


Received on Monday, 3 May 2010 08:06:06 UTC