Skip to content
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

Open
geelen opened this issue Jun 22, 2017 · 8 comments
Open

Autoprefixing (and other processing) #24

geelen opened this issue Jun 22, 2017 · 8 comments

Comments

@geelen
Copy link

geelen commented Jun 22, 2017

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?

@kof
Copy link
Member

kof commented Jun 22, 2017

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
Copy link
Author

geelen commented Jun 23, 2017

ICJS is kinda cool. But how about ISTF Interoperable Styling Transfer Format? Or S4F for Style Sheet Standard Serialisation Format 😜

@kof
Copy link
Member

kof commented Jun 23, 2017

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.

@mxstbr
Copy link

mxstbr commented Jun 23, 2017

Oooh I like ISTF!

@kof
Copy link
Member

kof commented Jun 23, 2017

Done.

@kof
Copy link
Member

kof commented Jun 23, 2017

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.

@okonet
Copy link
Member

okonet commented Jun 23, 2017

ISTF is cool!

@kitten
Copy link
Member

kitten commented Jun 26, 2017

@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

@cssinjs cssinjs deleted a comment from orlowang Oct 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants