kof
commented
7 years ago 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.
geelen
mxstbr
okonet
kitten
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?