Onboarding people

[jviereck]

Use this issue to express your interest to this project. I am than happy to give admin rights to anyone that wants to help out with this idea.

[ghost]

I see, thanks! I should have taken a closer look at react-style's functionality but other things have had my attention. I must have completely missed the foo: {} functionality somehow, which I agree is the best direction rather than SASS/LESS. I was actually planning on going the JS-only route as you described (no actual usage of SASS/LESS), but they do include certain useful functions, so that link is definitely helpful, and by the looks of it, should be something to keep in mind when creating APIs like this one.

[ghost]

Actually upon another review, I didn't miss the foo: {} functionality, but I don't think it results in the BEM style classes that I'm wanting. Or does it (or does the webpack plugin)? That was the other thing I was going to take away from react-in-style: the ability to explicitly define the resulting class name (and/or some prefix/suffix), but I agree with @dmitry that custom tags are definitely not the way to go.

[SanderSpies]

@timbur for example:

StyleSheet.create({
   foo: {
     backgroundColor: 'green'
   }
})

will result in .foo_a when not using NODE_ENV=production. And when using NODE_ENV=production it will result in only .a.

Btw: the a part is what makes the className unique.

[felixakiragreen]

Is there a consensus as to whether the direction is towards inline styles, compiling CSS, or a hybrid?

[ghost]

@dubert Compiled CSS is the way to go for 99% of use cases, but a hybrid is necessary for maximum flexibility.

@SanderSpies So when you have different states of foo, does the className essentially become .foo_a--some-state (or .a--b or .x) in production? And as for child selectors (e.g., .Foo_a__some-child), I described some possibilities as per your response to my issue at react-style. I think it may be relevant to this discussion so you all can see here: https://github.com/js-next/react-style/issues/108#issuecomment-93428104

[dmitry]

@dubert I agree with @timbur. For the most cases compiled CSS will be enough, but to engage most people to VirtualCSS it might be good to provide posibility to have inline styles too.

Look one of the BEM implementation`s in react.js: https://github.com/albburtsev/bem-cn

[kof]

leaving you guys, not interested in yet another static css generation tool.

[ghost]

@kof I don't think that's the goal. But I do think it's necessary for it to be possible (and easy).

[kof]

Yet I am against generating static css at all, as I tried to express already.

[ianobermiller]

@kof I am more in your camp, there. You will probably be interested in Radium, and my WIP pull request to simplify the syntax in particular.

I think it is great that so many people in the community are interested in solving styles for React components, different approaches are certainly welcome!

[ghost]

@kof Maybe @jviereck can clarify, but my understanding is that the goal here is to provide something that other libraries can use as a base, and it may not even be a tangible library itself, possibly somewhat of a pattern like Flux. "Compiled" doesn't mean "static" (at least not in this context). I checked out jss (I'm liking it a lot) and it looks like most if not all of its functionality aligns with what we're discussing here.

[jviereck]

At this point I think it is good to summarize what I think the goals and non-goals of VirtualCSS should be. Please let me know if you disagree with any of the following points.

Goals

1. Ability to declare CSS styles in a way that a static CSS file can be produce during build time on the server.
2. Support the full feature when declaring CSS styles except cascading. That means in particular support pseudo selectors like :hover and media queries.
3. Support functions in the style declarations (see the createSimpleButton example above). This is in particular important to support CSS preprocessors similar to SASS on top of VirtualCSS but I also see value for pure CSS-in-JS solutions (e.g. a function for gradients that then will emit style definitions for gradients with all the vendor prefixes).
4. Ability to extend/overwrite style definitions. E.g. create a static substyle of "Button" called "BigButton" that is an enlarged version of "Button"
5. Ability to optimize the static CSS by rewriting the declared styles at build time.

Non-Goals

1. Do not support generation of inline styles. The problem is that by using inline styles covering the full feature set of CSS (e.g. pseudo selectors) is non trivial. As the react-style project shows, it is doable, so maybe a future version of VirtualCSS can work together with react-style to support inline styles. But for now to focus the scope of the VirtualCSS project I doubt it is a good idea to support both inline styles and static css.
2. Provide high level APIs to developers to interact with VirtualCSS. Developers should not interact with VirtualCSS directly but use a different library that builds on top of VirtualCSS and talks to the lower bits provided by VirtualCSS. This way VirtualCSS can concentrate on the essential parts and don't have to deal with user ergonomics.

---

With this, yes, @kof and @ianobermiller I think the goals of VirtualCSS is not aligned with what you are looking for, which I can understand. As @ianobermiller wrote it:

I think it is great that so many people in the community are interested in solving styles for React components, different approaches are certainly welcome!

I couldn't express my thinking better :) Personally I am very interested to follow along the development of Radium and jss and incorporate ideas/issues you face in the project here as well.

---

@dubert I agree with @timbur. For the most cases compiled CSS will be enough, but to engage most people to VirtualCSS it might be good to provide posibility to have inline styles too.

Engaging more people to VirtualCSS sounds great supporting both (inline styles and complied CSS) does not come for free. If someone wants to write code to support both, that's great. From my side I can only say I am very short on spare time at the moment and don't have the resources to move forward with supporting both. Also react-style supports inline-styles already and I think there is more value at this point to a completly/new approach at first and maybe later merge the two ideas.

[jviereck]

To the people that are interested to follow the project: Is there consensus on the goals and non-goals I mentioned above? If not please let me know, otherwise I assume this is what we move forward with and try to continue developing a first WIP in PR #4.

Thanks for all your comments and questions so far - they really helped to shape the project - keep them coming :)

[joeybaker]

I'd only modify point 2 to read:

Support the full feature when declaring CSS styles except cascading. That means in particular support pseudo selectors like :hover, media queries, and multiple declarations of the same style.

I think it's important to be able to do this:

display: -webkit-flex;
display: flex;

Especially since the prefixed version is a requirement on iOS right now.

[jviereck]

Thanks @joeybaker for the comment.

I have updated the README.md of the repo to include the goals and included your feedback there as well. Also, I've added a new point to the goals that is

Ability to provide developer tools extensions for browsers that makes tweeking the style definitions easy during development.

Let me know if you have any thoughts about this.

[martinandert]

I want to add myself to the list. I'm the author of React Inline: https://github.com/martinandert/react-inline

[nickdima]

@jviereck I think that a build steps that removes the style declarations from the final javascript bundles is also needed. Since the styles would be "exported" as a static css file they won't be needed anymore at runtime but will add to the total "weight" of your app. Makes sense?

[jviereck]

Doing a small hacking evening, I managed to get a minimal runtime system in PR #4 up and running that generates valid output for the inline style definitions - that is, if you run the webpack server you will get the same styling/visual output as the one in react-style for the provided exmaple. At the moment the system doesn't generate static CSS yet (it executes the Css-In-JS definitions and mounts the generated CSS in a style tag dynamically). Also, the mounted CSS is far from being optimized (there is a lot of redundancy in the content of the CSS selectors). The next step is to generate static CSS.

Let me know if you have any feedback or questions.

---

@nickdima, about your question, yes.

[jviereck]

Many people dislike the name "VirtualCSS' and therefore I've just opened issued #5 to brainstorm a better name. Any suggestions are highly welcome :)

[robinweser]

I'd also like to add myself to the list. I'm a CS student focusing on front-end and design. Unfortunately I'm in the midst of exams, but I'll read along soon.. (Those goals look quite well too!)

[evanstern]

I read your medium post and it was fascinating. This is an issue I've been tinkering with for a long time and I'd love to get involved in this project.

I'm working for a company that is looking into some way to allow styles to be defined within the components to which they apply and, so far, your proposal is the most attractive solution I've seen. If you'd like some help, please let me know (feel free to contact me via email: evanmicahstern@gmail.com).

[jviereck]

Since I started this projected many other "CSS in JS" solutions have emerged. Also, my personal interests have shifted. Therefore, I decided to mark this project/VirtualCss as "No Maintenance Intended" per commit 7bd5c27.

Thanks to all the comments on this project and the energy people put into it. Feel free to ping me in case you have any further questions.

Best regards,

Julian