I've been playing around with LESS for a little bit to see about converting the website I manage at work over.
When I was learning about the behavior: url(...blah) ability of css I thought I had read that it was best to use that as little as possible for performance reasons (I now can't find that anywhere so not sure if that's still valid).
So with that assumption in mind I am a little apprehensive about converting that CSS into a LESS Mixin. Is this truly a performance hit or can I safely do this without being concerned about a slow down of the site's UI?
an example of what I'd be converting...
.FullRoundedBorder
{
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
-khtml-border-radius: 8px;
border-radius: 8px;
behavior: url(/Content/CSS/PIE/PIE.htc);
}
For those that haven't seen it PIE is an awesome plugin for rounded border cross browser functionality (mainly it fixes IE 6-8).
The use of the 'behavior' property itself is not a major performance concern -- you may have been thinking of 'expression' which is indeed very bad for performance.
However, you do need to examine the performance of the specific .htc that you pull in. Essentially .htc files are pieces of JavaScript that are executed when the CSS selector matches an element. This means that the more elements that are matched by your selector, the more times that script will run.
In the case of a complex script like PIE.htc, it is very easy to use it on too many elements resulting in a noticeable delay while it runs. Like any other script, you need to be deliberate about how widely you apply it, and of course test the performance of your site after applying it.
My experience with PIE.htc is that using it on about 15 elements or fewer is not noticeable, but beyond that you start noticing a delay. There are often things you can do to lessen the impact, such as using -pie-lazy-init.
Yes, PIE will slow down the UI in IE6-8. The more effects you stack on, the greater the impact. It should not affect other browsers.
I used PIE in a (big!) project last year to get some effects in IE6-8, but upon revisiting that project this year I decided to scrap all use of PIE. I found it to be flaky and inconsistent -- it would randomly fail to render a "Pay Now" button for instance. IE users would therefore be randomly incapable of paying their bill. I switched back to Modernizr with an image fallback for < IE 9. The moral of the story is: PIE seems great, but use it sparingly and only for non critical elements. It's difficult to debug when it goes wrong.
You can also easily try it and just disable it if you find your UI is too slow with it. If your mixins are good, it should only be a few lines of code.
I've worked extensively with Less. I like how it breaks large CSS into more logical and readable chunks. A few things to consider:
1) Will you be processing the Less server side or client side? I'm more of a proponent of putting fewer load on the UI/Browser because you simply don't have control over what kind of machine, browser the user is running and it adds more points of failure in your UI implementation. Simpler is always better. If your UI is for a small audience then you should see no performance hit. In most cases I will use Less when the plain CSS would be too large to easily maintain and read and thus accept a slight performance hit, especially if the user base is trivial. For high traffic sites, I would probably rewrite or convert back to CSS and publish the straight CSS.
2) Is Less really necessary? Are you loading a bunch of translation code or running an extra process on your server just so you don't have to write a few extra lines of CSS??? This is not justification enough in my Opinion. I often question the use of other "make your life easy" libraries/tools like JQuery, when i see a developer loading an entire library just because they didn't want to write "getElementByID()" pure native JavaScript.
Everything has it's place and it's use in a project/implementation. I suggest making a list of the benefits and then eliminating those that can be readily implemented with native browser features(plain CSS and JS). Smaller and lighter is always better and faster, especially if you're also running on mobile and legacy platforms.
I hope this helped.
Related
I'm using a jQuery-based framework (Kendo UI) which comes with its set of highly selective css rules.
In order to avoid the headache of my css rules clashing (and also to avoid using !important all over the place), I've nested everything in a body id -- e.g., #body-id .my-class.
However, is there a performance hit or other issue in using:
#body-id #my-other-id?
Every resource I find says, "it's pointless and makes no sense semantically." I agree, however, as I'm using the Less CSS framework, my entire CSS stylesheet will be wrapped in #body-id (for simplicity sake). Thus, it would eventually compile to #body-id #my-other-id (I'm assuming).
The jQuery selector speed is not very important, because there are other more narrow bottlenecks in your browsers JavaScript implementation.
Only if you have many, many jQuery operations like this to perform, the speed performance will be an issue
But by the way jQuery analyzes the selector (from right to left) an id with child selectors does not profit from javascript getElementById speed.
So it's more or less not important. But it may be not good style.
Check, if your CSS code is modular!
Edit
Here is a 'official' resource on performance and else
http://learn.jquery.com/performance/optimize-selectors/
I am wondering if unused CSS styles affect load times because I normally break my sections of my code using this format
/*===================
Nav-Styles
===================*/
However, I also use coda to write my code. It has a code navigator, which detects ids followed by {}
what I thought might help with my code organisation is to create this format of break
/*==========================================
#----NAV-STYLES-BEGIN {} /* Nav Styles */
==========================================*/
This will mean my section breaks will them appear in the code navigator and can be jumped to quickly. However, if this is going to cause speed related issues, the means will outweigh the end.
Is this a bad idea or will the difference be so insignificant that it's worth doing if I wanted?
The answers here are not correct.
Unused CSS does two things:
Adds more bytes that need to be downloaded before the engine can start rendering the page
The browser engine has to go through each css selector to evaluate whether it is on the page and how it should render.
The second part is crucial. If 50% of your css file is unused css, you are essentially have the browser engine take twice as long to render your CSS for the page. Of course, the type of CSS selectors you have matter as well, so the twice as long is more of a easy example than full truth. Never the less, unused CSS increases your browsers page load time, even when the file is cached on the local drive.
Any unused CSS or JS that is passed over the wire to the client will hurt the sites performance at the least to a small degree. The unused CSS increases the size of the page, therefore increasing the time it takes to download a page. A few characters here and there will not have a huge impact on your download times, however if there is a large amount of unused styling there may be an impact. This is why many people compress their CSS and JS.
The effect of this is going to be unnoticeable, and could be described as negligible at best. Regardless, you could use a build script to remove all comments and minify your CSS. This will improve load times, if only slightly.
The short answer - go for whatever is easiest to develop with. You can worry about production later.
I hesitate to add
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to Manage CSS Explosion
I intended to build my web site with consistent styles and a coherent CSS scheme. But styles have crept out of control as I fine-tune individual pages (especially the main search form).
I've already gone through the process one time of breaking down the styles and rebuilding almost from scratch, and now it looks like time to do that again. How can I be efficient about this? I'm looking for a methodology, not a software utility (though I'm open to suggestions there...unless they cost money...).
Added note: I'm using a CSS framework and it's difficult to keep padding and margin coordinated.
Added note 2: The initial responses to this post are about best practices for CSS. Let's assume I already tried to follow best practices (in fact, I did). Now it's the clean-up procedure I'm looking for.
Added note 3: As of 14 June, combining this response (which I just found) with my post below is possibly a comprehensive answer.
Closure notes:
I learned my question is too general, and for that reason I wish I hadn't posted it. (Maybe that's why it got a down-vote ... I'll never know without a comment to explain the reason.) On the other hand I got just what I needed, so I'm happy I did post it.
I'm surprised I didn't get an up-vote for my answer -- even with the priceless input by others, I think it stands up pretty well.
My acceptance is going to be based largely on the usability of the answer, from my point of view -- a point of view that is sadly unable to digest some of the more exciting and comprehensive responses.
Closed as an Exact Duplicate
I just tried posting this again (subject, body, tags) to see if SO would suggest the post "How to Manage CSS Explosion". Interestingly, it did not. I added the tag refactoring to that post.
Split your css into separate files.
Put in one file the CSS reset (if you use one)
Then create a global.css file where you will put global styles that
apply to many-all pages
Then create individual files for your individual pages
Then start styling your pages. Every time you find a style rule that is reusable on many pages make it a CSS class and put it in the global.css file. Avoid using css ID's. You will find that you more often reuse things or will reuse in the future. In this case you use of course CSS classes.
Eventually you will find out that in your global.css you will find mostly CSS classes rules and html tag rules.
In your individual page CSS files you will find specific styles for each page.
That should give you a good first level of organization in your CSS. You can try to keep this separation through the whole development process, and for releases merge the CSS files into one and minify it.
my 2p worth about css cleanup, from a a previous similar question:
Tips for cleaning and maintaining a big css file
hope that this may help you together with others' answers!
start branching the project (here I suppose that you are using a version control tool) - that will allow you to play independently with the code and tag any milestone you will reach.
format your CSS with a beautifier - it will increase readability and will help searching for specific declarations without missing any instances.
try to identify unused / redundant css and get rid of it.
you could try to make your selectors shorter (e.g. .main .foo .bar might be fine as .bar) - it will improve readability and increase the performance, but take this with a pinch of salt and be ready to go back if things start to break at every step you take.
try to eliminate, if possible, any !important - make the selector more specific if needed. A css reset could help with that if most of the !important statements were made to fix browser-specific issues, otherwise introducing a css reset now could potentially add more problems than solve them - this, if there is no css reset in your app at all.
break and regroup the css into different modules (and files if that helps) - Object Oriented CSS is a possible technique to keep things more maintainable, it works best if you start with it but it may also help you in refactoring. https://github.com/stubbornella/oocss/wiki is a valid one but there are alternatives that you can consider, like SMACSS.
After that , you may consider using a css preprocessor such as Less or Sass, allowing you to define variables and mixins (similar to functions), modularity and much more - this may end up being a very expensive task though, so evaluate carefully if this will bring you more benefits than pain.
test as much and as often as you can, consider unit tests to make sure that any changes you make don't break anything somewhere else.
Sometimes re-writing everything may end to be less time consuming than refactoring, so don't be afraid to leave things as they are if your assessment will show that refactoring will not bring enough benefits.
EDIT
Things change and evolve for good; with regards to OOCSS/SMACSS approach, I have been happily following for a while, Yandex's BEM methodology for CSS, I would like to add it as an additional recommendation to the above
The first thing I'll do is separate the CSS based on the purpose. Maybe first the general page layout (DIVs, boxes, ...), then the styling (fonts, H1/H2/.../Hn titles), then some more specialized CSS (CSS for tables, for forms, for specific components of the site).
Such a separation helps to organize the changes; if you have to change or add a font, you know you'll find it in the styling section.
If you have to change the page layout, there goes the same, and so on.
Things tend to get messy when you have "individual pages"; is their layout so different?
You probably have to abstract the common features of the pages (for example, a main content container box) as long as you can.
Then think about specializing more the layout (1-column, 2-column) and so on.
If you have a programmer background, just think about classes and inheritance, the concept - yes I know it's a totally different domain... - but the concept can be useful in designing your css.
Based on this current round of work, here is what I've got so far:
the Planning
Have a system for handling To-Do notations in your HTML and CSS. Many IDEs support this directly, or a global search function will do just fine. Besides tagging issues, you want to note priority and perhaps even functional area (but keep it simple, not a burden).
Don't start revising your code. Use your To-Do system to plan first.
Make a concise list of your overall goals.
Consider overall sylistic changes such as color or font scheme.
Review best practices for CSS. Identify areas where your approach is ineffective, or where a good approach can be applied more consistently. Examples:
Consolidate classes
Eliminate haphazard use of in-line styles
Remove styles that are unused or redundant or conflicting
Improve general consistency; apply a set of conventions
Improve units of measure
Use class and id names that reflect content rather than format
Decide how much of the browser market you want to support and how much to embrace or rely on the newest standards.
Decide if there are any new approaches you want to adopt. Examples:
Use of a reset style sheet to standardize browser presentation
Use of a CSS framework
Use of a specialized library, for example to help with forms
Dynamic CSS (I recently followed advice to use PHP to handle my CSS, so I could dynamically control my color scheme. But I returned to straight CSS, because I like the presentation of CSS code in my IDE and the hybrid method messed that up.)
Review your list of goals and decide which should be pursued now. Any large-scale change should be treated as separate, if possible. If your column layout is a mess, it's not the time to learn how CSS can elegantly replace your javascript. The same goes for best practices, stylistic changes, etc.
If you have your CSS files configured for speed (for example, compacted footprint or all CSS in a single file), change that. Break the code into a human-managable format. Later when you're finished, try benchmarking to see if the more legible version is also efficient enough for production use.
Submit your CSS to a validator. Note any violations you want to fix.
Find instances of in-line styles in your HTML (search for the style attribute). Note any that should be moved to a style sheet.
the Work
Follow your To Do manager. Make common-sense back-ups. As you go, test your work on several browsers.
If you are into regular expressions, be warned: regex is often not effective or safe for rewriting CSS. (Not as hazardous as for HTML, but still). Regex may be useful sending CSS changes into the HTML, but again be careful.
If you have a lot of tweaks to margins and padding, try globally resetting all of them to 0px (okay, use regex here). Then systematically build them back up. You can resolve a lot of confusions this way. Of course, don't include any library or framework style sheets in this process.
Again, submit your CSS to a validator.
I see people has already suggested using approaches like OOCSS etc., so I'm going to offer a different/additional line of thought. I believe that the problem lie deeper than within your CSS and the way you write it. I believe the reason your CSS gets out of hand is this quote from your question:
... as I fine-tune individual pages ...
That makes me think that the problem much lie within your design, rather than you CSS, so let me elaborate a little bit on that. In my opinion a great design is a design that doesn't have to be customized for each individual page - and there are several reasons for that. The main reason is, as you've mentioned yourself, your CSS get out of control. Small tweaks and fixes on individual elements, depending on where they are placed, often leads to a mess that is a pain to maintain and work with. There is also a usability-reason in play here. I believe a UI becomes easier to use if the user is familiar with the UI and recognize herself from page to page, without to much variation. Of course you could have some element that isn't present on each page, or that vary somewhat between pages, but I always strive to keep them at a minimum.
My suggestion is therefor that if you intend to rewrite your CSS, which is time-consuming and hard work anyway, then why not go over and re-evaluate your design at the same time. You will probably find that there are elements that you can modify so that they look the same. Make it a goal to get rid of as many UI-elements as possible, without compromising the design. When you've unified the design as much as possible, then it is time to refactor your CSS, and maybe even your markup?
At this point, it might be better to get rid of all your CSS and start fresh. If you continue on your old code, it is easy to get lazy and get stuck with some of your old less efficient code.
For the coding, I believe the other answers contain lots of good recommendations and best practices. I would personally vote for OOCSS, a new discovery for myself as well, but it has improved the way I structure my CSS a lot. So have a look at that! That will also help you think in terms of reusing elements and the CSS for them, which goes a long way for simplyfing your CSS.
This answer is in regard to the note;
"I'm using a CSS framework and it's difficult to keep padding and margin coordinated." only.
Using a css pre-processor will solve this problem.
Because css has no way to assign inheritance and therefore we have to repeat 'margin:10px' over and over.
with a pre-processor you just do
#margin {10px}
#padding {10px}
then
.mySelector{
margin: #margin;
padding: #padding;
}
For the broader question rethink/simplify your design as your css is directly proportional to the complexity of the design and there is not much you can do about that.
See also, http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/
This is more advice about making your css maintainable than the Q of how to manage the process.
I create a bunch of separate css files each narrowly tailored to a specific attribute (colors, fonts, margins, corners) or feature (nav, form). Then I use a compile phase to combine and minify these files into one or more files to be sent to the client. I do this during my built/test process, but it could be done dynamically by a CGI script.
Before adopting a pre-compiler, consider the often-overlooked multiple-selector syntax:
element,
otherlement
{
margin:10px;
}
In this example, whenever I want an element to have a 10px margin, I add it to the list. I separate different sets of attributes this way - I may list the same element 5 times in my css - associating it with 5 different sets of attributes.
Also don't overlook adding various classes to the body tag to create OO-like inheritance - say you have 3 main sections of your site - assign the body tag a class based on those sections. Likewise, if you have 1000 product pages, you can give the body tag a class like "product485" and then create styles that apply just to that page. For example:
h1 {
margin: 10px;
}
.product485 h1,
.product484 h1
{
margin: 5px;
}
.contact h1 {
margin: 15px;
}
This might all be in a file called "margins.css" which specifies only margins.
CSS style sheets have a habit of growing big and chaotic over time.
There are a lot of rules, hints, and schools of thought that help achieving cleaner CSS. (For example here) However, all those require constant alertness, activity and a lot of discipline on the maintainer's end, with mixed real-world success. As Nicole Sullivan so nicely puts it:
In fact, in most cases, the things we considered best practices were leading to the bad outcomes we sought to avoid. I realized (unpopular though it might be), that we couldn’t make it work out well by trying harder. Each time we start a new project, we think “this time, I’m going to keep the code clean. This time the project will be a shining example of what can be done with CSS.” And without fail, over time, as more content and features are added to the site, the code becomes a spaghetti tangle of duplication and unpredictability.
Are there any efforts to create a language of some sort, with strict structural rules and a merciless compiler, that enforces strict rules that prevent style sheets from becoming spaghetti? The compiled end result would be CSS.
I have no idea what such a language would look like and whether, given the vast amount of possibilities and combinations, this is a solvable problem at all.
Is there any research in this field? Anything to try out?
One very interesting related tool is CSS Lint, but what I'm asking about goes even farther than that.
Edit: LESS and SASS absolutely go into the right direction, but they are not what I am looking for. They introduce some very nice features and are a godsend for the CSS developer, but what I'm, asking about goes even further and more into defined, enforced structures.
You could very easily write spaghetti code in any interpreted language, so really what you are looking for is a CSS compiler. This is sort of what Google GWT does for JavaScript by generating it from Java code.
However, CSS doesn't have flow control, functions, variables etcetera, which means it doesn't make sense to have a higher-level language around CSS. At the root of it, it's just name-value pairs with cascading logic.
If you want to reign in your CSS code, you need to reign in your DOM as well. If you are defining columns with IDs left and right then you are semantically restricting the designer from moving them anywhere else. On the flip side, if you are smart about things you can do a lot more.
Lastly, the cascading part is what most new designers have the highest tendency to get wrong. If you pay close attention to the DOM and cascading logic, make use some good resets or grid-based frameworks and incorporate tools like LESS (Ruby) or LessPHP, you'll end up CSS that's far more pleasing to work with. I like LESS because It empowers you with quasi-functions, variables and nested properties which really helps clean up your CSS.
Are there any efforts to create a language of some sort ... The compiled end result would be CSS.
There are two efforts that I know of to do exactly this:
Less
SASS
Both aim to provide an improved version of CSS which allows you to write with more structure.
In addition, Google have demonstrated a development version of Chrome which incorporates a number of additions to CSS along similar lines. This is interesting because it indicates the future direction of CSS, but in the short to medium term you will need to use Less or Sass, as even the work in Chrome is very much experimental and will not be released for some time to come (and even when it is, you'll need to wait for the other browsers to follow suit).
[EDIT] Here's a link which details Google's experimental CSS features in Chrome: http://johanbrook.com/design/css/webkit-css-variables-mixins-nesting/
[UPDATE 18 April 2012] There has been some progress in this area since I wrote this answer. Slow progress, but progress nonetheless. The good news is that CSS Variables has just been published as a First Draft specification by the W3C.
See http://lists.w3.org/Archives/Public/www-style/2012Apr/0228.html for the official announcement of the specification.
So that's goodnews. Of course, how long it takes to get into the browsers and the end user base is anyone's guess, but at least there are signs of progress.
There is Stylus, something like LESS and SASS, but with transparent mixins.
That means that you can hide away complexity by bundling it into new key/value pairs. Example from the site:
border-radius()
-webkit-border-radius arguments
-moz-border-radius arguments
border-radius arguments
form input
padding 5px
border 1px solid
border-radius 5px
Maybe this kind of syntax is what you want?
PS: you can still type braces and semicolons, if you prefer ;)
Well you seem to know about Nicole Sullivan, so if you know about OOCSS already, I apologize, but no one seems to have brought it up. If you don't, it's her own project to do this very thing, I believe. It's only in Alpha testing right now, but you asked about efforts and not finished languages, so maybe this will be just what you're looking for. It definitely claims to be be for solving the problems you describe, but I haven't used it myself.
https://github.com/stubbornella/oocss/wiki
Have you checked out Compass? Compass is a framework built around Sass. I think it mostly adds features and boilerplate code to add a library of predefined mixins and whatnot. However, Compass might be even closer to what you want. Compass is based around Blueprint which is a straight up CSS framework (which may also be worth looking in to).
To me the best approach would be to take Compass and Sass (or CSS and Blueprint/LESS and something comparable) and to write a very concise and detailed style guidelines which you could develop overtime as you figure out what works best: your first thoughts on the matter, regardless of experience, may be wrong. Once you have these guidelines down you could talk to the people at Sass, Compass, LESS, Blueprint, whatever, about working in some of your well thought out and "researched" guidelines. OR you could start contributing to these wonderful projects which I believe are all under an open source license (Sass is under MIT, LESS is under Apache and I think Compass and Blueprint also under some form of open source license). Fork it and have fun :D
What are the aspects of style sheets (CSS) that can lead to poor performance of web sites?
Anything that can really choke up the CPU?
thanks in advance.
Sesh
IE expressions can be a killer if over used. They're reevaluated each and every time the rule is applied.
CSS? Not so much it's pretty tight, but on older (like gen 4) browsers I've seen problems with:
doing too much on the * selector
using inherit a lot
using the IE expression value abusively
loading a lot of external resources (images, other CSS docs)
applying a lot of what you might call unanchored selectors like div div
Basically anything which would be difficult to cascade through or would cascade a lot.
Browsers are very good at rendering CSS rules quickly.
Probably more important is the size of the CSS file. For most sites, this isn't a problem, but for larger sites it is something to be aware of.
For instance, cnn.com delivers something like 150K of CSS. This will take a few seconds on older modems, so CNN ought to make sure that their CSS is cacheable and gzipped.
I have personally never encountered anything in CSS that would do this. Flash content and exessively large pages are far more likely to slow down a browser. That said I would image over use of expressions or custom IE filters (as are often used for transparency of PNG images) may use a lot of CPU.
Something that chokes not-too-old browsers are huge backgrounds that use "background-position: fixed" a la Complexspiral Redux.
It's hard to affect the CPU (except with IE expressions, like sblundy mentioned), but it's very easy to affect the page-load time.
Try to follow Yahoo client-side performance guidelines, such as:
Put CSS links at the top of the page
Use <link> instead of #import
Combine CSS files
Minify CSS files
I have seen cases where high-resolution tiled background-images (usually jpg or png) cause a major slowdown (choppy effect) when you scroll.
Most likely, the CSS file is not choking the site quite so much as trips to the server, complex calc, etc. might. But if it is:
There's an art to writing a lightweight-but-effective css file system that is ever-evolving, to say the least. Effectively using classes and IDs to take advantage of the cascade, for example, can be tough, especially when the project evolves over time, or if the GUI writing it gets swapped out several times over the course of the lifecycle.
For every legacy browser you have to support, it adds a performance hit, especially if you're using hacks to get it done. Those can be tricky, especially if layered upon one another. Conditional comments are similar - the browser has to decipher which rules it follows, and read through everything before it renders.
Going full-size image when you could tile or set a color on a background is a drag on siteload, as well.
(Gratuitous shot) IE can take a long time to misrender your styles and elements.