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.

[jviereck]

I am interested (okay - you might have guess that - just for demo purpose ;) ).

[vjeux]

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]

Hey y'all, very interested in contributing. I work on Radium (https://github.com/FormidableLabs/radium).

[jlongster]

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]

@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.

[jlongster]

@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]

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)?

Other major concerns that I haven't listed above?

[SanderSpies]

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.

I like this idea a lot. It should solve a lot of issues most developers have with global CSS. I'm definitely on board, as the project's goals coincide with some things I'm working on. Components with compartmentalization is the future of the web, so it only makes sense that their styles are confined just the same and without any real performance hit.

Any actual code written for this yet? I have a few ideas that should allow changes to be made as usual via browsers' native CSS tools while updating the respective JSX, although a separate file would probably be less hacky.

[robertknight]

@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]

cc @kof

[alexlande]

/cc @ianobermiller

[ianobermiller]

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:

1. 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?
2. 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).

-- Thanks for the mention, @alexlande!

[boopathi]

Nice idea. I'm interested.

[SanderSpies]

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.