Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google recommends inlining small CSS

developers.google.com

Post reply on HN
Print view View original

131–140 of 143 posts

Re: Google recommends inlining small CSS

#131

Post by microcolonel »

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…

This article doesn't say to use `style` attributes inline. It's talking about inlining a `` element in the initial HTML page.

Re: Google recommends inlining small CSS

#132

Post by zaphar »

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…

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.

Re: Google recommends inlining small CSS

#133

Post by johnward »

geofft wrote: post #88
yoklov wrote: post #78

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

Would that block injection like Comcast does for bandwidth notifications? http://blog.ryankearney.com/2013/01/comcast-caught-intercept...

Re: Google recommends inlining small CSS

#134

Post by purplerabbit »

lewisl9029 wrote: post #129
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…

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

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

Re: Google recommends inlining small CSS

#135

Post by coverband »

OK, so this part is new to me:

Don't inline CSS attributes

Inlining CSS attributes on HTML elements (e.g., ) should be avoided where possible, as this often leads to unnecessary code duplication. Further, inline CSS on HTML elements is blocked by default with Content Security Policy (CSP).

How effective is this, really? If I can inline a CSS class, then I can inject any style on any HTML element even if I can't inline an attribute. Am I missing something here?

Re: Google recommends inlining small CSS

#136

Post by geofft »

api wrote: post #126
geofft wrote: post #88

Earlier quoted context omitted.

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

Right, in a perfect world, where all code deployed to production (including third-party libraries, legacy code that hasn't been touched in years, etc.) is free of security bugs, there's not much benefit to CSP.

Re: Google recommends inlining small CSS

#137

Post by lutusp »

coverband wrote: post #135

OK, so this part is new to me: Don't inline CSS attributes Inlining CSS attributes on HTML elements (e.g., ) should be avoided where possible, as this often leads to unnecessary code duplication. Further, inline CSS on HTML elements is blocked by default with Content Security Policy (CSP). How effective is this, really? If I can inline a CSS class, then I can inject any style on any HTML element even if I can't inlin…

Their point seems to be that inlining a class name means the class will only be defined once, but the case of an inlined style means the style information must be duplicated for each appearance. The style approach hits all the bad buttons -- the load is larger and slower, and its execution is slowed compared to a single class definition that's referred to multiple times.

Also, in the case of a defined class, you only need to change the class definition to change all the instances, rather than chasing down each explicit style instance.

The reasoning is only valid if the defined style is used more than once. If the style is unique, the argument doesn't hold up.

Re: Google recommends inlining small CSS

#138

Post by geofft »

johnward wrote: post #133
geofft wrote: post #88

Earlier quoted context omitted.

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…

Would that block injection like Comcast does for bandwidth notifications? http://blog.ryankearney.com/2013/01/comcast-caught-intercept...

No, because Comcast can just drop the CSP header from the HTTP stream (and you can believe that whatever developer has been ordered by management to implement this will quickly Google CSP, figure out that it's in their way, and drop the header).

The solution for network-level tampering and end-to-end authenticity is HTTPS. CSP just protects you against mistakes on the legitimate server.

Re: Google recommends inlining small CSS

#139

Post by noir_lord »

kccqzy wrote: post #100
jnmandal wrote: post #77

Earlier quoted context omitted.

Who are these non-JS users. Can you point to some statistics here? Using developer time on it seems more wasteful than trying to support old versions of IE.

See here for example: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...

Interesting but that was over 2 years ago and frankly even if it is still 1.1% since I write web applications not sites I'm not devoting any time to supporting people without JS.

Anything over 1% of the total dev time would be a poor RoI and frankly I'd sooner spend that time making things more accessible to screen readers and such (something that many web applications already do very poorly frankly).

Post reply on HN