I'm experimenting with CSS Transitions these days. I'm trying to build an animated web page with solely CSS.
Everything works just fine, but I came across an organisation-related issue: My CSS file look like a mess! If the client asks me to delay a specific animation or changing the order of another - It takes me few moments to find the right line to do that (few moments = too much).
May I separate animation-command from pure-design-css? How should I design browsers prefixes CSS (one line or several)? Changing animation speed must be as easy as a click (but now I need to type it 5 times).
I'd be glad to hear some ideas about CSS Trnasitions code organisation.
Thank you!
CSS files should be organized regardless of their content (transition rules etc.), this contributes both to browser's parsing, and to the file's readability in general. Note that:
You should order your CSS according to the rules specification and the cascade (obviously), also aggregating duplicate rules wherever possible.
It is highly recommended to add a table of contents, see example in this article on CSS files organization.
You better order key-value pairs in a consistent manner (e.g. alphabetize them) as recommended at google's 'make the web faster' article on payload.
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.
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
Regarding inline v. internal v. external CSS, I understand the cacheing issues, and the tradeoff between multiple downloads and single downloads of larger files. What I would like to know is how rendering speed varies, based on the three places you can put CSS.
In other words, what takes the least time to actually draw the page? I assume that external is the slowest, because even if it's cached, the browser still has to retrieve the rules, parse them, and apply them to the current elements. I also assume that internal (in the page but inside style tags) would be second slowest, because there's still the process of parsing the rules and determining which rules to apply to which elements. And I assume that inline (applied directly via style attribute) is the fastest, because the browser can skip the process of matching rules to elements.
Anybody ever looked at this in depth? I know that I've had some rendering problems on large pages with complex CSS that could only be solved by going inline. (Please, no lectures on the evils of large pages with complex CSS.)
either way, once the actual rule text is loaded, it's run through the same css parser - there aren't different parsers for external v.s. internal css. it's all just css. External might be a bit slower to get applied because it'll require an extra HTTP request to fetch that file, but once it's transferred to the host browser, it'll parse just as fast as if you'd physically embedded the same rules in an inline <style> block.
I don't think you should care which mode is fastest. HTML, CSS and JS are not meant to be fast in any case.
I think you should worry about readability and maintainability, think about managing a webpage with styles directly applied inside HTML tags. You wouldn't be able to manage anything complex in that way.
What you are asking mainly depends on browser implementation (with respect to the css file that could be downloaded separately according to which solution we are talking about). In any case I don't think the difference is so much considerable just because they all need to be parsed by the same parser.
If a page is really too complex to be styled with a stylesheet and requires inline style then the problem should be solved not by having inline css but refactoring things at a different level.
In addition I would say that many performance issues could be caused by writing CSS just without any kind of structure, just adding things day by day without even considering having strict/clever selectors. Developing things while thinking about them (that is something that is usually left behind in web development, especially with front ends) usually is the best way.
Is there a way of filtering large CSS files for the only required selectors on a page, and creating css files that contain just these selectors?
Case: I have a very large CSS file that I want to filter on a per page basis, so that the file size is cut down and can be cached by mobile devices. I was thinking along the lines of something like a server side dust me selectors tool.
The particular project I am working on is using ASP.NET MVC.
Thanks
Heads up that while you might get smaller individual page loads, the overall load of browsing the site will be higher given that you're hitting the server each and every time for a new CSS file (rather than just caching a site-level CSS file once).
In addition, if you find that there are a lot of unique per-page CSS declarations, the CSS for the site may not be written very well. So the solution may be to go back and rethink the CSS structure to begin with, perhaps looking into OOCSS models:
http://wiki.github.com/stubbornella/oocss/
Unfortunately, none of that answers your specific question.
Where multiple people can work on same css. is it possible to follow semantic name rules even in large websites.
If I would write all main css first time with semantic names . then what and how i should guideline/instruction to other developer to maintain css readability, validation . and to know quickly where other are adding their own css if required.
Right now every one just go to down and write required css classes ot IDs at bottom. and most of the time they don't write semantic names.
How to make good documentation/guide with text or with images for other developers on how to use css in whole site and how i wrote and what i used.
Update:
We use only one CSS file. I don't want to divide one css in multiple. Want to keep css managable even using one CSS file for whole site.
A similar question was asked a while ago: How to manage CSS Explosion there is a number of good answers there, and a number of great links (check out those provided by Paul D. Waite for example.)
Your main problem is going to be structuring the CSS file well. You will need clean rules for that: Keep everything grouped within the CSS file. Maybe using a CSS editor that can help you "navigate" through the style sheet is a good idea (similar to a programming IDE's "code explorer" feature). I don't know, however, if such a thing exists.
Other than that:
Using version control is a MUST. I personally am totally happy with centralized versioning using Subversion and TortoiseSVN; others believe in distributed version control like git or hg. For a team of designers, I think the centralized approach of Subversion is good, but that is a discussion in itself.
Maybe it's a good idea to split the style sheet into thematically relevant separate files to avoid chaos, and compile it using a tool like LESS or xCSS.
Define a clear, concise coding style. Use a CSS beautifier like Polystyle ($14 per license but money well spent) or Code Beautifier (based on CSS Tidy, haven't used it but looks interesting) and run it frequently on the file.
Have a number of links handy of pages that use the style sheet. Have people test those pages after they have made a change to the style sheet.
I would break down your css logically into groups and put each of these groups into its own css file. For example: header, footer, sidebar, content groups. Maybe some pages even deserve their own css file if big enough.
Similarly, give ids and classes on pages names that make sense. If it is a css rule for sub headings on a navigation bar, make sure it comes off as that in naming. Similarly to any other coding, don't use any magic numbers, etc. for naming.
See Modularizing web applications, includes specially CSS