cssinjs
Autoprefixing (and other processing)
Where does autoprefixing fit into this? Should it be part of the library (like SC), or something that happens on this "standard" data format (i.e. directly before injection into the DOM). What about other processing things?
Potentially, if we went the latter, we could build a converter from this format (do we have a name!?) to PostCSS for people who really wanted it, it would be slow but maybe some people would want to make that tradeoff. For anything core (like prefixing, rtl) we could write optimised transforms, for anything else people could write their own.
Is that opening up a pandora's box of customisation/complexity?
I think it should be up to the consumer library to decide when to vendor prefix, for e.g. at build time for SSR or at runtime for client rendered styles.
Because the need for prefixes strongly depend on the end user app requirements. I think there should be no vendor prefixes when publishing in "cssinjs standard", unless the author explicitly defined them in the code.
we could build a converter from this format
Sure, we can definitely build converters. But the standard doesn't need to know it, right? For e.g. converter can produce a postcss ast and feed it into autoprefixer when doing SSR directly.
do we have a name!?
My best take so far is "Interoperable CSSinJS standard". I don't know one good word for it, IJSS ? Why actually not simply "CSSinJS standard"? Do we need a better name for it? I mean there is a CSS standard, now there will be a "CSSinJS standard".
Is that opening up a pandora's box of customisation/complexity?
Lets see as we go what converters we will need, I think we will need a bunch. For the standard itself it doesn't mean any extra work. Just the tools around it.
ICJS is kinda cool. But how about ISTF Interoperable Styling Transfer Format? Or S4F for Style Sheet Standard Serialisation Format 😜
ISTF sounds good, I like the word "transfer" here, it makes it more clear what this format is for. So that people stop asking why we not just use an ast.
ISPF would be also good btw. Interoperable Styling Publishing Format, but I am fine with "Transfer" as well, because publishing is a form of transfer.
@geelen We should probably imitate Babel's approach here. We could write a parser like babylon, then a separate library for transforming and converting this format back to CSS. The second library could be a future effort, and is not 100% required if authors want to go their separate ways there.
But if we have a unified library for the generator, we can share transformations across implementations in the future
