Our Dev team had been developing enterprise web page more than 2 years ago. We are curious to know what is the best way to write a contract for CSS usage. For example, if we have a COMP, how we agree on a contract so our developers and our designers agree and we don't have to go back.
Is there a tool that is available for this type of technical writing?
What is the threadhold of information put in the CSS versus on the HTML page? Some of our designers thing that some things should go directly into the HTML page. The general opinion is that everything that is style should go in a CSS and all else in the html.
Thanks for your input.
Well, if a webpage has very specific CSS just for itself, I guess there is an argument for defining the CSS in the page, otherwise I would always have the CSS in an external file.
Try to avoid or at least minimise in-lining the CSS as a style attribute on HTML elements though, that would be a PITA to manage.
Most pages will be template driven with standard content styles, and thus the CSS styles will be defined in external files.
One thing you might want to think about are the number of CSS files - some people suggest that you should minimise this to just one file site-wide or per-template (or area of the site) to minimise HTTP requests to the server and avoid delayed CSS loading and funny looking styling up until that point.
So this "contract for CSS usage" is actually just a coding standard for HTML pages?
I'm a purist, so for me HTML is for content and structure and CSS is for layout & styling. That's really what each of them were created for.
See CSS Zen Garden for a great example of this. Same HTML and hundreds of different layouts & designs.
What are the reasons your designers give for styling to be in the HTML?
Edit: The main goal here is consistency across the site, correct? The more you have abstracted away from each page, the fewer changes you'll have to make.
The idea that the HTML should merely encode information and not style is called semantic markup. It has several advantages that you already know about, like separation of concerns, and a few that you probably haven't thought about.
If you stick to the web standards and separate your style and content you will also end up with a page that is more accessible to those with disabilities.
If you need to have some things styled differently for a specific page, use separate CSS include file for that page only and then use a CSS class on the element you want to style.
If I have style that is for a one time, single use page, I will consider putting it in the header of that page, as my templating system allows for that.
However you should never use inline styles. Even if you do a page with a block in it for a one off. That way should you find that you "one time" item becomes a site wide style, you can simply move the CSS into the external CSS file and not edit the content.
Related
I am using google's audit and its tells me to remove unused CSS. I don't know if that css is for just that page or the whole site. The CSS might be there but not needed on that page but another page. Can someone tell me how this works?
It is telling you to remove unneeded CSS for that page.
However you have rightly pointed out the flaw in this suggestion as it only takes into account the current page (in it's initial state, obviously if you have a pop-out menu it won't gather the CSS for that).
Think of it more as a guideline of making sure you don't send the whole of Bootstrap just for the grid and column layouts for example.
Overall this is very difficult to fix, just use the coverage section on the performance tab in Developer tools to make sure you don't have any massively bloated CSS files and you will be fine.
Obviously reduce your unused CSS if it is easy to do so.
The only other thing that this point covers (in it's description, not as part of it's monitoring) is deferring non-essential CSS.
You should defer any Style Sheets that are not required for rendering 'above the fold' content (and inline your 'above the fold' CSS).
This point is also covered in 'Eliminate Render Blocking Resources' so I never quite get why they add the suggestion under this part as well but I have added it for completeness.
I find this rule was good at guiding me when designing a theme from the ground up as it made me seperate global CSS and page CSS more effectively.
Unless your site is scoring 98 / 100 (or you have hundreds of kilobytes of CSS) and you want to squeeze that last little bit of performance out of the site, simply minify and combine your CSS files and ignore this point.
Google's audit tool compares the entire stylesheet against the current URL and then tells you how much of it is actually not used by the browser.
The browser however still needs to download the entire file and then match all CSS selectors that apply to the current URL.
There are many ways to deal with this, but I find it the easiest to use an external API tool like Splitcss that does this for you on URL basis.
If you have only a few URL patterns in your web application, you can use some CLI tools like purgecss or uncss.
I'm conscientious when it comes to building web pages and my PageSpeed score always used to be around 90-100.
However in recent times it has been in the 80's for desktop and and 70's for mobile.
The main thing I struggle with is "Eliminate render-blocking CSS in above-the-fold content." I understand what this means and I understand how to fix it, but I cannot see that it is at all practical to do. If I'm understanding correctly:
You have to determine which CSS is required to render above the fold content and inline it - although this is a challenge it's probably the least of our worries compared with the following...
Your regular external CSS file will still render block, so you then have to defer this and load it via JavaScript instead. I find it kind of incredulous that we're relying on JavaScript to help style the page.
The inlined content won't be cached. And if your above the fold content is things like your header and navigation this is likely to be the above the fold content on every single page and thus the caching of the associated styles is surely a good thing.
If you have multiple break points in a responsive design, to avoid a flash of unstyled content you would presumably need to include various media queries within the inlined content. And then have the same media queries within your external CSS. And then if ever you change them, remember to change them in both places.
If your site is very basic then the inlined content might be quite small, but with a more complicated design the inlined content might be quite large. Besides which separating the two is a nightmare from a workflow point of view.
Am I the only one who feels bitter about this? Are there any examples out there where people are doing this effectively? (the only examples I've seen is where people inline their entire CSS which I don't believe is a good solution).
Is it conceivable Google will eventually drop this recommendation on the fact it does not appear practical for 99% of websites?
I think it is hard to determine which CSS is needed for above-the-fold content. See for example this article by Luke Wroblewski: There is no fold. Using inline CSS in the head might be a good idea for pages that have a huge CSS file because the perceived performance is improved, but in general I tend to keep my CSS file small and to compress&gzip it.
If your sites CSS is pretty small it might be better to inline the CSS because the HTTP Lookup, server response and sending the file might take more time than actually simply having the CSS in the head of the HTML.
I also agree with 3), that the CSS is not cached. Inlined CSS might be useful for a microsite or a landingpage to have a fast loading page to increase conversions, but it might have a bad influence on an online-shop because people are usually more "browsing" the page and therefore load different pages (and always need to load the inlined CSS).
There seem to be some discussions about whether CSS should be inlined. Also, Google PageSpeed gives you recommendations on how to make your page load faster, but its not said that they are always right. There are so many different websites, you should always see for every page what can be improved in which way. Sometimes it's not the inlined CSS that improves the page load but an image that is removed from the page.
After working with many CMSes and cutting up many HTML designs, when I saw SilverStripe's use of CSS, I was converted.
Essentially, that it would be a waste to change IDs in <div> tags depending upon the page you were on, and that changing the <body> tag's classes and ID would be an easier way of changing specific pages.
Such convictions were brought into question by a coworker during the following problem:
On a specific website, we have a variety of pages that are similar in structure. Some may include a special form, and some may not. All special forms should have a different background image depending upon the sub-section we are in.
Due to a claim that "additional lines of CSS slow down body.onLoads," my argument to code all background expectations in the CSS was rejected.
Can anybody cite evidence between a variety of cases? Cases including: Badly-coded CSS, and CSS well-coded, but having a variety of unused CSS on each page?
(And specifically speaking on my problem, can anybody explain my unease? I feel uncomfortable assuming images will be there and auto-generating Inline CSS (or header-section-based style tags) based upon a variable from a database.)
It's not going to matter (noticeably) unless your website is Gmail or YouTube (or is similarly CSS heavy).
Google has some recommendations in their Page Speed guide:
http://code.google.com/speed/page-speed/docs/payload.html#RemoveUnusedCSS
Removing or deferring style rules that
are not used by a document avoid
downloads unnecessary bytes and allow
the browser to start rendering sooner.
Before a browser can begin to render a
web page, it must download and parse
any stylesheets that are required to
lay out the page. Even if a stylesheet
is in an external file that is cached,
rendering is blocked until the browser
loads the stylesheet from disk. In
addition, once the stylesheet is
loaded, the browser's CSS engine has
to evaluate every rule contained in
the file to see if the rule applies to
the current page. Often, many web
sites reuse the same external CSS file
for all of their pages, even if many
of the rules defined in it don't apply
to the current page.
The best way to
minimize the latency caused by
stylesheet loading and rendering time
is to cut down on the CSS footprint;
an obvious way to do this is to remove
or defer CSS rules that aren't
actually used by the current page.
Concerning this:
Due to a claim that "additional lines
of CSS slow down body.onLoads," my
argument to code all background
expectations in the CSS was rejected.
The extra time is in the order of a few milliseconds. Do what is easier and maintainable, not what is more "efficient".
i want to manage all the design of my website(asp.net) through my css.
my client requirement is he should be able to change all design of website within 4-5 hrs.
is this possible.
is there any trick to do this?
Sure it is. ASP.NET doesn't but render html, css and javascript. What you need it to let it render the html you're after and hook in css for layouting.
ASP.NET also provides you with some great functionality: Themes and skins. These make changing css, images, ... a snap by either configuration or setting a certain premaid theme in code. I suggest you take a look at these videos for more information:
Customize my Site with Profiles and Themes?
Create User Selectable Themes for a Web Site
Use Skins with CSS for a Flexible and Maintainable ASP.NET Web Site
That's a very tall order indeed. By design does the client mean the color/theme or also the layout?
Basically is boils down to the following:
1. Generate semantic html only from you ASP.NET code. That is no in-line style and use meaning full css class names for html that needs to be styled
2. Break your css files into two. One for style and layout and another for color. If you're using images, they should be a part of your color css file
You can start here but also be clear about what your client means by "should be able to change the design within 4-5 hours".
Yes this possible if you have good knowledge of CSS i.e. 2 and 3. Have look at below links which can provide you and idea about layouts fully dependent on CSS
Yui library
Yui CSS tools
Many more ideas like CSS sprite can be used to achieve what you need
I'm building a site with a lot of similar css between pages. I've decided that a good approach would be to have the css generated as strings by php functions (with parameters) and outputed as an internal stylesheet in every page that i serve. The benefits:
this way if i make a change it will reflect throughout the entire site without having to maintain duplicates
i can send only the necessary css for a certain page
it's better than having small css files and sending a lot of css headers at inclusion
the possibility that the content might be displayed before the stylesheet is loaded is gone
i can calculate dimensions by using parameters
i can create a layer that will minify the result received from these functions or serve cached minified css
I haven't seen this done anywhere else unfortunately so i'm thinking that this might be because of SEO. The generated internal stylesheet will be at around 15kb max (before minifying the stylesheet).
I need your opinion on this approach and your thoughts about the impact a long internal stylesheet will have on SEO.
Many thanks.
Not an answer to your question (which is interesting enough!), but most of your arguments for inline CSS are wrong. An external style sheet is always the better and faster solution.
The first point you can handle by adding a version number to the style sheet's file name
The second point is moot because an external file gets cached, so no additional requests
The third point is moot for the same reason
The fourth point won't really matter once the style sheet is cached
The fifth point can be sorted using inline CSS for only the properties that need to be
updated dynamically - usually a tiny fraction of the whole CSS code base
The sixth point I don't get.
Go for an external style sheet. Just make sure it gets served with the correct caching headers!
Like long blocks of inline JavaScript, they are ignored.
Bots look at the content, not the layout. If you want a better representation of what they see, try the Lynx browser.
Unfortunately they will not be cached on the user's browser either, as external CSS and JS are, making each page load slower. It is actually more efficient to have a large external stylesheet than server up related "css snippets" with each page.
Assuming by 'internal stylesheet' you mean inline CSS included using the <style> tag, I'd recommend against this. If you use an external stylesheet, visitors download it once on the first request, and it will then be cached. By including all of your CSS inline, you're adding page weight to every single HTML request.
Although it might seem more efficient to just serve CSS for the current page, or split your CSS into lots of different page-specific stylesheets; in practice it's usually better just to have one stylesheet. Serving this compressed and with appropriate expires headers will almost always be faster than the alternatives.
Regarding SEO, robots ignore CSS, so this won't have any affect. If you had so much CSS that it substantially slowed down loading of your page, in theory you might start having issues, but you would need an inhuman amount of inline CSS before this could even potentially be an issue.
To the extent of my knowledge, your CSS sheet plays a minimal role in SEO, what is more important is your HTML markup and execution.
Following the order of '< h1 > - < h5 >' for your heading tags, with accompanying '< p >' tags instead of '< font >' or similar approaches is what will effect a web crawlers ability to recognise and prioritise the content in your page.
While you can use CSS to hide paragraph that you only want to appear in search engines and similar techniques it has little importance compared to the HTML structure.
All benefits you said apply. Search engines doesn't care too much about CSS and javascript (of course, if your page takes too long to wrap and send, this will affect, but I don't think it is the case).
I've seen this kind of solution before, but people tend to avoid use scripting to serve, once you can use media queries instead, writing just only one external stylesheet. I think you should take a look on this.
However, I see you are trying to optimize the CSS sent. This is good, but talking about 80k for all sheets, makes me think if you are not over complicating the rules.
Well, as last opinion, you can cache many different responses and make use of "canonical" thing on page head.