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.

[ghost]

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.

[ghost]

I think we need to support preprocessers. People have a need to reduce or change syntax or add features like autoprefix or use features from upcoming css spec via 4to3 cssnext.

[robertknight]

Aside from @SanderSpies comments about making render() as cheap as possible, I can also see other problems with emulating pseudo-selectors, media queries etc. in JS. For example, a recent talk at London React described the way that for the Tesco mobile shopping side, they render the site isomorphically and turn off JavaScript for old devices. CSS media queries could still work in such an environment, roll-your-own implementations in JS won't.

Additionally, the logic for implementing some pseudo-selectors is not as trivial as some people think and attempts to do the same with event listeners are likely to omit at least some of the native behaviors. I suspect it would be like the CSS equivalent of using hashbangs for URLs that lots of sites tried a few years ago.

[joeybaker]

I've been both excited and disappointed by the react's inline style approach. I'd love to be involved with this.

[felixakiragreen]

I'm very interested! I'm a designer & developer, been working with React for nearly a year and have recently been very involved in researching and using as many CSS in JS options and I can find.

[jviereck]

Hi there, thanks a lot for all the great responses and the time you put into writing them. I don't know exactly what's the best way to write a proper response (especially as I am getting a bit sick at the moment) - let’s hope the response is helpful to move the brainstorming further. In this response I try to explain why I want a system to be able to create a CSS file at the end and outline that to achieve this the way styles can be defined in an JS-To-CSS must be restricted. I give an outline what these restrictions could look like and I would love to hear back from you what you think about it.

It might be important to note that my experience with building web apps is biased towards large scale apps. In such environments you have different constraints compared to when building a smaller website for a client. For instance, using only inline styles like in Radium and relying on JS is a possible and in many cases a good practical solution. However, for large scale apps where you also have to cover the case of no-js-users not feasible. Therefore, any kind of solution that I am interested in building is about emitting a “static” CSS file at the end. Also the emitted CSS file should be optimised for file size. The part that takes care about creating this static CSS file and optmising it is what I referred to in my blog post as "VirtualCSS". The blog post talks about VirtualCSS in the context of React but if possible I would love to see it as a general library/framework that can be used by other frameworks and therefore works as a standalone component.

Because there is already a lot of CSS tooling I would love to see a soultion that enables to reuse the tools as much as it makes sense. Also, if there is a way to support preprocessors like SASS in any way, this is something I find worth considering given the big community and knowledge around these tools. For now I will use JS in my examples to declare the styles but I don't think this is a real limiting factor as converting a CSS-definition-string to the equivalent JS-object is doable. As of the feature set I think VirtualCSS should allow developers to write any kind of CSS as long as the CSS does not use cascading selectors or element selectors (like div { ...}).

To generate CSS from JS style definitions, the requirement is to scan the JS code and be able to determine all the style definitions and usages statically (at build time) without actually running the JS code. (This was not so much clear to me before @robertknight asked me about it). At first it seems this cannot be done by any of the existing CSS-In-JS libraries. For instance (using the react-style library here)

var StyleSheet = require('react-style');

var res = (function() {
  var i = math.random() * 100;
  while (i— > 0) {
    var ButtonStyles = StyleSheet.create({
      primary: {
        backgroundColor: 'rgb(0, 120, ' + i + ')',
        color: '#fff'
      }
    });
  }
  return ButtonStyles;
})();

module.exports = ButtonStyles;

makes it impossible to figure out the style definitions statically. But this looks like a completely made up case (on purpose :P ) and I expect most style definitions to look more along the lines of this:

var StyleSheet = require('react-style');

var ButtonStyles = StyleSheet.create({
  basic: {
    backgroundColor: 'rgb(0, 120, 120)',
    color: '#fff'
  }
}

module.exports = ButtonStyles;

That is the definition of a style happens at the top level of the module and there are no variables involved in the object passed to StyleSheet.create. This restriction makes the last listing relatively easy to analysis statically. Assuming there is then a “FancyButton” component that we want to implement, the implementation might look like this:

var StyleSheet = require('react-style');
var ButtonStyles = require('button-styles');

// Create a new set of styles that inherit from the previous ButtonStyles.
var FancyButtonStyles = StyleSheet.cascade(ButtonStyles, {
  basic: {
    fontWeight: 'bold'
  },
  'basic:hover': {
    fontSize: '20px'
  }
});

class FancyButton extends React.Component {
  render() {
    var colorStyle = this.props.colorStyle;
    return <div className={FancyButtonStyles.basic} style={colorStyle}>
              Lore Ipsum
            </div>
  }
}

This should also be possible to be analyised statically as well. Note that where the first idea with VirtualCSS was to be able to combine statically and dynamic changing styles this solution opts for a simpler setup: If the developer want to use dynamic changing styles, they have to do this by specifing inline styles themselfs. That doesn't look like a too bad limitation to me.

The restriction to disallow any values on the object passed to StyleSheet.create is very strong and to make it more flexible I think it should be possible to allow the use of constant variables that are defined at the top level of modules and pure function (hand waving definition: pure as in the sense they don't touch any other variables beside the ones passed to them by arguments or locally defined ones). With this extension the following becomes possible to write:

// ---
// In file: 'css-utils.js'

var createSimpleButton = function(baseColor) {
  return {
    backgroundColor: 'rgb(0, 120, 120)',
    color: baseColor
  };
}

module.exports = { createSimpleButton: createSimpleButton};

// ---
// In file 'button-styles.js'

var StyleSheet = require('react-style');
var cssUtils = rquire('css-utils');

var ButtonStyles = StyleSheet.create({
  basic: cssUtils.createSimpleButton('#fff');
}

module.exports = ButtonStyles;

This becomes a bit more complicated to analyse statically and involves running the cssUtils.createSimpleButton when building the final CSS file statically, but looks still doable to me.

As you can see, there are certain restrictions on how to define the style sheets and what to use as their arguments. The build system generating the CSS files (aka VirtualCSS) has to check if the developer plays by the restricted rules and if there is a violation raise an error to the user. Although I use react-style here in the examples, I could also imagine the analysis to work similar for jss, ts-style and rcss.

So the question to ask might be this: Do you think to build such a tool, that checks if the developer follows certain restrictions and if they do get the ability to generate an optimised CSS output is a good idea or do you think this is not useful in reality?

Please let me know what you think. Also not, that I emphasized in what I am interested in building. That doesn't mean there are other options and if you have different opinions, feel free to express them - I am more than happy to reconsider my decision making :)

[alexlande]

Have only started reading, but wanted to say one thing:

For instance, using only inline styles like in Radium and relying on JS is a possible and in many cases a good practical solution. However, for large scale apps where you also have to cover the case of no-js-users not feasible.

Supporting no-js + server-side rendering completely with Radium is 100% a goal/very important to me, and for that case something like VirtualCSS seems like the correct solution (to cover media queries, animations, and browser state pseudo-selectors like :hover specifically).

Have discussed that a little bit here: FormidableLabs/radium#53

I don't expect Radium to start using a style tag with generated classes for everything, but for those use cases I think it's the best solution.

[ghost]

@jviereck Regarding the optimization of the CSS file for size, it might be worth it (in advance, for testing) to put together something that generates large semi-random CSS files, both optimized versions and unoptimized versions, and then compare the size after GZIP compression. It may not even be necessary (or worth the time and effort) to add a bunch of complex optimization logic if GZIP is able to reduce it to a comparable size.

[jviereck]

if GZIP is able to reduce it to a comparable size.

@timbur good thought, glad you bring it up!!!

Are you interested in doing such an experiment and report back you findings?

For the architecture of VirtualCSS is made up of three more-or-less independent parts anyway:

1. Collecting the style definitions from the JS files, check invariants hold, generate the CSS by running all the embedded functions
2. Optimize the found CSS by merging selector rules
3. Minimize the resulting CSS using traditional CSS minimize techniques
4. Place the generated CSS class names at the appropriate points in the JS file (that is replace the style definitions with the computed CSS class names)

For a first version the step 2) can definitely be left out first and then later depending out the research finding added later if it makes sense.

[jviereck]

Supporting no-js + server-side rendering completely with Radium is 100% a goal/very important to me, and for that case something like VirtualCSS seems like the correct solution (to cover media queries, animations, and browser state pseudo-selectors like :hover specifically).

Have discussed that a little bit here: FormidableLabs/radium#53

@alexlande, thanks a lot for the clarification. I was under the impression that Radium sees JS as the solution to support media queries and pseudo classes.

The Issue you link looks very interesting and from what I've read goes into the same direction as what proposed above.

[ghost]

Also, @jviereck everything you mentioned in your last (long) comment is spot on. :)

Although, maybe I misunderstood what you were saying, but I'm not sure how I feel about the practicality of trying to analyze JS to extract the CSS.

I'm also not sure when I might have time to try out the optimization comparisons. I will most likely be contributing soon in some other form, however.

[ghost]

What about the idea to use template strings with a annotation about what css dialect is used.

var x = `@css4
  html: {
    color: #aaa;
  }
`;

var y = `@stylus
  html 
    color #aaa
`;

It should be possible to find such code in AST when Espree or similar libraries are used.

[kof]

Hi everybody, I am a maintainer of jss.

1. I was breaking my head by trying to allow static css out of js. Its a step backwards. Once you say you support this you loose all the beautiful runtime capabilities. Its even more important in large scale apps. Its good to have just one way styles are rendered.
   Basically I do support this indirectly in jss. You just need to use .toString method serverside. But you can't use most of plugins then.
2. jss vs. linline styles
   They are not competitors. I use them both for different purposes. JSS for everything static, inline for dynamic parts. Sometimes I take declarations from jss, modify them and use inline.
3. JSS tries to map 1:1 to css syntax but in json. I am not sure trying to support regular css but then to convert it to json during compilation will lead to an understandable code.

[boopathi]

The major trade-offs I experienced was between,

• How close do you want to keep the css to the component (or) how tightly should the css be bound to the component defined - as in React style, or in ember-component-css. This way I was able to create components which as a whole became reusable entities.

And

• Taking out the styles away from the component and declaring them separately. This way the styles would be shared between components rather than the component itself.

@fibric 👍 Relay is using template strings for specifying GraphQL queries as seen here - https://facebook.github.io/react/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html#whats-the-ltstorygt . So I guess, if we have something like this,

class Component extends React.Component { /*...*/ }
Stylesheet.create(Component, {
    styles: scss`
       /* ... */
    `
});

with tag specifying the css dialect, it could either be seen as an obstruction to using with Relay, or an advantage only. I'm not able to speculate about it. Also, as @robertknight mentioned, it might require monkey-patching React.createElement or an abstraction over the component definition which might lead to StylesPlusReact.createClass.

[SanderSpies]

@boopathi - React Style styling is not connected to a component. Styles can be defined anywhere, but should preferably be done at the module level.

[kof]

On the other hand if there is a strong issue with writing css in json. There might be a less preprocessor which will parse from components (like in your example) and converts them to json syntax which can be then used by jss.

[ghost]

@dmitry I am actually planning on using BEM style classes, although I didn't know that's what it's called! See my questions at https://github.com/js-next/react-style/issues/108#issuecomment-92885761. They're probably pretty newbie questions so maybe someone here can answer them for me.

The main things I wanted to take from react-in-style was the use of certain SASS functionality and pseudo classes. I see react-style has pseudo classes planned for its next release, but perhaps someone (@SanderSpies?) could provide an example for how it's expected to work.

[SanderSpies]

@timbur - we're going for the following syntax:

StyleSheet.create({
   foo: {
      backgroundColor: 'blue',
      ':hover': {
         backgroundColor: 'orange'
      }
   }
});

Most people seem to prefer this above other ways of defining pseudo classes.

Note that by default we only will support a subset of pseudo classes - as we want to maintain optimal support for both inline styles and compile to CSS.

Also moving to JS has an advantage - removing the extra layer of SASS or LESS. It's now just JavaScript which you are using already anyway. Adding SASS or LESS like syntax seems to me like going into the wrong direction.

As for using certain functions of LESS, if you go here: https://github.com/less/less.js/tree/master/lib/less/functions there's a whole bunch of functions that you can extract and use with any CSS-in-JS solution today (might need some changes here and there though).

[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