Hello, I wonder if subselectors are supported at the moment, since either of following syntax seems to throw syntax errors,

// Either 
const classes = ({
  'wrapper title': {
    margin: 1,
  }
})

// Or
const classes = ({
  'wrapper': {
    'title': {
      margin: 1,
    }
  }
})

Despite the second syntax being a SASS style and might not be the focus of this project, the first syntax actually belongs to CSS syntax and is quite useful, or actually irreplaceably necessary, in practice.

Suppose I have a below button style.

const styles = cssInJS({
  button: {
    width: 57,
    height: 57,
  },
})

I wanna make some css properties changes on the specific platform ios.

// case1)
const styles = cssInJS({
  button: {
    width: __IOS__ ? 40 : 57,
    height: 57,
  },
})

or wanna make changes in some classes,

// case2)
const styles = cssInJS({
  button: __IOS__ ? {
    width: 40,
    height: 57,
  } : {
    width: 57,
    height: 57,
  }
})

In the above examples, __IOS__ will be defined by webpack definePlugin, or It will be just normal variable.

Now, I have to add another class, like button_ios. but that way make a bundle with all classes even useless.

Do you have any plan about that feature supporting specific platform or theme style using condition statement? If you are not available now, It wouldn't be easy to do, but I cound make a PR.

For stuff like this in css

p:nth-of-type(1) {} p:nth-of-type(2) {} p:nth-of-type(3) {}

you basically need to create object with styling for every p and then attach it to that element? What's the best practice for this stuff?

I am wondering how one would go about setting a webpack dev environment up with this plugin? All my efforts have so far ended up with the styles of the last saved file overwriting the content of the bundled file.

To write dynamic style rules, now we can use FunctionExpression. This PR includes code change, some test code and added documentation. Also maybe two #9 #13 issues will be resolved by this PR. In my environment, all test case is passed.

Thanks.

This is an easy solution for #16. Any selector prefixed with $ is passed through to the generated CSS unchanged, and omitted in the resulting JS object.

This allows for comma-separated lists of selectors as well, such as { '$html, body, .button': {} }, which is pretty useful when defining global stylesheets.

An alternative solution would be to allow comma separated selectors everywhere, and requiring the prefixing of every selector individually ({ foo: {}, bar: {}, '$html, $body, $.button, foo, bar': {} }), but that would be a bigger change. Would love to hear thoughts on this.

It would be great if it were an escape hatch that would allow you to specify global style rules in JS as well, without having to use a separate syntax and pipeline for it.

There could be a special syntax that would opt a rule out of the selector rewriting. For example:

const globalStyles = cssInJS({
  '$body': {margin: 0},
  '$.small-caps': {textTransform: 'uppercase', fontSize: '0.9%'},
});

This would inject the following into the generated stylesheet:

body {margin: 0px}
.small-caps {text-transform: uppercase; font-size: 0.9%}

Recently, I'm working on the study about universal app like react-redux-universal-hot-example. As far as I know, in universal app, js files are loaded from different ways on each server and client side. Server side use the babel-register but client side use a bundle js file from webpack.

I have a question. Assuming that my code state haven't changed and use the same babelrc and options, regardless of the loading method(babel-register or webpack), does babel-plugin-css-in-js always guarantee to create the same class name? Even when I use compressClassName option, always guarantee it?

On this line of transformObjectExpressionIntoStyleSheetObject, the string value is checked to see if it is blank, which is currently matching all whitespace characters.

This disallows CSS that looks like this:

const stylesheet = cssInJS({
    default: {
        ':after': {
            content: " "    // There is a an empty space here so that the pseudo element renders
        }
    }
});

This is needed to do some styling things where content is not necessary for the pseudo element. A change that would fix this problem is simply:

    assert(val.length >= 1, 'string value cannot be blank');

instead of the isBlank call. This still prevents empty strings, but allows deliberately white space strings for CSS properties.

In react-inline it was possible to -t, --context <name=path> Add context item (require'd from path) as name and it was possible to define complex data structures in the required file etc but it appears this functionality has been removed here. With context defined in the .babelrc it's very inflexible. The use case I'm talking about is defining colors and using darken or lighten from color.js to define some more colors and then to use this in the style sheet definitions.

hello

I open a PR to discuss the support of nested selector (issue #24) I propose to handle global nesting using a parent prop in the specification object that is generated

Another way to support that is to it like in sass, using & char

cssInJS({
  foo: {
    '& .bar': {
      color: 'red'
    },
    '.bar &': {
      color: 'green'
    }
  }
})   

should generate

.foo .bar {
  color: red;
}
.bar .foo {
  color: green;
}

what do you prefer ? and given i'm pretty new to babel-plugin, is there a simpler solution ?

Currently babel-plugin-css-in-js support some nested rules using global selectors $, but they are very limited. I'm considering implementing nested rules for a universal case used in css pre-processes such as less and stylus. ( see the example below )

Component:

<div className={ st.box }>
  <div className={ st.hiddenBtn }/>
</div>

css-in-js

const st = cssInJS({
  box: {
    color: 'red',
  },

  hiddenBtn: {
    opacity: 0
  },

  // I want to follow Nested Rules
  'box:hover': {
    '.hiddenBtn': {
      opacity: 1,
    }
  }
})

babel:

const st = {
  box: 'dir_filename_js-styles-box',
  hiddenBtn: 'dir_filename_js-styles-hiddenBtn'
}

css

.dir_filename_js-styles-box {
  color: red;
}
.dir_filename_js-styles-hiddenBtn {
  opacity: 0;
}
.dir_filename_js-styles-box:hover .dir_filename_js-styles-hiddenBtn {
  opacity: 1;
}

[Image1]

In the First box in Image1 .box .hiddenBtn selector works well. But in the second box, .box .hiddenBtn selector will select all .hiddenBtn in the box. it might be a bug. (Because developers always can write .box .hiddenBtn selector instead of .box > .hiddenBtn selector, I don't mention about .box > .hiddenBtn selector here )

So I like the globally unique (randomized) className this plugin creates. Ever since I use this plugin, no matter how big the application was, there was no bug affected by the unintentional css rule. In order to keep this benefit, in nested rules, both box and hiddenBtn must be uniqued.

The global selector concept is great for theme, but I want to implement nested rules with a more universal concept that is used by other pre-processors that operate independently of the global selector nested rules.

Could I make some PR?

Hello,

I wonder if there is a way to do something like

cssInJS({
  Title: {
     color: "red"
  },
  '$.my-webfont Title: {
      font-family: webfont'
   }
})

When dealing with async font loading, a common technique is to use a font-observer like https://github.com/bramstein/fontfaceobserver and decorate the body tag with specific classes once font are available.

I love inline-css, but I don't like the mental gymnastics I need to do to convert css into a js object.

Could we add template literal support to allow us to write more vanilla css?

for example we could convert this:

const styles =  cssInJs({
  myButton: {
    border: 'solid 1px #ccc',
    backgroundColor: 'lightgray',

    ':hover': {
      borderColor: '#ddd',

      ':active': {
        borderColor: '#eee'
      }
    },

    '[disabled]': {
      opacity: .5,
    }
  },

  '@media only screen and (max-width: 480px)': {
    myButton: {
      borderWidth: 0
    }
  }
})

to

const styles =  cssInJs(`
  .myButton {
    border: solid 1px #ccc
    background-color: lightgray

    &:hover {
      border-color: #ddd

      &:active {
        border-color: #eee
      }
    }

    &[disabled] {
      opacity: .5
    }

    @media only screen and (max-width: 480px) {
      border-width: 0
    }
  }
`)

the output would be the same

const styles = {
  myButton: 'example_js_styles_button'
}

Single media query blocks in the source JS are currently split up into multiple blocks, one per selector, in the output CSS. This creates larger files and also potentially slows down browser rendering.

var x = cssInJS({
  foo: { margin: 10 },
  bar: { border: '2px solid black' },
  baz: { padding: '0 20px' },
  '@media only screen and (min-width: 500px)': {
    foo: { margin: 5 },
    bar: { border: '1px solid black' },
    baz: { padding: '0 10px' },
  }
});

becomes:

{
  .foo { margin: 10px }
  @media only screen and (min-width: 500px) {
    .foo { margin: 5px }
  }
  .bar { border: 2px solid black }
  @media only screen and (min-width: 500px) {
    .bar { border: 1px solid black }
  }
  .baz { padding: 0 20px }
  @media only screen and (min-width: 500px) {
    .baz { padding: 0 10px }
  }
}

instead of:

{
  .foo { margin: 10px }
  .bar { border: 2px solid black }
  .baz { padding: 0 20px }
  @media only screen and (min-width: 500px) {
    .foo { margin: 5px }
    .bar { border: 1px solid black }
    .baz { padding: 0 10px }
  }
}

All generated classes have the same specificity, but that complicates extending generic styles with custom styles for a specific theme.

Example:

// Button.jsx

import React from 'react';
import classNames from 'classnames';

const Button = ({ className, children }) => (<button className={classNames(styles.button, className)}>{children}</button>);

const styles = cssInJS({
  button: {
    color: 'blue';
  }
});

export default Button;

// CustomButton.jsx

import React from 'react';
import Button from 'Button';

const CustomButton = () => (<Button className={styles.customButton}>Click me!</Button>);

const styles = cssInJS({
  customButton: {
    color: 'green'
  }
});

export default CustomButton;

When I render CustomButton, the color: 'blue' still takes precedence over color: 'green', but I want my green theming to override the default styling. Is there a mechanism to do that without resorting to specificity hacks?