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

On Wed, Jul 25, 2012 at 3:26 AM, Florian Rivoal <florianr@opera.com> wrote:
> 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.

It would be interesting to see if there's any compat impact, but I
suspect just specifying "white space" will be good enough.  Definitely
easier than trying to define indenting.

~TJ

Received on Wednesday, 25 July 2012 15:44:08 UTC