- From: Zack Weinberg <zackw@panix.com>
- Date: Wed, 15 Jan 2014 11:08:48 -0500
- To: Anne van Kesteren <annevk@annevk.nl>, www-style list <www-style@w3.org>
On Wed, Jan 15, 2014 at 10:39 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Jan 15, 2014 at 3:22 PM, Richard Ishida <ishida@w3.org> wrote: > > I don't expect that the ordinary user of CSS will see any sophistication > > here - for them this is just an @-rule with some special characteristics > > that they need to get right if it's going to be effective. Why don't we just > > frame it that way in the spec? I think the benefit would be that (a) it's > > more straightforward, and (b) that it doesn't make it look like we suck > > (instead, those people who don't follow the special rules would just make > > pages that suck). > > The suckage cannot be removed. For compatibility it has to show up in > the object model. That's the whole problem. If that was not a > requirement we could skip the @charset bytes before parsing and treat > @charset rules as errors during parsing. That's true but I don't think it affects Richard's point regarding the exposition. Concretely, I think that section 8.2 would be better if it read something like this: The @charset rule is a reflection in the object model of the stylesheet's fallback encoding as determined by the algorithm in section 3.2. For compatibility's sake, an @charset rule will still appear in the object model, as-if parsed as a normal @-rule, even if it was not recognized as an encoding annotation by the algorithm in section 3.2 (for instance, if the @-sign was not the very first byte of the file, or if the word 'charset' was not entirely lowercase). However, @charset is invalid if it is not the very first top-level rule of a stylesheet. Moreover, adding, modifying, or deleting @charset rules via the CSSOM does not change the stylesheet's encoding. zw
Received on Wednesday, 15 January 2014 16:09:10 UTC