Jump to content

Cre8asiteforums Internet Marketing
and Conversion Web Design


Photo

Inline Css Crazy


  • Please log in to reply
8 replies to this topic

#1 cre8pc

cre8pc

    Dream Catcher Forums Founder

  • Admin - Top Level
  • 14,816 posts

Posted 22 August 2016 - 12:26 PM

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?

 

 

 

 

Recommendations

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.

 

  •  


#2 Grumpus

Grumpus

    Honored One Who Served Moderator Alumni

  • Hall Of Fame
  • 6,612 posts

Posted 23 August 2016 - 06:42 AM

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.

 

G.



#3 wiser3

wiser3

    Mach 1 Member

  • 250 Posts Club
  • 282 posts

Posted 23 August 2016 - 10:58 PM

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



#4 bobbb

bobbb

    Sonic Boom Member

  • Hall Of Fame
  • 3,431 posts

Posted 24 August 2016 - 11:16 AM

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



#5 cre8pc

cre8pc

    Dream Catcher Forums Founder

  • Admin - Top Level
  • 14,816 posts

Posted 24 August 2016 - 11:32 AM

 but it seems we have been out voted by the folks at the Googleplex.

 

 

As usual.  :morningcoffee:



#6 iamlost

iamlost

    The Wind Master

  • Site Administrators
  • 5,513 posts

Posted 24 August 2016 - 11:48 AM

In the discussions I've been reading about this issue there is a common mistake being made: header or internal CSS aka
<HEAD>
 <STYLE type="text/css"> H1 {border-width: 1; border: solid; text-align: center} </STYLE> 
</HEAD>
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.

#7 iamlost

iamlost

    The Wind Master

  • Site Administrators
  • 5,513 posts

Posted 24 August 2016 - 11:56 AM

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.

#8 bobbb

bobbb

    Sonic Boom Member

  • Hall Of Fame
  • 3,431 posts

Posted 24 August 2016 - 01:50 PM

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, 24 August 2016 - 01:51 PM.


#9 iamlost

iamlost

    The Wind Master

  • Site Administrators
  • 5,513 posts

Posted 24 August 2016 - 08:37 PM

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

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





RSS Feed

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users