- From: Florian Rivoal <florianr@opera.com>
- Date: Wed, 25 Jul 2012 12:26:01 +0200
- To: "www-style@w3.org" <www-style@w3.org>
For the value of CSSRule.cssText, Dom level 2 only said: "cssText of type DOMString The parsable textual representation of the rule." On the other hand, css-om, while not fully written, appears to try and be more specific. It says: "cssText of type DOMString The cssText attribute must return a serialization of the CSS rule." And the section on serialization (http://dev.w3.org/csswg/cssom/#serialize-a-css-rule) has (a stub of) specific instructions on how to serialize rules, including how much white space and what kind of white space there should be. I was wondering about that in the context of css3-conditionals, wondering what kind of indentation style (if any) in serialization we want to mandate, in general and for for nested things in particular. Given this: @media all { @support (width: 1px) { div { width: 1px } } } There are a lot of possible variations on the serialization, just tweaking whitespace. We could we break the line for @rules, style rules, or both. We can put opening braces on new lines, or at the end the previous line. We could indent with tabs or spaces, and if spaces, we can pick a different number of spaces per level of indentation, or not indent at all... Should we go into this? We certainly gain a little bit of interoperability by doing it, but I am not convinced it is that significant a gain, and the cost of specifying all this and adjusting implementations is definitely non trivial. If not, when defining serialization, we could simply say "token x, followed by white space, follow by token y..." where 'white space' is left implementation dependent. - Florian
Received on Wednesday, 25 July 2012 10:26:37 UTC