- From: Asmus Freytag <asmusf@ix.netcom.com>
- Date: Thu, 23 Jan 2014 09:32:12 -0800
- To: Simon Sapin <simon.sapin@exyr.org>, "Phillips, Addison" <addison@lab126.com>, Anne van Kesteren <annevk@annevk.nl>, Richard Ishida <ishida@w3.org>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>, Zack Weinberg <zackw@panix.com>, www-style list <www-style@w3.org>, www International <www-international@w3.org>
Presumably the @charset continues to exist because there are situations where it's needed. If the only conceivably situations are parsing of already existing stylesheets, then an argument that any change that affects the interpretation of any of these stylesheets is inherently risky and, in a strict sense would violate the backwards compatibility, does have some merit. (But remember, we are talking about making them behave as declared, not behave in an unusual new way.) On the other hand, if there are any situations where someone needs to create new stylesheets that are not in UTF-8 (for whatever reason) and if the intent is to support newly created stylesheet that are not UTF-8 in such cases, then having a syntax that is a "trap" is counter productive. Those for whom the support of new non-UTF-8 stylesheets is perpetuated would be likely to fail in correctly availing themselves of that feature, because they happen to fall into the trap. If the intent is to force people to use UTF-8, then the way to do that would be to disregard the @charset declaration for any stylesheet that uses a feature not present in legacy stylesheets. That would be a clean solution. Simply leaving a "gotcha" strikes me as suboptimal. It's not about "making it more convenient", but about making the process more robust, by separating the status of the feature (more or less deprecated) from accidents in syntax. A./
Received on Thursday, 23 January 2014 17:33:09 UTC