Is it worth adapting to a css framework or just use the css we all know?
How to get started with Blueprint [CSS Framework]?
Any other css frameworks which is really worth a try?
If not Blueprint, I recommend at least using a CSS reset file, which standardizes many default browser settings that differ across browsers; such as the Yahoo "YUI Reset CSS".
Otherwise, if I were you I guess I would just start in the Blueprint wiki and look through the tutorials. Then make something of your own!
To determine if it's best to use a css framework or not, you need to look at your overall web design and see how easily you can break it down into elements. If you find yourself using a lot of container divs and floating them all left or right, a CSS framework may be a good idea.
Another reason it may be beneficial to use Blueprint is that you can decrease the amount of CSS you need. Rather than creating a div id for every column or container and putting in a width and height in your CSS file, you can just use the framework and quickly assign a class.
I built Intronis.com using the Blueprint CSS framework. It worked well because it is a very clean site with common elements and it's based on a grid.
I'd use a CSS framework on a case by case basis. Let the design dictate if you use it or not. For some sites it's a good fit. For others it's not.
To get started, download it here, then just unzip the file and put it in a local test environment to try it out.
Also, make sure you take a look at the IE6 CSS included with Blueprint and take note of the .clearfix class that you can use when working with container divs and floating objects.
I've just written a brief tutorial on how to get started with Blueprint CSS, you might like it. http://flowdev.tumblr.com/post/1187039740/blueprint-css-to-grid-or-not-to-grid
Related
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.
Ok, so Less.js has come along, and it seems that my dreams of creating a CSS framework (especially a 'grid' system), with an 'abstracted' CSS language might be about to come true.
That is, 960 and Blueprint are great and all... but it so irked me to put style information in HTML markup, such as:
class="article grid_4 pull_2"
or whatever the syntax was :)
So, now it seems that we can do it this way:
.article {
.grid_container();
.grid_four();
.pull_two();
.last();
}
Weeeeeee!
So, I'm about to get stuck into developing this for myself -- but I'm sure there are some brainiacs out there that have already done it -- so before I get into any heavy lifting...?
Any leads?
Kindly
Daryl.
This is the CSS framework you're looking for - http://semantic.gs/
The Semantic Grid System - Page layout for tomorrow.
Set column and gutter widths, choose the number of columns, and switch between pixels and percentages.
All without any ugly .grid_x classes in your markup. Oh, and did we mention it's responsive?
Brought to you by LESS.js and the creator of 1KB Grid.
I checked out less , it was a push between that and the new sass (scss) syntax, but what made me choose sass is that it has a way to turn css into scss code.
The round trip was something I definitely wanted. Once that happened, then Compass presented itself. I was going to try using something to code everything in python, but it makes perfect sense to me to preprocess the css, especially since I'd like to use HTML5, and if the spec changes, then I can tweak the generation.
BTW folks, I've started that framework I was talking about.
http://github.com/DarylAntony/lesser
I'm having fun with it.
So i am working with a few CSS developers and every now and then we run into layout issues which have been fixed previously because one of the css developer did something which conflicted with something else.
We are already using SVN .. each CSS guy has his own css file he works with. So my question is what steps should be taken to minimize:
1 : layout conflicts
2 : increasing re-usability of previously written styles.
3 : minimize wasted time trying to merge the styles together in the final css.
I would really appreciate any tips you guys have to offer.
Update:
I am not one of the CSS developer, i just take care of the backend stuff.. so please keep in mind that i am a total newbie when it comes to CSS norms.
Define a naming convention for your CSS files to prevent conflicts (prefix?)
Have an automated process that you can run before check-in (check-in tests) to see any potential conflicts
Discuss what you will add (code review?) and avoid the conflicts altogether
I dont know of any namespacing you can do to avoid CSS stylesheet name conflicts so, I suggest those. They are things that many large companies do already.
A good starting point is to disallow using general tags in specific css files. Each developer should only use classes and ids. All general tags should be included first on all pages, so that special tags may overwrite them later.
Changing the general tags should require more planning than changing each developer file.
With general tags I mean
div {
/* affects all divs */
}
and each developer should only do
div.something {
/* potentially overwrite defaults for div */
}
and the html file should be like
link href="general.css"
link href="dev1.css"
link href="dev2.css"
The best thing you can do is assign areas of responsibility - if you are all working in the same area of the site you are bound to have conflicting changes and will only create difficulties for yourselves because you will constantly be stepping on each other's toes.
Once you have established a common baseline for the styles of your site, divide the main areas of the site amongst you and only work in those areas. When changes need to be made to the baseline, make them out in the open and communicate with your teammates about this change so that no one is surprised.
I am not going to pretend that this is easy to do - working on something as a team is a challenge that the entire software development industry has yet to completely solve. Good luck!
All others have good answers, but I'll add this: Strongly encourage the use of IDs in selectors. ID-ing important elements generally pays off in the long run because it allows for better testability and less conflicts.
CSS Example:
#myid selector { ... }
#myotherid selector { ... }
General styles really should go in a top-level or general stylesheet that everyone manages, if possible.
Is there any way to find unused CSS in a website?
I'm trying to clean up a project I just inherited.
Dust-me Selectors is a Firefox plugin that finds unused selectors.
I just ran into this and remembered your question: http://github.com/geuis/helium-css
Chrome 59 has built-in coverage display for CSS and JavaScript since 2017-04: https://developers.google.com/web/updates/2017/04/devtools-release-notes#coverage
You can enable it by opening the dev tools, then the command menu (Cmd+Shift+P on Mac or Ctrl+Shift+P on Windows and Linux), and then type "show coverage".
There is so much that can be said about best-practice methods for CSS. I'll try to stick to the main points.
Use a CSS reset.
Try to remove really general CSS statements like h1 {} and #container em {}. You're much better off using h1.section-title and #container em.important {}, because that way if you choose to use h1 or em a different way somewhere in your document, you don't have to worry about overriding any existing code.
Don't be too specific in your CSS selectors if you don't have to. You really only need to have high degrees of specificity if being in a specific section changes how the element is going to be displayed. Otherwise, to make your code for your block class reusable, #container .content .block ... could be reduced to .block ... in many cases.
Look for commonalities in your CSS and see if you can create reusable classes. If you have similar blocks class="favorites" and class="popular", turn it into class="block block-favorites" and class="block block-popular", and put the commonalities into .block.
Get in the habit of making areas in your CSS have an auto-width (can be done implicitly) so that they grow to the width of your containers. This makes it incredibly easier to move sections from a narrow portion of your website to a wide portion of your website without having to change any code.
Commenting your code and breaking it down into sections usually helps make code more readable.
You'd be surprised how much cleaner your code looks when you implement more powerful CSS selectors. Most of them are cross-browser compatible (Internet Explorer 7 and later).
Some valuable resources: When can I use... - Quirks Mode on CSS Selectors - w3 on CSS Selectors
Answer moved from:
Best Practices for Cleaning up Existing CSS/unused styles
To add to #cweiske suggestion, Google Chrome has a no nonsense way of uncovering where your "unused" and "never will be used" selectors are.
I have posted a screen capture of how to launch the CSS Coverage tool with step by step markers.
It is a reliable way to figure out where you really are not using stuff.
I've just been assigned the task to refactor a huge 5000 line CSS file... but here's the worst part - I also need to make it IE6 compatible. Any CSS gurus have suggestions of tools, or possibly tips (common pitfalls) for use in my monolithic expedition? Cheers.
checkout sass... it includes the ability to convert css to sass.
http://haml.hamptoncatlin.com/docs/rdoc/classes/Sass.html
A sass file is a yaml file that can be parsed down into a css file. It allows you to use variables and alternate organization...
sass example:
!main_color = #00ff00
#main
:color = !main_color
:p
:background-color = !main_color
:color #000000
css output:
#main {
color: #00ff00; }
#main p {
background-color: #00ff00;
color: #000000; }
Some tips:
Use version control so you can roll back when needed.
Come up with a checklist of visual tests to run through after each change, in each browser. A spreadsheet of URL links and things to look for, building on them as you run across problems (think "unit tests" but not automated).
Use a CSS-specific beautifier first to get everything into the format you prefer for braces, etc.
Consider using something like SASS to "compile" your CSS as you go along.
Comment the heck out of things, especially where you're doing IE6-specific stuff.
Future-proof yourself by building a separate file with IE6-specific directives as you go along, or at least use Microsoft's way of filtering them out for other browsers.
Use the W3C Validation often.
Mechanically, I would attack it like this:
<link type="text/css" href="newhotness.css" />
<link type="text/css" href="newhotness-ie6.css" />
<link type="text/css" href="oldandbusted.css" />
Move code from the third (old) file into the other two, cleaning up as you go. That way you can validate your code without worrying about tons of errors in the old stuff, and you can track your progress, Ctrl-Tab between them more easily than between locations in a single file, etc.
(If you can't control the markup to add your CSS files, use an #import at the top of the old file.)
Start from scratch!
Assuming you can check all the major pages manually, I would be VERY tempted to wipe the entire file and start from scratch. Spot-checking for IE6 inconsistencies, you'll be doing nearly the same amount of work anyway, but it will be much, much more painful if you're modifying old, browser-specific CSS.
That 5000 lines may well be expressable in 2000 lines of modern, well-designed CSS. I think most experienced CSS developers would find it less work to write 2k lines of new CSS than modify 5k lines of horrible CSS.
http://www.codebeautifier.com/
which is based on this:
http://csstidy.sourceforge.net/
Not necessarily CSS, but here's worflow tip: use GIT.
start off by importing the files in git;
commit for every minor step, and record what you did;
whenever you find that you broke something, you can identify the exact same step broke using git bisect ( a good description );
For extra kicks, here's a talk about code coverage for CSS to help you quickly weed out unused rules.
As Triptych said, I would start from scratch. Also, consider the following:
use a CSS reset file to smooth out cross-browser inconsistencies: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
get it working perfectly in Firefox, then tweak for other browsers as needed
study the underlying HTML. How is it organized? Is it laid out with tables? all DIVs? Semantic tagging?
is the CSS used for layout or simply styling (fonts, colors, etc.)?
Once you get a feel for that, study the content. Categorize the layout and elements as much as possible, so that you identify all the common elements and can maximize the efficiency of your CSS
remember the C in CSS, Make the most commonly used font the body font, so that other elements will inherit it by default.
use relative units (ems) for font size, to allow proper scaling of text
try not to use ANY inline styles
make use of Firebug - it will let you inspect an element and see exactly what CSS is in effect and where the rules came from
don't be afraid to re-use portions of the old CSS, especially for things like dropdown menus, which can need very specific incantations to work properly
have fun! starting from scratch lets you implement best practices and learn a ton along the way. When you are done you are probably going to look back on this as a good experience.
there is a presentation here that should get you in the right headspace for tackling this task: CSS Systems
I would be tempted into creating a test suite first: automating page visits (perhaps with Selenium?), taking screenshots, then using something like ImageMagick to compare those with reference images.
Also, I second all the suggestions to use source control. If you later discover that your refactorings broke something that wasn't checked by the test suite, you can add a new test and then bisect your history to find the change that broke it. Git is good for that.
Get a code editor with good syntax highlighting. Also, goodluck I dont envy you.
My initial thought was does some like NCover exist for CSS, as it would be handy to see if all of the CSS is referenced. A quick Google on CSS code coverage found a few things- you might want to look yourself though: http://development.lombardi.com/?p=436
Install sass, run css2sass on your 5000 lines of css, proceed. After you are done with your sass file refactoring, run sass2css to regenerate the css file. Best of luck!
I'd suggest Stylizer - it is a CSS editor with an embedded live preview browser. It makes life much easier when editing CSS files and can tell you which rules affect which element on the page and more.
All of you guys saying he should start from scratch are wrong. You shouldn't. Try to identify the different parts the site uses. Put them on a sheet of paper. Find the parts that match together. Build a structure. Find parts of the application that are the same but are still styled with different rules.
Take that one part and name it. Then match all app parts that use that "pattern" with the correct HTML/CSS.
Repeat until you're done. Break up the large task in small chunks.
Identify whether the original CSS writer used standard methods like using a CSS reset. If he didn't, and everything is defined by #id without reusable classes, well, then maybe the guys saying you should start from scratch are in fact right. But my point here is that you can't just recommend that without assessing the situation.
Using the Dust-Me Selectors Firefox Plugin can be handy. It's a bit like a code coverage tool for CSS.
Tool suggestion: ReSharper by JetBrains. It will autocomplete CSS and rename selectors site wide from the CSS file editing window.