Do we need better stringifier ?

[MoOx]

Parsing this

@keyframes kf {
  0% { opacity: 0 }
  25% { opacity: 0 } /* keep 0 to 25% of the timing to simulates a delay */
  100% { opacity: 1 }
}

Give that stringified

@keyframes kf {
  0% {
    opacity: 0;
  }

  25% {
    opacity: 0;
  }

  /* keep 0 to 25% of the timing to simulates a delay */
  100% {
    opacity: 1;
  }
}

This is weird.

What is the reason we just don't keep the code as is like postcss does ? Is there any ?

[conradz]

Is there any reason to keep the source format now that we have source maps? I pretty much never look at the generated source code, so IMO I don't care how it looks.

[MoOx]

I totally get the "i don't look so i don't care", but it just sounds stupid to me (stupid to change whitespace, I understand your point of view, since most of the time (98%) I never checkout output).
But in that way postcss is doing a better job at keeping author coding style.
I'm working on a playground for myth.io website (so people can try & get live output) & I would like to just keep author preferences to make minimal changes (like postcss does when you use autoprefixer for example).

[necolas]

it's a lot of changes for a relatively trivial use case though. it's not that this module intentionally changes whitespace, it's that preserving it is extra complexity.

[lydell]

It would not be enough to change the stringifier. The parser would need changes as well.

However, what's the point of doing things just like postcss? Then we could just use postcss instead, couldn't we?

Recently I've had a really hard time choosing between rework and postcss. Since postcss has been rewritten in JavaScript (no more CoffeeScript) I've started to lean to it ...

[MoOx]

@lydell I'll probably do the same so. That would involve rewriting all current plugins used by myth as postcss plugins. Ouch.