-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autoprefixing (and other processing) #24
Comments
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.
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.
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".
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. |
|
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. |
Oooh I like ISTF! |
Done. |
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. |
ISTF is cool! |
@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 |
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?
The text was updated successfully, but these errors were encountered: