Google recommends inlining small CSS • Hacker News Board

Re: Google recommends inlining small CSS

#141

Post by jonesb6 » Tue, Jan 12, 2016, 11:25 PM UTC

ergothus wrote: post #130

MatthewPhillips wrote: post #127

Earlier quoted context omitted.

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 concept…

> 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 m…

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.

Re: Google recommends inlining small CSS

#142

Post by sim0n » Wed, Jan 13, 2016, 7:35 AM UTC

MatthewPhillips wrote: post #127

lewisl9029 wrote: post #115

This is probably not a very good general recommendation, but inline CSS actually makes quite a bit of sense to me when using React/Redux. Style is generally heavily interconnected with app state in modern web apps, so why not take advantage of a sophisticated state management system like Redux to declaratively manage your styles along with your state rather than adding/removing class names at runtime imperatively? Wi…

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 concept…

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 ({entry});
  });

A little bit of extra code but so much that I find it to be an issue.

[1] https://github.com/FormidableLabs/radium

Re: Google recommends inlining small CSS

#143

Post by jdmarantz » Wed, Jan 13, 2016, 1:22 PM UTC

pauly wrote: post #45

LoSboccacc wrote: post #41

that suggestion has been around for a while

yeah this is not new was a recommendation from https://developers.google.com/speed/pagespeed/insights/ which I thought was now depracated, so must have been around for a while. I think it's a recommendation of http://yellowlab.tools/ too which is great.

PageSpeed Insights (the analysis tool) is not deprecated. The optimization modules, mod_pagespeed and ngx_pagespeed, are also not deprecated.

What's deprecated is the hosted version of the optimization modules: PageSpeed Service: https://developers.google.com/speed/pagespeed/service/Deprec...