I think this has been for a long time now and I expect to see everyone speak about how this is a bad recommendation. If the above-the-fold content can extracted with a gulp/grunt plugin and injected it gets even better. These are extreme measures needed for performance profits and anyone can choose to take them or simply ignore
Google recommends inlining small CSS
121–130 of 143 posts
Re: Google recommends inlining small CSS
#122I'd also like to throw this into the conversation:
Inline styles also prevent the user from overriding styles with a custom style sheet (think color blind people). This isn't necessarily against ADA/508 compliance, but it should be taken into consideration.
Re: Google recommends inlining small CSS
#123This 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…
Can I see please some examples of those JS-powered CSS components in the wild?
Re: Google recommends inlining small CSS
#124I'd also like to throw this into the conversation: Inline styles also prevent the user from overriding styles with a custom style sheet (think color blind people). This isn't necessarily against ADA/508 compliance, but it should be taken into consideration.
Important flagged CSS declarations trump those inline style ones anytime of the day. Also, limiting the options available to your end users without solid and good reasons is not a sound strategy as it may prove inconvenient for them and endanger the product's image.
Re: Google recommends inlining small CSS
#125This is the part that surprised me, > Further, inline CSS on HTML elements is blocked by default with Content Security Policy (CSP). I'm probably not up to date on this stuff, since I am not a web dev, but does this mean it's actually not possible to use `style=""` in your HTML elements any more? I thought it was not recommended, but more for organizational reasons, not security reasons. What is the reason?
Only if you have specified Content-Security-Policy headers in your response, without also specifying "unsafe-inline": http://www.html5rocks.com/en/tutorials/security/content-secu...
thank you so much for the link, I wasn't aware of this. It's a very easy way to help harden the webpage! (especially because I can do this via headers)
Re: Google recommends inlining small CSS
#126Earlier quoted context omitted.
What potential security vulnerability do inline styles have?
CSP is mainly a defense against arbitrary HTML getting injected into your website via poor validation, buggy scripts, etc. It's not a replacement for validation, but it's a failsafe when there's inevitably a bug. So the purpose of CSP is to block regular XSS like alert("XSS!"); , and anything that works similarly. This isn't saying that inline script tags are a security vulnerability per se, just that they're a tool…
... which means if you use something like React and do not inject HTML or use innerHTML or other eval-type junk then you don't actually need to worry much about allowing inline CSS or inline JavaScript.
Some of CSP's protections are there to protect crap web developers from blowing their feet off. Unfortunately there are enough of these on the web platform that having inline CSS and inline JavaScript off by default is a good idea. The 'unsafe' in 'unsafe-inline' means 'I know what I am doing.'
Re: Google recommends inlining small CSS
#127This 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 })
Re: Google recommends inlining small CSS
#128This 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…
You should see the examples on the page. It's more like
.blue{color:blue;}
Re: Google recommends inlining small CSS
#129This 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…
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.
Re: Google recommends inlining small CSS
#130This 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…
> 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.