3 ms·

I hear this all the time but it's hard to giving up the C in CSS, cascading. With CSS you can define a style that applies to all buttons on the page. to replic

I hear this all the time but it's hard to giving up the C in CSS, cascading. With CSS you can define a style that applies to all buttons on the page. to replicate this with inline styles you have to do var styles = require("./styles/global"); // react stuff here var thisButton = Object.assign(styles.button, { custom: stuff }) And that's the absolute most simple case. Replicating even slightly more complex CSS concepts like :nth-child or descendant selectors must result in a lot of code.

sp332 11y ago
You should see the examples on the page. It's more like <head> <style> .blue{color:blue;} </style> </head> The critical styles needed to style the above-the-fold content are inlined and applied to the document immediately. The full small.css is loaded after initial painting of the page. Its styles are applied to the page once it finishes loading, without blocking the initial render of the critical content. https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery#example https://developers.google.com/speed/docs/insights/OptimizeCS...
lewisl9029 11y ago
Thanks for that insight. I haven't really given this enough of thought until now. For the use case you mentioned, I personally would try to create a styled button component and take custom styles as a prop to extend the default style. However, I think you can also just apply these kinds of globally cascading styles using a regular CSS stylesheet and handle only the state-dependent styles inline if you prefer that approach. As for features like nth-child, I don't see these being very difficult to implement, because you can easily map/reduce/filter your component tree with React since it's constructed from functional mappings of state data to begin with. nth-child would be as simple as applying/extending a style when (index + 1) % n === 0, for instance. Descendant selectors, I'm honestly not too sure about.
- purplerabbit 11y ago
  +1 for (s)css-ing as normal and adding state-dependent styles as necessary. I've yet to see a better approach.
ergothus 11y ago
> I hear this all the time but it's hard to giving up the C in CSS, cascading. Cascading in CSS is a bit of a love/hate relationship. Ultimately, it's like subclassing - neat idea, and great when it works, but often you hate life when a change at the top level cascades down and you didn't want it to. At my previous workplace, we moved to be all about semantic markup, and our CSS matched that. Class names were to be minimized, because the structure should tell you what you need to know. (a few classes were required, but usually just to identify different top level items). Cascading saw heavy use, and it was generally cleaner than the specificity battles we had in legacy code where semantics weren't used, but it required a lot of discipline. At my current workplace we're using React and BEM for CSS. Thus we avoid referencing element tags as much as possible and instead focus on very specific class names. BEM is, as far as I can tell, a means to avoid cascading as much as possible. Currently none of our CSS is inline. Not much discipline is required, but we have very little reuse (Sass provides some capability for reuse) I tend to prefer my previous workplace's version, but the two are making very different kinds of products with different needs (my former place is basically building a CMS product and then marketing the output, whereas the current is a few single page web apps). So in some scenarios cascading is an evil to be avoided, and in others it is a feature to exploit.
- zaphar 11y ago
  The hard part of the cascading in CSS for a page is that it is global in scope. In the current landscape of complex html/javascript applications this global nature tends to snowball. It's never safe to remove something so you have to fill your css with more and more complex rules and !important's to override the rest of the CSS on the page. At some point your CSS becomes impossible to manage and you are almost forced to start over again from scratch. After a couple of these times you start to curse the whole Global always on Cascading feature. This is why ShadowDom and the WebComponents stuff is such a breath of fresh air.
- jonesb6 11y ago
  I remember when a colleague first showed me BEM and I was really excited. Then came a deadline and any chance of optimizing our styles flew out the window. Complicated further by the fact that we have no designer on the team. I don't know if there is much room to optimize style sheet workflow when it is the lowest item on the totem poll in almost every situation.
sim0n 11y ago
Could be a little simpler if you're using an ES6 transpiler. import styles from './styles/global'; const thisButton = { ...styles.button, custom: stuff }; Also, nth-child and similar selectors aren't too bad, especially if you use a [1]helper library on top of React that lets you pass an array of styles to a component. All it then usually requires is adding a test against the iterator index when rendering a list of data. Something like: this.props.list.map((entry, index) => { const style = [styles.row, index % 2 === 0 && styles.even]; return (<div style={style}>{entry}</div>); }); A little bit of extra code but so much that I find it to be an issue. [1] https://github.com/FormidableLabs/radium https://github.com/FormidableLabs/radium

sp332 11y ago

You should see the examples on the page. It's more like <head> <style> .blue{color:blue;} </style> </head> The critical styles needed to style the above-the-fold content are inlined and applied to the document immediately. The full small.css is loaded after initial painting of the page. Its styles are applied to the page once it finishes loading, without blocking the initial render of the critical content. https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery#example https://developers.google.com/speed/docs/insights/OptimizeCS...

lewisl9029 11y ago

Thanks for that insight. I haven't really given this enough of thought until now. For the use case you mentioned, I personally would try to create a styled button component and take custom styles as a prop to extend the default style. However, I think you can also just apply these kinds of globally cascading styles using a regular CSS stylesheet and handle only the state-dependent styles inline if you prefer that approach. As for features like nth-child, I don't see these being very difficult to implement, because you can easily map/reduce/filter your component tree with React since it's constructed from functional mappings of state data to begin with. nth-child would be as simple as applying/extending a style when (index + 1) % n === 0, for instance. Descendant selectors, I'm honestly not too sure about.

purplerabbit 11y ago
+1 for (s)css-ing as normal and adding state-dependent styles as necessary. I've yet to see a better approach.

ergothus 11y ago

> I hear this all the time but it's hard to giving up the C in CSS, cascading. Cascading in CSS is a bit of a love/hate relationship. Ultimately, it's like subclassing - neat idea, and great when it works, but often you hate life when a change at the top level cascades down and you didn't want it to. At my previous workplace, we moved to be all about semantic markup, and our CSS matched that. Class names were to be minimized, because the structure should tell you what you need to know. (a few classes were required, but usually just to identify different top level items). Cascading saw heavy use, and it was generally cleaner than the specificity battles we had in legacy code where semantics weren't used, but it required a lot of discipline. At my current workplace we're using React and BEM for CSS. Thus we avoid referencing element tags as much as possible and instead focus on very specific class names. BEM is, as far as I can tell, a means to avoid cascading as much as possible. Currently none of our CSS is inline. Not much discipline is required, but we have very little reuse (Sass provides some capability for reuse) I tend to prefer my previous workplace's version, but the two are making very different kinds of products with different needs (my former place is basically building a CMS product and then marketing the output, whereas the current is a few single page web apps). So in some scenarios cascading is an evil to be avoided, and in others it is a feature to exploit.

zaphar 11y ago
The hard part of the cascading in CSS for a page is that it is global in scope. In the current landscape of complex html/javascript applications this global nature tends to snowball. It's never safe to remove something so you have to fill your css with more and more complex rules and !important's to override the rest of the CSS on the page. At some point your CSS becomes impossible to manage and you are almost forced to start over again from scratch. After a couple of these times you start to curse the whole Global always on Cascading feature. This is why ShadowDom and the WebComponents stuff is such a breath of fresh air.
jonesb6 11y ago
I remember when a colleague first showed me BEM and I was really excited. Then came a deadline and any chance of optimizing our styles flew out the window. Complicated further by the fact that we have no designer on the team. I don't know if there is much room to optimize style sheet workflow when it is the lowest item on the totem poll in almost every situation.

sim0n 11y ago

Could be a little simpler if you're using an ES6 transpiler. import styles from './styles/global'; const thisButton = { ...styles.button, custom: stuff }; Also, nth-child and similar selectors aren't too bad, especially if you use a [1]helper library on top of React that lets you pass an array of styles to a component. All it then usually requires is adding a test against the iterator index when rendering a list of data. Something like: this.props.list.map((entry, index) => { const style = [styles.row, index % 2 === 0 && styles.even]; return (<div style={style}>{entry}</div>); }); A little bit of extra code but so much that I find it to be an issue. [1] https://github.com/FormidableLabs/radium https://github.com/FormidableLabs/radium