- From: Francois Daoust <fd@w3.org>
- Date: Mon, 03 May 2010 10:05:36 +0200
- To: Pierre Rudloff <tael67@gmail.com>
- CC: public-qa-dev@w3.org
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 sheet. 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: http://www.w3.org/TR/CSS21/syndata.html#charset 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 sheet. 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: http://www.w3.org/TR/mobile-bp/#ddc 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: http://www.w3.org/TR/2008/CR-css-mobile-20080801/ 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. Thanks, Francois.
Received on Monday, 3 May 2010 08:06:06 UTC