W3C home > Mailing lists > Public > www-style@w3.org > July 2012

[css-om][css3-conditional] spaces, newlines and rule serialization

From: Florian Rivoal <florianr@opera.com>
Date: Wed, 25 Jul 2012 12:26:01 +0200
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <op.whzy9nyg4p7avi@localhost.localdomain>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:57 GMT