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

91–100 of 143 posts

Re: Google recommends inlining small CSS

#91

Post by talmand »

mattmanser wrote: post #74
FroshKiller wrote: post #66

Earlier quoted context omitted.

In my experience--not that I'm a prolific JavaScript developer or anything--people tend to write out $(document).ready anyway because it makes their intent clearer. Personally, I have to do a little mental work every time I trip over the shortcut and prefer seeing $(document).ready.

Javascript is the wild west of styles, this isn't valid advice. $(function() {}) is a well known shortcut for jQuery. You might as well argue about whether or not to use the ternary operator or whether bootstrap's javascript is good or bad. It's just your opinion. In these days King Canute could have used javascript styles instead of the sea.

One is just as valid as the other. You are mistaking your preference as a standard.

Re: Google recommends inlining small CSS

#92

Post by acdha »

yoklov wrote: post #78
adevine wrote: post #73

Earlier quoted context omitted.

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...

What potential security vulnerability do inline styles have?

It's mostly the combination with other things: the ability to hide or position elements on the page is commonly exploited by XSS, malware, adware, etc. If someone can inject JS or HTML into the page, they can do things like put an opacity:0 submit button over the control the user thought they were clicking on.

Consider how this could work if Twitter made a mistake and gave you a way to inject improperly-sanitized HTML into a field which other people will see: you might be able to inject a follow or tweet button even if you didn't have enough access to completely rewrite the entire page or load arbitrary scripts. If you can style it to either look real or be positioned over a real button, the odds of someone clicking that go up dramatically.

Re: Google recommends inlining small CSS

#93

Post by talmand »

Lawtonfogle wrote: post #76
thirdsun wrote: post #53

Earlier quoted context omitted.

I agree with jdudek here. While I'd never use important, I usually have a lot of small utility classes like bold, italics, uppercase, truncated etc. I don't see what's wrong here - they come in handy when you need a one-time style alteration.

Is there an accessibility issue? You are using style to bold text, but bolding text is almost always a semantics issue of wanting to emphasize the text, not merely make it look different just for style reasons. So someone with a screen reader would have a far more difficult time getting the correct semantics from this page. Now I'm not saying one should go out of their way to ensure every single accessibility technol…

If you want to actually emphasize a bit of text then you should wrap it with the appropriate tags. Using font-weight is usually just a design decision for the visual, not necessarily to emphasize the text.

Re: Google recommends inlining small CSS

#94

Post by talmand »

pkorzeniewski wrote: post #37

I remember a CSS class in some enterprise software I was working on several years ago: /* bold */ .bold { font-weight: bold !important; } It has became my favourite real-world example of CSS misusage :)

That totally depends on your CSS pattern.

But I think the comment was overkill.

Re: Google recommends inlining small CSS

#95

Post by [deleted] »

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…

[deleted]

Re: Google recommends inlining small CSS

#96

Post by dahart »

pkorzeniewski wrote: post #37

I remember a CSS class in some enterprise software I was working on several years ago: /* bold */ .bold { font-weight: bold !important; } It has became my favourite real-world example of CSS misusage :)

Others have mentioned this is not necessarily a mis-use. I'll add that what I see here is potentially an override style that can be toggled dynamically. In that case, this may be the right thing to do, the !important declaration lets this rule collide and win over conflicting font-weight rules without having to keep track of which order the conflicting rules were declared in; they might be in separate files.

The canonical .hide class I see many places, and use myself, has the exact same structure, and it is often better to do hiding this way than to toggle visibility or display, because it's a pain and error prone to toggle display directly on mixed display mode elements, e.g., inline-block, flexbox, etc., and visibility doesn't reflow.

So, don't be so sure this rule exemplifies mis-using css. It might, but without the context, it's pretty hard to draw that conclusion.

Re: Google recommends inlining small CSS

#97

Post by acdha »

johnsbrayton wrote: post #89

I agree that Google's recommendation here is a poor one in most cases. It would be better to do the following: 1. Have only one or two external CSS files per page. 2. Serve CSS compressed when possible. 3. Ensure that CSS does not require any server-side processing or compression, that the server just spits out a .css or .css.gz file when the CSS is requested. 4. Ensure that the CSS files are relatively small. 5. Ser…

The problem is basically telling whether your challenges are like Google's. An external link requires a separate request, possibly even separate DNS lookups, server connection, SSL negotiation, etc. and nothing will render until those complete.

If you're Google with a strong culture of web performance and have generally solved all the normal server issues with a globally-distributed network of edge servers, a 24x7 team of very talented engineers continuously monitoring and optimizing, etc. you might quite reasonably conclude that the biggest remaining area to improve page performance is chipping away at the long tail of users on high-latency connections, unreliable / flaky ISPs which might drop or delay requests for your render-blocking resources, etc.

The trick is realizing that relatively few people work at Google and most other places have not made the same investments to get to the point where this kind of micro-optimization is a net win versus the maintenance costs. Most sites tend to show easier problems - optimizing DNS, getting a CDN or using one better, reducing total transfer size, etc. – which are going to impact the user experience more than inlining some CSS.

This is particularly true as we rapidly head into an area where things like HTTP/2 are changing most of our optimization weights – e.g. packing things into CSS bundles is rapidly becoming an anti-pattern since it reduces the period where a cached resource is still valid.

Re: Google recommends inlining small CSS

#98

Post by kccqzy »

[deleted] wrote: post #95
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…

[deleted]

CSP has a directive called "form-action" that limits the URI in form submission. So at least you can only submit forms to known destinations.

Re: Google recommends inlining small CSS

#99

Post by lost_name »

yoz-y wrote: post #33

I do not understand this particular example. They replace 4 lines of external CSS + 1 line of loading by 1 line of internal CSS + 2 lines of tags + 11 lines of JavaScript which then asynchronously loads 3 lines of CSS. So we went from a blocking call and 5 lines of code to 17 lines and an async call. How is this in any way better than simply cramming the 4 lines of CSS internally? Maintenance will not be simpler beca…

The article is about optimizing the delivery of the CSS content, not about making it clear or concise or anything else.

So, the point of the example then is to optimize for the content that is delivered directly on the page. Note that the only style used in the page is '.blue' which is the only style left in the header (they additionally specify that you should do this for content above the fold). The javascript will fetch the rest of the style after the page has finished loading.

By loading only the immediately rendered styles, the entire page content finishes loading then the remaining styles are loaded. This is opposed to loading all of the styles, followed by the page content. Of course, when we're talking about a page that is around 1k in size either way it's not particular important.

Re: Google recommends inlining small CSS

#100

Post by kccqzy »

jnmandal wrote: post #77
eric_bullington wrote: post #35

Earlier quoted context omitted.

> ...I'm going to evolve my CSS, starting with inline styling, moving out to an inline style node in HEAD, then dynamically loading it from JS as in the Google example, and then finally using a class/series of classes. I'm sure it will load spectacularly fast, but that sounds like a maintenance nightmare. I spent a lot of effort on my "brochure" sites making sure that non-JS users will have a good experience (that in…

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...
Post reply on HN