Jump to content


Web Site Design, Usability, SEO & Marketing Discussion and Support

  • Announcements

    • cre8pc

      20 Years! Cre8asiteforums 1998 - 2018   01/18/2018

      Cre8asiteforums In Its 20th Year In case you didn't know, Internet Marketing Ninjas released many of the online forums they had acquired, such as WebmasterWorld, SEOChat, several DevShed properties and these forums back to their founders. You will notice a new user interface for Cre8asiteforums, the software was upgraded, and it was moved to a new server.  Founder, Kim Krause Berg, who was retained as forums Admin when the forums were sold, is the hotel manager here, with the help of long-time member, "iamlost" as backup. Kim is shouldering the expenses of keeping the place going, so if you have any inclination towards making a donation or putting up a banner, she is most appreciative of your financial support. 

Inline Css Crazy

Recommended Posts

I needed to investigate inline CSS and went down the rabbit trail and am now silently screaming.


Things change so quickly, how does anyone stay on top of this stuff!


Google is teaching me...are there other resources?






If the external CSS resources are small, you can insert those directly into the HTML document, which is called inlining. Inlining small CSS in this way allows the browser to proceed with rendering the page. Keep in mind if the CSS file is large, completely inlining the CSS may cause PageSpeed Insights to warn that the above-the-fold portion of your page is too large via Prioritize Visible Content. In the case of a large CSS file, you will need to identify and inline the CSS necessary for rendering the above-the-fold content and defer loading the remaining styles until after the above-the-fold content.


Share this post

Link to post
Share on other sites

I disagree. Mostly, anyway.


Inline CSS, regardless of the size, needs to be loaded on every page load. A CSS file, if properly set up, is loaded on your first pageview and stays in your cache for at least the duration of your current visit to that site.


For me, the time to use inline CSS is for rare exceptions to a CSS rule and for pages that have style elements that are unique to that page and are unnecessary to have loaded on every page of the site. For example, maybe you have a calendar page on the site that has some unique styling to lay out the calendar and give it a certain look - you don't need that on every page, just the calendar page - so put it inline. Then again, if each day on the calendar loads another page that uses some of the same styling, then I'd make a separate smaller CSS file for those and only call it on that pages where that set of styles is necessary - again, because of caching.



  • Like 1

Share this post

Link to post
Share on other sites

I agree with Grumpas. There is no good reason to use inline CSS.

Share this post

Link to post
Share on other sites

Agreed with both of you but it seems we have been out voted by the folks at the Googleplex.

Share this post

Link to post
Share on other sites
but it seems we have been out voted by the folks at the Googleplex.



As usual. :morningcoffee:

Share this post

Link to post
Share on other sites

In the discussions I've been reading about this issue there is a common mistake being made: header or internal CSS aka

 <STYLE type="text/css"> H1 {border-width: 1; border: solid; text-align: center} </STYLE> 
is being called "inline" even by folks who have been around long enough to know better.


Actual inline CSS is inline with the target code:

<P style="font-size: 12pt; color: ">Aren't style sheets wonderful?
Note: both examples from W3C 14 Style Sheets


The original recommendation to help speed initial viewport rendering was to apply inline CSS to that part of the HTML/content that would show first allowing the viewer to read quicker while subsequent code loaded.


I saw the logic but considered it a bandaid covering the problem. That so many simply loaded the external style sheet into the head and mislabeled it inline simply adds incompetence to ignorance. Now instead of a bandaid they have covered their problem with a cast.


And will have even more work to do when they get around to switching to HTTP/2 ... just about everything folks have been doing to speed HTTP/1.1 is counterproductive in 2.


Getting basic terminology so wrong and so widely misinterpreting a suggested fix is truly mind blowing.

Share this post

Link to post
Share on other sites

Google is suggesting - and implementing, i.e. via AMP - a great many things that are actually NOT broad best practices. Unfortunately most Google fanbois are not sufficiently competent to know whether a suggestion should be applied.


Long ago I came to the conclusion that I should ignore what G said should be done, instead only giving consideration to what they said should not; even ignoring that half the time.

Share this post

Link to post
Share on other sites

Even using that strict definition it still makes sense, to me, to put a <P style> in the external CSS if it is the same through out.

It is the eternal problem of how to speed things up: throw more CPU/Bandwidth horsepower at it or optimise. Horsepower always wins since it just keep on growing.... and it costs less. So.... from an efficiency point of view it is easy to make the argument to throw more hp at it than optimise. Now you can get on to other things. Of course the best is to do both but you only have the first two options.

Now add in a maintenance factor. There will always be maintenance and it costs (I've switched to programming). Do you write state of the art code or simple stuff (which will be bigger)? Six to eight months (or more) down the road when the code needs to be looked at and changed/fixed/maintained you scratch your head and say "what am I doing here"? A lesser experienced person might just say duh? (or quoi?)


I'm thinking if then elseif then elseif then elseif sort of stuff and throw in a few NOTs into the mix.

Edited by bobbb

Share this post

Link to post
Share on other sites

Long long ago in webdev time it was agreed that separating structure (HTML), presentation (CSS), and behaviour (javascript) was best practice. Recently, as mentioned above it was suggested that putting a minimal amount of presentation back into structure would be beneficial for a narrow specific reason (initial viewport render speed, especially for mobile). As is often/usually the case, webdevs went overboard and many dumped all the CSS back into the structure albeit usually in the header rather than inline.

Given the way the web is moving it is an abused solution for a problem that won't exist in a couple of years. Sound familiar?

If you've been paying attention to my posts over the past many years I've been discussing site personalisation and context. What I've been testing for over 3-years and am slowly rolling out live is 180 degrees from stuffing stuff back together. Instead I'm not only separating structure, presentation, and behaviour BUT going one and a half further in that I'm separating content from the page structure plus making the sematics/structure itself vary such that a given URL becomes rather amorphous.

Currently many/most webdevs' format is: structure/semantics -> content -> presentation/behaviour.
I'm changing to: context -> content -> structure/semantics -> presentation/behaviour.

Yes, the SEs are rather ambivalent as publicly they prefer a static page; as with a blind person they have difficulties with frequent furniture rearranging. The room and the things in the room are simply assumed to have fixed positions...

Well, for the past deacde we as webdevs have had to adjust to the SEs' increasing personalisation such that query results vary by context... now they can accept the default page version understanding that it is not necessarily unique (so far so good) or become increasingly irrelevant to my sites and business.

What's good for the goose... :)

1. I am against stuffing back in what has been separated for good solid reasons, i.e. ease of change.
2. I am against applying a narrowly specific solution to the broadly general.
3. I am against adding to the misery of switching to http/2 with additional http/1.1 kludges.
But then iamlost.


Note: from the above comments I think we are generally in agreement. :) Cre8 FTW!

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now