I'm currently developing a professional website and I have reached around 750 lines of CSS for around 4 pages, the bulk going into the homepage. I have curly braces in separate lines. I could probably reduce it a bit by going through it again.
But I was just wondering, what would you consider as being too much css?
Regards,
I think there isn't a limit at all. Just write the code you need, and when you've finished try to optimize it.
A gotcha on this (not directly related to the OP, but for others who might come here) ...
IE9 and below only recognizes the first 4096 selectors in a CSS file. Everything after that is merely silently ignored.
How large is your CSS File? Sure, you have to worry about hard the browser has to work in terms on load when interpreting the CSS.. is it efficient, are you over working it?
Keep your size as low as possible is a given, but there are quite a few factors to think about. You can always minify, gzip compression when your done to save some time. Take a look at a testing tool http://tools.pingdom.com/
There's plenty of articles on this so I won't bother reeling off my personal opinion, so check these out
http://css-tricks.com/efficiently-rendering-css/
https://developer.mozilla.org/en-US/docs/CSS/Writing_Efficient_CSS?redirectlocale=en-US&redirectslug=Writing_Efficient_CSS
http://speckyboy.com/2011/03/08/website-speed-part-1-write-more-efficient-css/
Assuming your home page doesn't have tens of nested components that have different roles/looks, you're probably being a bit non-clever with your CSS. There are two things to worry about here:
Bandwidth: If your CSS file's size is more than 50KBs or so, some of your clients with low connection speeds/bandwidth might experience
some notable lag.
Rendering: It's possible that your CSS file is complex enough to force the client's layout/rendering engine to make some extra effort while
rendering.
Both the issues would reduce your website time-efficiency. What to do?
The simplest example on how to optimize your CSS file is to collect rules that you use for many elements in one class. There are many other tips to help reduce the size of your CSS file; the other answers already link you to some articles with helpful tips, but if you want to give programs that automate the process a try, take a look at CSS Tidy (and an online tool based on CSS Tidy).
I hope that helped!
It depends on what is your website supposed to do. If it is a small blog and you need, say, 3000 lines of CSS, that is probably too much. If it is an online store with multiple sections and a complicated layout, it might not be enough. It depends on your needs.
Related
Once upon a time I was thought by more advanced web developers (gee, when was it again? ;)) that we should avoid managing multiple CSS files and stick to one per project. It helped to improve page load speed and avoid silly mistakes when dealing with a lot overlapping CSS rules.
My question is - is this approach still valid?
Argument about page load performance doesn't seem to hold that much nowadays with awesome broadband Internet and clever web browsers with even more awesome caching capabilities.
CSS cascading can indeed be error prone, but just for inexperienced developer and having one CSS style sheet doesn't really make us bullet-proof.
I think that I would prefer to have a set of default style sheets neatly separated by components, then wire them up into one single rule by CSS #import. This would also allow me to include reset style sheet by default.
Anyone is with me?
It's not about bandwidth speed but number of http requests, this makes a lot of sense for a mobile connection.
However the approach of having different css files to keep the project modular is solid, as it helps you keeping your css organized the way you want it without having all the code in one file only. Then you can benefit of css preprocessors / minifiers to concatenate and compress all your css files in a single one for production.
this article http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/
has a paragraph about mobile that explains well why this is a good practice:
you are much better off downloading all of the CSS content in one shot over the initial, warmed up connection. By doing so, you will also help the user extend their battery life. If there is one optimization to be made here then it is simply: concatenate and compress.
Yes, that approach is still valid. There are dozens of articles about load optimization out there, but the general idea is as follows
Less files = less http requests made to server = better load performance
Main thing that changed over time is that now there are many tools that support merging multiple files into single at runtime. So you have separate stylesheets for better organization, debugging at development time, and those tools merge, minify and set correct caching headers at production.
I agree with you, I find no reason to keep only a single css sheet anymore, nowadays, I do exactly what you just stated, separation by component, along with lazy loading :) (php if statements etc).
I separate stuff with comments. For example divs goes to /* Divs start*/ div#somediv /* Divs end*/ /* Animations start*/ /* Animations end*/. For me this is easier than merging different css files once i've completed the project
I've made websites before it was really used, and I've made the decision years ago to use CSS to design my webpages. It was a lot of trouble to leave the great tables and try "clearing both" instead.
The question is, after all those years I still have trouble sometimes. And everytime I run into a bad CSS situation I recall the easy way to make cols with "table".
And the more I'm thinking about it, and the less I understand why we dropped the use of table. They are great to design pages, and not every websites need to be 100% W3C conform or have hundreds of page that wouldn't support a change of design because of that.
So yeah, now I'm thinking about going back using tables. Should I do it? Do pro designers actually use tables where they shouldn't use them?
I also stumbled into a grotesque table in the google map API. If google ingeneers are taking that shortcut, why not me?
(sorry for my english I'm not fluent).
EDIT:
lot of response says it's my fault. I considered being pretty good in CSS, started with books of Eric Meyer and have been doing CSS since 2005. I know that the trick width:100%;overflow:auto; works in most case (and also that we didn't have this trick bad then), but I wonder if it would be a bad thing to use tables to quickly do the job on smalls website, like a blog.
I had the same issues when I started dropping tables and using CSS. Sometimes CSS floats can be a pain, there are a few tricky edge-cases that come up when using them for page layout, but you'll learn how to deal with them and it really is worth it. Your code will be 10% of the size and much easier to work with.
Another consideration is CSS floats can be made to work nicely with mobile devices and small screens. Tables can cause real issues with this, especially if you want to add nice touchscreen improvements.
Lots of "pro" designers use tables when they shouldn't. All over the place. But "pro" is often not the same as "good". Tables should only be used for visible tables of data.
Tables still have an important and semantically correct correct usage. That is for the display of tabular data. That is especially useful in envirnments that are DB-centric or that are process a lot of xml with ajax. For general layout they are not appropriate because the cause slow page loading because the browser has to wait for all contents before it can start rendering. CSS should not be difficult. If you are having trouble you should look at how it is being used on sites where you like the design.
The big advantage of CSS is that you can develop a master stylesheet for a site, and then where individual pages need slight variations you can apply overrides or modifications to specific elements without having to change the master sheet.
avoiding table layouts offers up a plethora of benefits but # the end of the day, browsers are still entirely too forgiving (currently) and you can get away with it. if you are wary of going back to them, read up on display:table and css3. it's practically table based layouts, minus the table.
One reason tables are avoided is that the content inside of them does not display until the HTML for the entire table has loaded. With the CSS method, this is not true.
If you really have a lot of trouble with the CSS method, you must be doing it wrong. Consider reading over other people's code to see how to do it better.
6 years later (we're now in 2017) and CSS now has grids and flexbox which should be the easiest way to build a layout without using ugly hacks and without using tables.
Short story: I frequently have to work on many different, rather small, web pages.
Most of them are layouted with pure CSS.
My Problem:
My job is to work on the code itself, on the functionality of the pages, not on the layout. However, due to the changes I make, I am often forced to make slight layout modifications and that soaks up my time like a black hole.
I end up spending as much as 10 times as long to do the slightest layout modifications as it takes me to add or rewrite routines.
We have a designer as well but it is just impossible to wait for him to redo layouts for every change I make (and often enough I have to change things multiple times).
So what I've searched for is a super basic and simple CSS WYSIWYG editor that isn't a complicated professional design tool. After trying a few tools I gave up, going back to editing by hand. In particular, the behavior of nested layout boxes just freaks me out every time.
Does anyone have some hints on this?
I'd appreciate any help,
Thank you
Two thoughts:
1) Adopt more of an agile process
The visual design (layout) and logic design should be built in tandem rather than one after the other. As you've found out, modifying things after the fact can be a real pain.
2) Adopt a CSS framework/OOCSS methods/Component Library
The idea behind all 3 of those is to create reusable CSS that follows a predictable structure. This takes a lot more up-front work, but results in a code base that should be a lot easier to maintain going forward.
twitter bootstrap
http://twitter.github.com/bootstrap/
looks really good from first impressions.
My rails expert keeps raving about it and I'm planning on trying it. Obviously free 'n all.
Basically we've felt your pain with this issue!
Bootstrap is good for real developers, a lot of it is basic layout via css tags and I think it'll make a lot of sense to you.
Even if it doesn't meet all your needs, it might be a great place to start with, as a standard for a development team. As much as developers often dislike being templated ;)
The actual direct github site is: https://github.com/twbs/bootstrap
Is it used much? Currently?...
Github Stats:
Watcher: 8682
Forks: 1383
Last Update: 10/10/2011
This post: 10/26/2011
Looks good! :)
I'm also a big fan of HAML - Ruby + HTML without the angle brackets(and more)!
... not sure if this will help, but yahoo grid builder works well for me. Of course there is a catch. The css selectors it generates are not very semantic, so you might have to do some re-factoring of them from withing the generated html page.
Github Stats: (for Blueprint suggested by Daniel below)
Watchers: 4556
Forks: 390
Last Update: 06/06/2011
This post: 10/26/2011
Are CSS reset pages (like this one) still necessary in today's age? I assume the answer is yes but looking to see if I get surprised.
I've read thoroughly the HTML5 BoilerPlate from Paul Irish but don't see myself adopting a standard that isn't necessarily standard. [Rhetorical] Isn't this at least some cause of what got us into this mess if you put aside the IE bashing?
yes, the same reasons they were created still exist: several browsers have several different implementations of CSS, and this is one way to take care of them.
Necessary? No.
Some developers like to use them, some don't, but they are definitely not necessary.
Necessary? No. I actually think it never has been necessary. But a CSS reset will help you to make your project look the same in every browser and might save you a lot of time of browser-testing and debugging.
I'm using my own reset file, customized to my needs:
http://www.htmltweaks.com/Reset_Browser-Specific_CSS_Styles
only if you want to have an easier time getting your site to look the same in all browsers.
If that is not a requirement, or if you don't mind having a hard time getting IE to follow suit then by all means. A lot of developers every day are making sites without css-resets.
They are no less necessary than they ever were. IE6 still has a significant market share.
I've recently begun working on a very large, high traffic website. We would very much like to reduce the size and number of our style sheets, minification is one route we will pursue but is anyone aware of any tools for checking ID and class use? Literally scanning the website to see what's active and what isn't?
Alternatively any software for redacting the css to reduce repition and size?
Thanks in advance
Literally scanning the website to see
what's active and what isn't?
Dust-Me Selectors is a Firefox plugin that you can use to show what css rules aren't being used.
http://www.sitepoint.com/dustmeselectors/
I can certainly recommend Page Speed (http://code.google.com/speed/page-speed/) by Google to check the performance (and possible improvements) of your webpages.
Page Speed also checks CSS and usage of classes on your webpages.
It is used in combination with Firebug.
Gzip compression in the webserver.
Expiry dates that lie far in the future to avoid redownloading the CSS files.
Alternatively any software for
redacting the css to reduce repition
and size?
Yet another level of indirection ... You (and your team) should write long CSS files with as many comments as needed and then write a tool that will publish merged files as needed (different templates need different files), stripped comments and minified as http://www.cleancss.com could do (CSSTidy). Readability comes first if you wan't to be able to modify a file in 1 month or keep track of modifications (or worse if sb else must do that!).
Other options are to reduce the number of templates used throughout the site. No need of two templates with 2px differences (grid layouts are a good way to stick to this) or inconsistent ways of displaying error messages. Define a common look and feel to your site and give instructions to webdesigners, if it isn't already done.