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

On Wed, Jul 25, 2012 at 9:43 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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.
>

my preference would be one line only, no indentation; and that whitespace
must be in a minimized form, i.e., a single SPACE; if we leave whitespace
less specific, then the serialization becomes ambiguous; i have notice that
in various tests that read the value of cssText, a literal comparison is
made without further parsing, and such comparisons tend to be non-portable
given the current lack of specificity; for example, some browsers always
append a "; " to the end of a serialized declaration block, effectively
adding an empty declaration to the list; others do not; this type of
difference needs to be eliminated if possible;