- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Sat, 01 Feb 2014 08:39:25 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Zack Weinberg <zackw@panix.com>, Simon Pieters <simonp@opera.com>, www-style list <www-style@w3.org>, www International <www-international@w3.org>
On 31/01/2014 06:17, Leif Halvard Silli wrote: > Richard Ishida, Fri, 24 Jan 2014 18:23:56 +0000: >> On 24/01/2014 17:06, Anne van Kesteren wrote: > >> I spoke with someone this week who works for a company where 100s of >> developers are still not using UTF-8 due to legacy code and corporate >> policy issues. They're working to change that, but it takes a while >> to turn the ship around. > > Then, for such situations, it could perhaps be of help knowing that > they could start their switch to UTF-8 by switching the CSS to UTF-8 > first and that @charset could be of help for that, since the @charset > "UTF-8" would make the CSS work even if the CSS makes use of non-ASCII > selectors. > > HTML(5) permits <meta charset="UTF-8"/> in XHTML, as long as it > specifies "UTF-8". And it seems like not recommending @charset in CSS, > except when it says "UTF-8", could be a similarly decent rule. Hi, Tab recently added a note at the end of the section that I think covers this scenario. http://dev.w3.org/csswg/css-syntax/#input-byte-stream > If neither of these options are available, authors should begin the > stylesheet with a UTF-8 BOM or the exact characters @charset > "utf-8";. Also, this sounds like a special enough case that we can afford to teach people to use the exact byte sequence without relaxing its syntax requirements. -- Simon Sapin
Received on Saturday, 1 February 2014 07:39:58 UTC