Implement serialize() that preserves formatting and comments

[NV]

/* button.css */
.button {
    display: inline-block;

    text-align: right; /* fixes Opera */

    /* background-image defined in button-theme.css */
    background: no-repeat 100% -55px;
}

var css = CSSOM.parse(buttonCSS, {preserveFormatting: true})
css.cssRules[0].style.setProperty('display', 'inline');

css.toString()
-> ".button {display: inline; text-align: right; background: no-repeat 100% -55px}"

css.serialize()
-> "/* button.css */
.button {
    display: inline;

    text-align: right; /* fixes Opera */

    /* background-image defined in button-theme.css */
    background: no-repeat 100% -55px;
}"

I'm working on it.

[ghost]

This will be awesome, how do you plan on storing the whitespace?

Will it be possible to serialize specific rulesets, rules etc?

css.cssRules[0].serialize()                // => "h1 { \n  color:  red;\n\n  background: blue;\n}"
css.cssRules[0].style[0].serialize()       // => "color:  red;"
css.cssRules[0].style[0].value.serialize() // => "red"

This combined with a way to determine the index in the original text would be quite powerful. Each rule could contain an integer offset within it's parent, this way you could get a "live" index by summing all the previous sibling offsets and parent offsets:

css.cssRules[0].style[0].index()       // => Rule's index within the css text that was parsed
css.cssRules[0].style[0].value.index() // => Value's index within the css text that was parsed

[NV]

Yes, yes, and yes. I hope to release it on the next weekends.

[ghost]

Excellent! Will the whitespace be stored as separate nodes/objects?

I mentioned in a previous ticket adding support for Less-style nested rules which I can see now doesn't really belong in this project. What would be nice is a way to plug in addition features like this, it there likely to be an API with hooks allowing this kind of thing as I don't really fancy forking the project just for this?

Also lack of older IE support is a bit of an issue in my use case, would you accept a patch with a kind of ieCompat option? It would obviously have to get around getters and setters in another way.

[kizu]

Any news on this? Especially on comments — the CSSOM is used in Stylus' CSS to Stylus convertor and the lack of them in there is bad, 'cause we want them to stay there in the code after conversion :(