4 ms·

I agree, I'm not sure what postprocessor would even mean in this context.

kcorbitt 13y ago
I think they chose "post-process" based on the following feature: Taking plain CSS as an input also means you can use Myth to post-process anyone else's CSS, adding the browser support you need, without having to re-write their code in a completely different syntax. What distinguishes it from LESS or SASS or whatever is that the input has to be valid CSS, as well as the output. Their claim is that it makes your CSS act now like it will in the future once the version of the spec they're targeting has been fully adopted.
- lstamour 13y ago
  Or maybe they were thinking visual post-processing: http://en.wikipedia.org/wiki/Video_post-processing http://en.wikipedia.org/wiki/Video_post-processing
- stormcrowsx 13y ago
  To me they chose the wrong word, they are still preprocessing because current css engines don't accept future css. Therefore it must be preprocessed by Myth before its usable in the browser.
- ricardobeat 13y ago
  LESS, SASS and rework/stylus are all supersets of CSS, so they can too "post-process" anyone else's CSS.
  - amitu 13y ago
    That would be a noop with LESS/SASS unless the input CSS was not a "valid" CSS. This project will "enhance" "normal" CSS to take care of polyfill, which alone is a win. Take any CSS file you got, and it suddenly has all browser prefixes thanks to this tool. This is something LESS/SASS can not do.
    - ricardobeat 13y ago
      Styl(us) can. My point is that calling it a 'post-processor' is a misnomer.
darth_aardvark 13y ago
I think the idea is that, instead of writing x other style language (SASS, LESS, etc.) that is turned into css, you write css that turns into different css. This means you can use other SASS/LESS/etc... and myth together.
ollysb 13y ago
Preprocessor: non css => css (e.g. less, sass) Postprocessor: css => better css (e.g. myth, ?)
- CatMtKing 13y ago
  I think you mostly hit the mark, although wouldn't it be: future css => compatible css ?
  - deleted 13y ago
    [deleted]
XaspR8d 13y ago
The reading I think they are going for is that preprocessors generate CSS from something else, while this uses (the platonic ideal of "true") CSS and generates the shambled code that the browser needs. But I could be way off.

I think they chose "post-process" based on the following feature: Taking plain CSS as an input also means you can use Myth to post-process anyone else's CSS, adding the browser support you need, without having to re-write their code in a completely different syntax. What distinguishes it from LESS or SASS or whatever is that the input has to be valid CSS, as well as the output. Their claim is that it makes your CSS act now like it will in the future once the version of the spec they're targeting has been fully adopted.

lstamour 13y ago
Or maybe they were thinking visual post-processing: http://en.wikipedia.org/wiki/Video_post-processing http://en.wikipedia.org/wiki/Video_post-processing
stormcrowsx 13y ago
To me they chose the wrong word, they are still preprocessing because current css engines don't accept future css. Therefore it must be preprocessed by Myth before its usable in the browser.
ricardobeat 13y ago
LESS, SASS and rework/stylus are all supersets of CSS, so they can too "post-process" anyone else's CSS.
- amitu 13y ago
  That would be a noop with LESS/SASS unless the input CSS was not a "valid" CSS. This project will "enhance" "normal" CSS to take care of polyfill, which alone is a win. Take any CSS file you got, and it suddenly has all browser prefixes thanks to this tool. This is something LESS/SASS can not do.
  - ricardobeat 13y ago
    Styl(us) can. My point is that calling it a 'post-processor' is a misnomer.

darth_aardvark 13y ago

I think the idea is that, instead of writing x other style language (SASS, LESS, etc.) that is turned into css, you write css that turns into different css. This means you can use other SASS/LESS/etc... and myth together.

ollysb 13y ago

Preprocessor: non css => css (e.g. less, sass) Postprocessor: css => better css (e.g. myth, ?)

CatMtKing 13y ago
I think you mostly hit the mark, although wouldn't it be: future css => compatible css ?
- deleted 13y ago
  [deleted]

XaspR8d 13y ago

The reading I think they are going for is that preprocessors generate CSS from something else, while this uses (the platonic ideal of "true") CSS and generates the shambled code that the browser needs. But I could be way off.