You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not really involved in the CSS aspect of React in any way, but I do have one comment: I think the name "VirtualCSS" is somewhat confusing honestly. Comparing it to the virtual DOM approach is somewhat misleading because the virtual DOM is tightly tied to the idea of optimizing performance by diffing and only touching the DOM when possible. "VirtualCSS" makes me expect a similar technique, but maybe that's just me.
I had not heard of JSS before but it seems like that might a better place to have a bunch of discussion because they already have a working tool that people use in production: https://github.com/jsstyles/react-jss
@jlongster, you made good points there - thanks for them!
I'm not really involved in the CSS aspect of React in any way, but I do have one comment: I think the name "VirtualCSS"
Without getting a too long naming debate started, I think VirtualCSS might be right as it is also about performance and optimising the style definitions. But I agree a different name might make more sense and I am happy for suggestions :)
I had not heard of JSS before but it seems like that might a better place to have a bunch of discussion
From my first look at JSS I get the feeling it fits better as a possible frontend that uses a VirtualCSS implementation for the low-level parts (CSS optimisation, mounting, ...) and a good idea is to see what APIs needs to be supported by a core library to get JSS supported.
Maybe let's wait before making such a move until I have made up my mind and wrote the promised reply to @gaearon about the differences between jss and my outlined idea in the blog post.
@jviereck Sounds great, absolutely don't take my words too seriously. Often the initial connotations with a new name wears off pretty quickly, so if others like it, I think it's fine. I look forward to seeing what you flesh this out into.
I'm interested. @jlongster that's a fair point about the VDOM and performance. I think of the 'virtual' aspect though as being more about decoupling the way you write your app from the environment it will run in - with performance being one of the benefits. The React README was recently changed to emphasize the abstraction over the diffing, but I'd guess that most people still think of it as being primarily about performance.
Off the top of my head, some of the different aspects to think about are:
How do you find out where styles are used? eg. Amenability to static analysis tools, or just relying on styles being limited to the component module where they are defined?
How are problems with specificity / class declaration order solved? Inline styles (React's StyleSheet.create()), CSS specificity tricks (react-style)? Mix of inline/classes (ts-style, this proposal?), leave it up to the developer?
Support for media queries, pseudo-selectors, keyframes, descendant selectors?
How are naming conflicts between styles defined in different modules avoided?
How easy is it to debug/tweak the resulting CSS in browser dev tools? Does that matter?
Are styles generated statically or dynamically?
Is usage of the library tied to inline styles with '
`, classes (JSS) or is that abstracted away?
Is the library React-specific or does it work with other libs? Does that matter?
How do you share common styling elements (eg. base styles / mixins etc.) between styles? Object.assign()? Custom mixin functionality?
Plain JS syntax (React inline styles, JSS, ts-style) or something akin to JSX (react-style has a mode for this)?
So React Style started last year, before all the CSS-in-JS madness really took off - there have already been a ton of discussions, and I've tried really hard to push everything into the right direction. Obviously, I'm very happy with the current direction and where it's going:
support both inline styles + compile to CSS: it's only a configuration setting.
we take the best from inline: the style prop order and bring it also to CSS classes
both CSS and inline styles are supported with one property: styles and that property makes sure the aforementioned order is correct (famous specificity hack)
we take the best (?) from CSS: media queries (supported), pseudo classes (next release) and bring it also to inline styles
we support CSS like syntax similar to that of the article (react-style-syntax project)
we optimize CSS classNames and make them unique (using a - ZZZ)
syntax is identical to React Native
auto-prefixing will arrive soonish also for inline styles + compile to CSS
Issues we do have:
animation, and I believe that something like React Magician is a good fit syntax wise - but more needs to be done in that area. I lack time for this though. CSS animation is not the right solution due to having no way to involve user feedback.
CSS sourcemaps - unfortunately this doesn't work due to how sourcemaps work (maybe inline it works, I haven't seen it working yet though)
A good website + tutorial
integrations might need more work
I think we nailed it pretty good, but yes I might have some bias ;-). So I'm totally up for discussions and exchange of ideas! Hope to steal some good ideas - and hope you guys do the same.
@SanderSpies - Adding support for the 'styles' attribute so that clients the styling can switch between or mix inline CSS and classes is useful but currently requires monkey-patching React.createElement(). Can you see a way to avoid this?
I've been experimenting with styling react components for a while now, and the current state of that is reflected in Cesium (see Button example usage), the core ideas of which I'm working on incorporating into Radium.
I'm not sure I buy all of your premises, I'd love if you could expand on (or defend) these:
The "nasty tricks" Radium has to do (the new syntax I'm working on is extremely lightweight)
Media queries - we have window.matchMedia for this, not a dealbreaker
Pseudo classes - not needed, we have the full flexibility of javascript. Since we are keeping style in the component, just add another element if you need one. Of course if you are interested in writing themeable components, your requirements might be a bit different.
Developer tools - while I agree that they are much nicer with normal css, I think you dismiss react-hot-loader too quickly; I've found my workflow to be more than adequate. One thing I do miss is by not having classnames is that it is harder to look at the Elements tab and scan for components. However, the React dev tools mitigate this for the most part, and it would be pretty easy to write a dev-only wrapper that puts the component name as a class on the top level element, for example, just to make debugging easier (not to be used for style, of course)
"CSS files can be loaded in parallel with other resources. This results in a faster page load" - how much does this matter? Is it worth the added build complexity? Empirically, is this even true? You can't style components until they are rendered anyway, and with inline styles, they both happen at once (plus you have no selector resolution)
Finally, and @robertknight has already brought this up, I think the two most difficult issues to solve when using classes are:
When you combine styles (say a base style and an override based on prop, e.g. button + special), how do you make sure the second (special, in this case) has higher precedence?
How do you handle overrides? After you create a generic component, you'll need to tweak the styles depending on where it is used (size, margin, positioning, etc). While this could be solved with diligence, like always using a wrapper and making the component fill its container, that'd be unnatural and hard to get right.
React Style handles this by creating these giant selectors, like .foo,.foo.foo1,.foo.foo1.foo2. I'm not sure this is any less "hacky" than going wholesale on inline-styles.
I've personally given up generating classes and actual CSS, and have instead turned my focus to emulating all the nice things we then forgo, like states (:hover, :focus, :active), media queries (which I've always found to be painful in CSS, but that's just my opinion), animations (Cesium actually uses an injected stylesheet for these, which I don't mind so much). This way, you solve the overriding/specificity issues once and for all, and always have the full power of JavaScript at your disposal (no difference between "static" and "dynamic" styles, for example).
Pure inline styles would be great, but not everyone is a fan of that. I'm also not convinced it's the right solution at the moment. I don't think that merging style objects every render, especially when animating, is desirable. CSS classes are ideal for immutable styles, inline styles are great for mutable styles. Doing as little as possible during render is important. React Style also has some work to do here, pseudo classes branch has already improved a bit on this. We could probably do better though.
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
Ability to declare CSS styles in a way that a static CSS file can be produce during build time on the server.
Support the full feature when declaring CSS styles except cascading. That means in particular support pseudo selectors like :hover and media queries.
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).
Ability to extend/overwrite style definitions. E.g. create a static substyle of "Button" called "BigButton" that is an enlarged version of "Button"
Ability to optimize the static CSS by rewriting the declared styles at build time.
Non-Goals
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.
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.
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 :)
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.
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.
@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?
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.
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!)
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).
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.
Activity
jviereck commentedon Mar 31, 2015
I am interested (okay - you might have guess that - just for demo purpose ;) ).
vjeux commentedon Mar 31, 2015
I'm interested in following the discussions but i've got a LOT of word to do on React Native right now, so don't expect much from my end :)
alexlande commentedon Mar 31, 2015
Hey y'all, very interested in contributing. I work on Radium (https://github.com/FormidableLabs/radium).
jlongster commentedon Mar 31, 2015
I'm not really involved in the CSS aspect of React in any way, but I do have one comment: I think the name "VirtualCSS" is somewhat confusing honestly. Comparing it to the virtual DOM approach is somewhat misleading because the virtual DOM is tightly tied to the idea of optimizing performance by diffing and only touching the DOM when possible. "VirtualCSS" makes me expect a similar technique, but maybe that's just me.
I had not heard of JSS before but it seems like that might a better place to have a bunch of discussion because they already have a working tool that people use in production: https://github.com/jsstyles/react-jss
jviereck commentedon Mar 31, 2015
@jlongster, you made good points there - thanks for them!
Without getting a too long naming debate started, I think VirtualCSS might be right as it is also about performance and optimising the style definitions. But I agree a different name might make more sense and I am happy for suggestions :)
From my first look at JSS I get the feeling it fits better as a possible frontend that uses a VirtualCSS implementation for the low-level parts (CSS optimisation, mounting, ...) and a good idea is to see what APIs needs to be supported by a core library to get JSS supported.
Maybe let's wait before making such a move until I have made up my mind and wrote the promised reply to @gaearon about the differences between jss and my outlined idea in the blog post.
jlongster commentedon Mar 31, 2015
@jviereck Sounds great, absolutely don't take my words too seriously. Often the initial connotations with a new name wears off pretty quickly, so if others like it, I think it's fine. I look forward to seeing what you flesh this out into.
robertknight commentedon Mar 31, 2015
I'm interested. @jlongster that's a fair point about the VDOM and performance. I think of the 'virtual' aspect though as being more about decoupling the way you write your app from the environment it will run in - with performance being one of the benefits. The React README was recently changed to emphasize the abstraction over the diffing, but I'd guess that most people still think of it as being primarily about performance.
Off the top of my head, some of the different aspects to think about are:
Other major concerns that I haven't listed above?
SanderSpies commentedon Mar 31, 2015
So React Style started last year, before all the CSS-in-JS madness really took off - there have already been a ton of discussions, and I've tried really hard to push everything into the right direction. Obviously, I'm very happy with the current direction and where it's going:
Issues we do have:
I think we nailed it pretty good, but yes I might have some bias ;-). So I'm totally up for discussions and exchange of ideas! Hope to steal some good ideas - and hope you guys do the same.
robertknight commentedon Apr 1, 2015
@SanderSpies - Adding support for the 'styles' attribute so that clients the styling can switch between or mix inline CSS and classes is useful but currently requires monkey-patching React.createElement(). Can you see a way to avoid this?
gaearon commentedon Apr 1, 2015
cc @kof
alexlande commentedon Apr 1, 2015
/cc @ianobermiller
ianobermiller commentedon Apr 2, 2015
I've been experimenting with styling react components for a while now, and the current state of that is reflected in Cesium (see Button example usage), the core ideas of which I'm working on incorporating into Radium.
I'm not sure I buy all of your premises, I'd love if you could expand on (or defend) these:
Finally, and @robertknight has already brought this up, I think the two most difficult issues to solve when using classes are:
React Style handles this by creating these giant selectors, like
.foo,.foo.foo1,.foo.foo1.foo2. I'm not sure this is any less "hacky" than going wholesale on inline-styles.I've personally given up generating classes and actual CSS, and have instead turned my focus to emulating all the nice things we then forgo, like states (:hover, :focus, :active), media queries (which I've always found to be painful in CSS, but that's just my opinion), animations (Cesium actually uses an injected stylesheet for these, which I don't mind so much). This way, you solve the overriding/specificity issues once and for all, and always have the full power of JavaScript at your disposal (no difference between "static" and "dynamic" styles, for example).
-- Thanks for the mention, @alexlande!
boopathi commentedon Apr 2, 2015
Nice idea. I'm interested.
SanderSpies commentedon Apr 2, 2015
Pure inline styles would be great, but not everyone is a fan of that. I'm also not convinced it's the right solution at the moment. I don't think that merging style objects every render, especially when animating, is desirable. CSS classes are ideal for immutable styles, inline styles are great for mutable styles. Doing as little as possible during render is important. React Style also has some work to do here, pseudo classes branch has already improved a bit on this. We could probably do better though.
45 remaining items
jviereck commentedon Apr 15, 2015
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
:hoverand media queries.createSimpleButtonexample 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 forgradientsthat then will emit style definitions for gradients with all the vendor prefixes).Non-Goals
react-styleproject shows, it is doable, so maybe a future version of VirtualCSS can work together withreact-styleto 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.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 couldn't express my thinking better :) Personally I am very interested to follow along the development of
Radiumandjssand incorporate ideas/issues you face in the project here as well.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-stylesupports 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 commentedon Apr 15, 2015
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 commentedon Apr 15, 2015
I'd only modify point 2 to read:
I think it's important to be able to do this:
Especially since the prefixed version is a requirement on iOS right now.
Update goals and add non-goals
jviereck commentedon Apr 16, 2015
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
Let me know if you have any thoughts about this.
martinandert commentedon Apr 17, 2015
I want to add myself to the list. I'm the author of React Inline: https://github.com/martinandert/react-inline
nickdima commentedon Apr 20, 2015
@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 commentedon Apr 21, 2015
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-stylefor 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 commentedon Apr 22, 2015
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 commentedon Jun 14, 2015
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 commentedon Jul 15, 2015
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 commentedon Dec 31, 2016
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
initial commit