Many frameworks seek to abstract away from HTML (custom tags, JSFs component system) in an effort to make dealing with that particular kettle of fish easier.
Is there anything you folks have used that has a similar concept applied to CSS? Something that does a bunch of cross-browser magic for you, supports like variables (why do I have to type #3c5c8d every time I want that colour), supports calculated fields (which are 'compiled' into CSS and JS), etc.
Alternatively, am I even thinking about this correctly? Am I trying to push a very square block through a very round hole?
What I found works best is to really learn CSS. I mean really learn CSS.
It can be a confusing language to learn, but if you read enough about it and practice, eventually you'll learn the best way to do things.
The key is to do it enough that it comes natural. CSS can be very elegant if you know what you want to do before you start and you have enough experience to do it.
Granted, it is also a major PITA to do sometimes, but even cross-browser issues aren't so bad if you really practice at it and learn what works and what doesn't, and how to get around problems.
All it takes is practice and in time you can become good at it.
If by some chance you happen to be using Ruby, there's Sass. It supports hierarchical selectors (using indentation to establish hierarchies), among other things, which makes life easier to an extend from a syntactical perspective (you repeat yourself a lot less).
I am certainly with you, though. While I would consider myself a small-time CSS expert, I think it would be nice if there were tools for CSS like there are with Javascript (Prototype, JQuery, etc.). You tell the tool what you want, and it handles the browser inconsistencies behind-the-scenes. That would be ideal, methinks.
You can always use a template engine to add variables and
calculated fields to your CSS files.
This elaborates on my previous answer.
When I first started using CSS I also thought it was a pain that it didn't support variables, expressions, etc. But as I started to use it more and more, I developed a different style to overcome these issues.
For example, instead of this:
a { color: red }
.entry { color: red }
h1 { color: red }
You can do:
a, .entry, h1 { color: red }
You can keep the color declared in one spot by doing this.
Once you use CSS enough you should be able to overcome most browser inconsistencies easily. If you find that you need to use a CSS hack there is probably a better way to do it.
Sorry to say that guys, but all of you missed the point.
The word abstraction is the key. Say you and Sally are making a website. You are styling forms while she makes the corners round. Both you and she have defined a handful of selectors.
What if, unknowingly, you picked class names that clash with the ones of Sally? You see, you can't "hide" (abstract out) the details when you work in CSS. That's why you can't fix a bug in IE then create a self-contained solution that others can use as-is, much like you call procedures in a programming language only caring about pre- and postconditions and not thinking of how it works on the inside. You just think of what you want to accomplish.
This is the biggest problem with the web: it completely lacks abstraction mechanisms! Most of you will exclaim, "It's unnecessary; you stop smoking crack!"
You will instead do the job of say, fixing layout bugs or making round corners or debating on the "best" markup for this or that case over and over again. You will find a site that explains the solution, then copy-paste the answer then adapt it to your specific case without even thinking what the hell are you doing! Yes, that's what you will do.
End of the rant.
Then comes the multiple browser issue
There is this that helps remove some inconsistencies from IE. You can also use jQuery to add some selectors via javascript.
I agree with Dan, learn it and it's not so much of a problem, even fun.
See, this is the problem with SO-- every answer so far has made a valid point and should be considered the final answer. Let me try to sum up:
CSS is good! To expand further, there is a learning curve but once you learn it many things will be much easier.
(Some) Browser inconsistencies are solvable generically.
(Some of your) Variable and calculated field functionality can be taken care of through whatever templating engine you use.
I think a combination of all these certainly solves a large sum of problems (although to be fair deeply learning CSS is not an option for everyone; some people just don't use it enough to justify the time).
There are some problems none of the above points cover (certain types of calculated fields would require writing a JS library for, me thinks) but it's certainly a good start.
For variable support, I have used PHP with CSS headers to great effect for that. I think you can do it in any language. Here is a php sample:
<?
header('content-type:text/css');
header("Expires: ".gmdate("D, d M Y H:i:s", (time()+900)) . " GMT");
$someColorVar = "#cc0000";
?>
BODY {
background-color: <?= someColorVar ?>;
}
Solutions to problems seem to often involve jiggering numbers around like some chef trying to work out exactly how much nutmeg to put in his soon-to-be famous rice pudding
I only get this when trying to make stuff work in IE.
If you learn CSS to the point where you can code most things without having to look up the reference (if you're still looking up reference regularly you don't really know it and can't claim to complain I think), and then develop for firefox/safari, it's a pretty nice place to be in.
Leave the pain and suffering of IE compatibilit to the end after it works in FF/Safari, so your mind will attribute the blame to IE, where it damn well belongs, rather than CSS in general.
CSS variables are coming (relatively) soon, but I agree they are long overdue. In the meantime, it is possible to use a CSS templating engine such as Sass, or even the dynamic web language of your choice, to generate your stylesheets programmatically.
For CSS frameworks, you could consider YUI Grids. It makes basic layout a lot quicker and simpler, although used in its raw form it does compromise on semantics.
The key to a real understanding of CSS (and the browser headaches) is a solid understanding of the box model used by the CSS Standards, and the incorrect model used by some browsers. Once you have that down and start learning selectors you will get away from browser specific properties and CSS will become something you look forward to.
Also check out BlueprintCSS, a layout framework in CSS. It doesn't solve all your problems, but many, and you don't have to write the CSS yourself.
I believe the common errors beginners have with CSS are to do with specificity. If you're styling the a tag, are you sure you really want to be styling every single one in the document or a certain "class" of a tags?
I usually start out being very specific with my CSS selectors and generalize them when I see fit.
Here's a humerours article on the subject, but also informational:
Specificity Wars
CSS takes a bit of time to learn, but the thing I initially found most discouraging was the fact that so many hacks were needed to get all browsers to behave the same way. Learning a system which doesn't adhere to logic seems dumb... but I've clung to the vague belief that there is logic behind each browser's idiosyncrasy, in the form of the W3 spec. It seems that the new generation browsers are slowly coming into line - but IE6 still makes my life hell on a daily basis.
Maybe creating an abstraction layer between compliant/valid CSS code and the browsers' shoddy implementations wouldn't be a bad thing. But if such a thing was created - would it need to be powered by JS (or jQuery)? (and would that create an unreasonably burden, in terms of processing cost?)
I've found that it useful to 'level the ground' when scripting with CSS. There are probably loads of different flavours of reset script out there - but using YUI resets has helped me to reduce the number of quirks I'd otherwise encounter - and YUI grids make life a little easier sometimes.
#SCdF: I think your summary here is fair. But the argument that some people don't have the time to learn CSS is bogus - just think about for a second. Substitute a technology that you've mastered and you'll see why:
I. Hate. Java. Is there something out there that will just write it for me? Not everyone has the time to master Java.
CSS is certainly an imperfect technology - I have high hopes that 5 years from now we won't be dealing with browser incompatibilities any more (we're almost there), and that we'll have better author-side tools (I've written a Visual Studio macro for my own use that provides the the sort of variables and calculations that you describe, so it's not impossible) - but to insist that you should be able to use this technology effectively without really understanding it just isn't reasonable.
You are thinking about this correctly though, you're probably still going to need to understand the different browser implementations of CSS. This is just understanding the environment your application lives in.
To clarify: this isn't about understanding CSS. If you know the language well, you've still got to handle the redundancy, duplication and lack of control structures in the language.
Ive been writing CSS solidly for more than 10 years and I've come to the conclusion that while the language is powerful and effective, implementing CSS sucks. So I use an abstraction layer like Sass or Less or xCSS to interface to the language. These tools use a syntax similar to CSS so you're solving the problem in the problem's domain. Using something like PHP to write CSS works but is not the best approach.
By hiding the problems in the language through an abstraction layer, you can deliver a better product that will maintain its integrity throughout the full life cycle of your project. Writing CSS by hand accelerates software rot unless you're providing solid documentation which most CSS coders aren't. If you're writing a well documented CSS framework, you probably wouldn't write it by hand anyway. It's just not efficient.
Another problem with CSS is due to it's lack of support for nesting block declarations. This encourages coders to build a flat, global set of classes and handle the name collisions with a naming convention. We all know globals are evil but why do we write CSS in such a way? Wouldn't it be better to give your classes a context instead of exposing them to the whole document model? And your naming convention may work but it's just another task you must master to get the language written.
I encourage those of you who pride yourselves on writing good CSS to start applying some of the best practices from programming to your markup. Using an abtraction layer doesn't mean you lack the skill to write good CSS, it means you've limited your exposure to the weaknesses of the language.
You don’t need an abstraction away from CSS—you need to realize that CSS itself in an abstraction. CSS isn’t about putting pixels just so on the screen. Instead, it’s about writing a system of rules that help the browser make those decisions for you. This is necessary, because at the time you write CSS, you don’t know the content the browser will be applying it to; neither do you know the environment where the browser will be doing it.
Mastering this takes time. You can’t pick up up CSS in a weekend and be good to go. It’s a bit deceiving, because the language has such a low barrier of entry, but the waters run deep. Here is just a few of the topics you should seek to master to be proficient in CSS:
The Cascade and Inheritance
The Box Model
Layout methods including floats and the new flexbox
Positioning
Current best practices such as SMACSS or BEM to keep your styles modular and easy to maintain
You don't need to know this all up front, but you should continue pushing forward. Just as with other languages and programming in general, you need to continually seek to learn more and master the craft. CSS is a fundamental part of web development, and more developers need to treat it with the same respect they afford other languages.
Related
I am interested in improving my understanding of CSS. I have been making web pages for a while, but I am still constantly thwarted by bizarre behavior that I can't explain when I try to get things to look the way I want. I have a good bit of development experience and I have no trouble understanding the finer points of Javascript, PHP, or even C. But when it comes to CSS and HTML, I find I am always trying to "trick" my code into working.
This must betray a lack of understanding on my part about how web pages and CSS actually work. Are there any good books or resources I could look at toward the end of truly understanding what is going on under the hood? I always feel like I'm at a loss, but I suspect I could get over that if I just cracked down and did some good reading.
I find I am always trying to "trick" my code into working.
Yep. CSS is often about creating the illusion of the effect you intend, rather than actually doing what you intend.
That said, there are very specific rules, as specified by the W3C. Understanding the visual formatting model can do wonders for your understanding as well. These specs are dense, and often confusing, however, so figuring out specific properties and building knowledge step by step is often the easier way to go. Find tutorials (see links below), or just play with them and see what happens (that's how I learned float and clear).
Even though it's often dead, there are a few SO users who will check the CSS Chat Room regularly (myself included), so if you have general questions (inappropriate for an actual SO question), feel free to ask there, and someone will eventually ping you back.
Also, I've created a Useful CSS Links document with links to official documents, several tutorials, and other CSS resources.
You might be getting mesmerized by the pretty blinking lights and forgetting to watch how everything is connected together. Just like you can get too focused on how a node in the DOM is affected by your javascript, you can't forget about the parents and siblings and how they all fit together. Your biggest problems are probably positioning. Remember how all the elements are connected together and that will solve a lot of confusion.
I'm sure you've already been here, but just in case:
Learn CSS:
http://w3schools.com/css/default.asp
Learn CSS3:
http://w3schools.com/css3/default.asp
However, the best way to learn this stuff is by trial-and-error. HTML and CSS are unique in their forgiving approach to malformation/errors. This, along with the fact that no two browsers render HTML/CSS exactly alike, presents a certain ambiguity that even experienced HTML/CSS developers occasionally grapple with.
Still, learning this stuff is a blast, and really rewarding once you get a handle on it. Happy coding!
I'm faced with a business requirement that I believe may be solved by implementing CSS variables.
Basically, while the front-end developers on this project are in charge of CSS implementation, the designer wants to be able to introduce different "themes" for the site.
By swapping one theme for another, a range of changes (such as font-size, font color, border width, etc) can be made without having to change too much code.
Currently we're trying to fit this requirement by splitting up the styling of components into different CSS files - e.g. one for layout, one for typography, one for colors, etc.
But I don't like this approach. It makes the CSS quite unmaintainable, and it's difficult to separate out all the CSS for one particular component, which is becoming a frequent requirement.
I'm hoping to instead introduce a standard set of "variables", which can be tied to a particular theme.
The CSS will be pre-processed and the variables will be swapped for the actual value depending on the theme used.
This will enable us developers to organize our code most effectively, while still keeping it flexible enough to be customized according to the designer's tastes.
Any thoughts on the pro's/con's of this?
The only disadvantage that I can think of is the added complexity of having to use or write a pre-processor, and appropriately manage the caching of the output in order not to have each request pass through the pre-processor.
You might also have some issues with syntax highlighting in editors when you use your new variable syntax, but that can probably could be solved.
Apart from that, I guess it should be all advantages.
You might be interested in checking out LESS:
#brand_color: #4D926F;
#header {
color: #brand_color;
}
h2 {
color: #brand_color;
}
Pre-processing a CSS seems like a good idea. The disadvantage I see is that, this additional abstraction will entail its own problems - bugs in the processing code might lead to an invalid or buggy CSS. Overtime things might become difficult to maintain.
You might want to have one fully working CSS without the variable, and then have another pre-processed CSS with the minimal required variable stuff, which overrides the original CSS.
I don't see any improvement over just having different css-files for the themes: You say you just add some variables to change fonts, colors and the like. What about borders, alignment and a lot of other stuff? Themes are not just 2-3 color variables. A theme for a bigger webpage can get pretty big and different themes for the same page might not only differ by a few colorcodes. I don't think it's a good idea. Let the front-end designers just create different css-files for the themes and load the css-files that belong to a theme.
A big disadvantage is certainly that you aren't writing CSS anymore. You are writing in a proprietary language, that compiles to CSS. Inventing your own programming language is on page one of the things-that-are-a-bad-idea-for-business book. If you are doing this as an experiment or for a personal project, then go ahead, but otherwise I'd say that you're asking for trouble.
A concrete problem I could foresee is that developers might have editors/IDE's that knows how to deal with CSS, but don't know how to deal with your dialect of CSS. That could restrict said developers quite a bit.
But really - The point isn't listing up pros and cons. The point is that you're moving into uncharted territory, and that's - out of principle - a bad idea, unless it's your core business.
Edit:
I'd just like to moderate my answer a bit. From a technical perspective, it may well be a good idea - Depending on how well you control your environment, how able you are to retrace your steps and a lot more. This is essentially a type of external-DSL, which can be a very powerful instrument. I don't think I would apply it here though, since you're targeting (frontend) developers, and I think external-DSL's are better used at administrators/non-developers. But it could be used successfully.
My main concern is that you're only approaching this from a technical point of view, which is a common fallacy for us developers. From a business-perspective (assuming you are a business), it's probably a really bad idea. That's what I was trying to voice.
Is there anything that CSS Frameworks give that its not easy to make yourself?
The main use I have for CSS frameworks is that they tend to force you to think about how you're going to organise you code rather than provide you with indispensable tools for your day to day tasks.
For that reason, I'm a fan of boilerplate rather than things like blueprint as boilerplate tends to focus on how you structure your css stylesheets and imports rather than providing you with a collection of semantically confusing helper classes.
They are simply a convenience and as such are good for things like wireframing and rapid prototyping. They are probably also a good way to learn CSS layout aswell if you can familiarise yourself with the layout code.
What I don't like about CSS frameworks is that they encourage the use of non-semantic class names and are a bit heavy handed for a simpler designs. I still think it's very important to understand how CSS layout works and not to just rely on the frameworks because you'd be limiting your creativity and what you could achieve. Sometimes reading CSS files from the csszengarden site can teach you things you weren't sure of how to achieve.
For wireframing this is the most promising CSS framework I've seen:
http://designinfluences.com/fluid960gs/
I think that all depends on your own knowledge and the project. If you have a lot of small business clients, or for other reasons makes a lot of similar designs, I think it saves some time to use css frameworks. And you save time for browser bugfixing, but you should always test anyways.
But if your CSS skills are good, you know the most common IE bugs and how to hack them, I dont see any need of using a framework in most cases.
A reset stylesheet of some description is a worthwhile starting point.
For example:
http://developer.yahoo.com/yui/reset/
IE6 compatibility.
given that you are already familiar with one particular framework, it's easier and quicker to do certain common grid layouts. You might want to learn and try to stick with a framework if you are doing a lot of CSS.
Blueprint CSS is the CSS framework I prefer.
Yes, testing testing and more testing. Do you have time to test and debug your code in all browsers? If you have it's the best to write your own code. If you need quick solution you can use some framework. I wrote one post about this subject: http://www.vcarrer.com/2008/08/when-to-use-css-framework.html
It depends on the framework and your end-goal.
A lot of times they can work as guides with pre-defined templates to aid your development effort. But other times you just want your page to look nicer and not have to deal with actual work on CSS files. In the latter, you can skip the "make yourself" part altogether, and invest more effort into other parts of your project.
Take Skeleton and Tacit CSS frameworks for example. Both are pretty much minimal frameworks. The first is more centered on providing easy to use and adapt the boilerplate code and comes with a moderate amount of utility. Tacit on the other hand is a CSS framework for dummies, for people who, for example, have no interest in working with CSS but still want to get a nicer display look than the default CSS-less HTML display, and they want this out-of-the-box, not having to work with CSS classes.
i think that compatibility of any kind is best achieved when we band together, whether it be using CSS or Javascript frameworks, there's bound to be more chance that bugs will get fixed and wishes will get granted. there's also the chance that similar interfaces reduce the amount of training required for new users of your site.
I would never, ever use a CSS framework. They don't make anything faster or easier, increase code bloat and make debugging or testing much harder. If I do use a CSS framework to start with, it looks like this:
body {}
In what way would you ever need more than that? the baseline starting point should always be what the browser displays by default, nothing more.
Reset CSS stylesheets cause the same problems.
eg: http://withoutsubstance.blogspot.com/2008/09/why-you-should-never-ever-ever-use.html
I've worked with 960 a bit and found it's great for prototyping but I'm not a fan of putting it into production. I find the use of float makes my head hurt a little.
There's a common misconception that frameworks == bloat and another that a particular implementation of a framework represents the definition. A framework is just a tool. Here's an analogy: If you need a spanner to fix your car, you shouldn't throw away your screwdriver set.
If you've found that the frameworks you've looked at aren't suitable to the task at hand, you shouldn't write them off. You can easily make your own or use frameworks when they suit your needs.
I tend to take the academic approach all too often and adhere to strict principles in my development when the reality is that I could have finished the project sooner had I been a little less cautious. I'm looking to find the right amount of practicality.
I want to take the "Zen" approach to designing a site which (in my words) says "Use HTML strictly for content structure, and let the CSS magic do the rest". How practical is this in reality? One of the issues I run into is that I want to develop (make functional) the site first, then come back in and design it later. I know structure-wise how I want the site to flow, but I haven't even begun playing with the CSS layout, graphics, or any of the other designy stuff. What is the right approach here?
It's absolutely practical, and provides infinite benefit. In fact it's exactly what CSS and the separation of content and layout is designed for.
The right approach given the above, is to let different teams get on with the different tasks at hand. That requires (perhaps) an initial graphic design which can be quite rough, and a documented and collaboratively agreed set of naming conventions for things like "#viewport", ".user" etc..
The markup team will usually be backend driven and will usually lead the design team slightly, but they should and must remain flexible enough to change markup where required, or put that in the control of the designers.
This last is just my $.02, but where one person is both roles, again I think you lead yourself with the markup/backend first and then iteratively go to a design stage, then markup, then design, as required.
The approach you want to follow is the right one. Just two things:
If you use a validator for css or html, don't pretend that all your html or css pass the test. Obviously the ideal goal is that everything validates, but at a first stage I think is better not spend a lot of time in validation issues. And remember that no one validator is perfect, and the good way to use it at the beginning is to guide you in the right direction and avoid big mistakes (i.e. put the same id twice in one page, or put block elements inside inline ones...). Then, when the application is at a good stage, you can make your css and html perfect and valid.
Don't design the interface at the end. I think that the interface of the application can give you good directions in how develop your back-end too. So, at your place, I would design the interface first, with html and css, and then I'd start to add functionality to it.
(Sorry for my english, spelling corrections are welcome.)
It can be very practical and you will be suprised how clean your HTML looks. I like using a CSS reset file to help get started, I personally like the YUI reset. Another Zen item to consider is the use of unobtrusive JavaScript. This further separates the different layers of your code. JavaScript libraries, like jquery, prototype and dojo can help with this.
It can be done, and I think your site (and your web design skills, not least) will be much better for it. But it also has a certain learning curve. It requires a more thorough understanding of the XHTML/CSS specs than many people have.
Making sure your HTML can be validated is just the beginning.
Oh, and make sure all browsers run in strict mode when rendering the page.
Of course, you will require workarounds for IE support, but that can be done with several methods.
First, IE supports conditional comments, allowing you to include special CSS stylesheets just to fix IE bugs, which should get you most of the way, without affecting your compliant standard-version of the page.
For some things, you may need a bit of javascript as well, but it shouldn't be necessary for most common functionality.
There are reasons explained in http://www.webdevout.net/articles/beware-of-xhtml against using XHTML today. To summarize, XHTML is not supported unless you serve it as such and if you target older browsers (any IE version is old considering most of its features are implemented when they were still immature and not changed substantially for a while) you have no choice but serve it as HTML.
Unless you don't require features that being XML provides (like SVG, MathML), stick with HTML. You won't have any serious advantage over HTML, be any more semantic, have better CSS support (even less). But you get wider compatibility and your layout will be more predictable (for example table cells can inherit from first cell in the row in HTML, no such thing in XML, not even sure XHTML has any exceptions somewhere).
Validators won't help writing XHTML any more than HTML. Even annoy, if you use a strict one, leaving you wondering what is all the fuss about / in the br tag if you lie and say it is HTML. (Firefox view source shows it bright red if you serve XHTML as HTML). I am sure you can find more examples.
Sure, you can do that, but be prepared that it WILL NOT render under IE. On a recent web project, the majority of our front-end defects were fixing stuff in IE that already worked fine in Firefox. Maybe this will change in IE8, but I doubt it. In some cases we even had to write some javascript that would be executed on IE only to work around things that couldn't be done with just CSS.
while it sounds good in theory you cant create the layout for a site 100% with css. You still need to use some markup so that you have something to apply the css to. That said, you can come fairly close to ideal using this method. I'm constantly amazed at how little markup a true css guru actually requires.
closer the "zen" approach that you are really looking for is xslt. it works by your app generating xml data and then the xslt transforms that xml into html/css. this requires learning xslt and adds another layer of complication to the process of generating a page, but adds the separation you are looking for. In an ideal world the theory is that a programmer only has to worry about generating xml data and then a designer can generate the visuals using that data, however it rarely works that way as xslt is more technical than most designers can handle. Most of the time the programmer ends up generating the xslt which somewhat defeats the purpose.
One approach that works for me is to structure the HTML first, then add some minimal CSS in a tag in the same file (just enough to create the right layout etc). Then once you're happy with the structure, you can pull the CSS out into separate files and / or completely rework the CSS. This strikes the right balance for me - it's still a lightweight process, but it avoids the potential headache of finding and replacing inline CSS.
In theoria yes, in practice, browser differences may force you to add a bit of javascript to deal with the differences.
Now... Benefits of something is different from practicality of doing it. Are you guys forgetting IE or even the pain-in-the-whatever client who wants the impossible done?
I am tempted to say you have to make some exception to the strict DTD that you are using to make it work in a reasonable set of browsers and please your stakeholder for the website/web-app.
I am a standards freak and no one would be more happy than me if it was possible to build a website that doesn't violate even 1 DTD rule. But after 4 years, I just haven't been able to do it for practical purposes.
Sure if I am the one coming up with the requirements for the website I am going to develop, it might be possible, but I have to bend the business rules to accommodate that. Believe me, that's the only way it is possible.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Reading on another forum I've came across the world of CSS Frameworks. The one I've been specifically looking at is BluePrint. I was wondering if anyone else had come across CSS frameworks, suggest which is the best and if they are worth the effort?
CSS 'frameworks' are completely missing the point.
CSS is not like JavaScript, where you can include a base library/framework and then call functions and objects from it to do higher-level work. All a CSS framework can give you is declarative rules: some default browser-rule-reset stuff, some class styles to be forced to author your page to, and layout rules using 'float' and 'clear'. You can write that in a few lines of CSS yourself rather than pulling in the bloat of a hundred framework rules.
The 'grid layout' stuff in particular goes back to the bad old days of mixing your presentation into your markup. 'div class="span-24"' is no better than a table, you'll have to go back in there and change the markup to affect the layout. And all the frameworks I've seen are based around fixed-pixel floated boxes, making it impossible to create a liquid layout accessible on a wide range of window sizes.
It's backwards authoring, of use only for someone too scared to write a CSS rule.
So, nobody's responded to this question yet (although I've seen a few upvotes), so I am going to at least attempt to tackle the second question in this prompt.
CSS Frameworks are great; like any other framework, they reduce development time and let you get working immediately on site-specific design and CSS. They think about hard decisions so you don't have to.
Unfortunately, there are two downsides to using a framework (in general):
The framework dictates the overall structure and mechanics of your CSS code. Now, I'm not talking about a CSS reset (these are useful in their own right, but they are not true frameworks); I'm talking about an honest to good framework, that has already made the decisions about what semantic tags you are going to be using in your document, etc. As such, you are made dependent on the framework, and when there is a bug in the framework, you will most commonly have to fix it yourself.
Frameworks are not an excuse for being oblivious to cross-browser/advanced CSS issues. You will invariably run into them, just as you would working with a PHP or JavaScript framework. And you need to know how to deal with them. There is a common saying that you should write your own framework first, before using someone else's.
Taking a quick peek at Blueprint, I would not really call it a framework; maybe a reset with a few extra goodies on top.
I've looked at BluePrint and a few others and the only CSS 'framework' I'd recommend is YUI Grids
Pros:
Written by one of the best frontend engineers out there (IMO) (Nate Koechley)
Very small. 4KB
Very flexible (1000 different layouts)
Supports fluid-width (100%) layouts as well as preset fixed-width layouts at 750px, 950px, and 974px, and the ability to easily customize to any number.
Supports easy customization of the width for fixed-width layouts.
Template columns are source-order independent, so you can put your most important content first in the markup layer for improved accessibility and search engine optimization (SEO).
Self-clearing footer. No matter which column is longer, the footer stays at the bottom.
Layouts less than 100% are automatically centered.
Somewhat semantic classnames (better than top, left, right, etc)
Cons:
Lots of extra markup compared to hand-written HTML and CSS
Takes some learning to figure out how to do complex layouts
As other have posted, there are no real 'frameworks' for CSS. Reset stylesheets help a lot with layout too. I usually stick with a reset stylesheet and go from there. But if you don't have a lot of CSS experience YUI Grids could save you some time.
Compass is an actual CSS framework in the sense that it gives you not only templates (both YUI and blueprint), but also reusable constructs and higher-level declarations while still giving you familiar CSS syntax.
Take the time to study and understand (really understand!) a few css frameworks such as BluePrint and YUI, and css resets like Eric Meyer's. Then, take the time to put together your own reset and/or framework based on your work methods and the kind of sites you build.
Personally, I use most of the Eric Meyer reset with some classes and resets of my own, plus a few ideas from BluePrint and YUI.
I recently watched Eric Meyer give a presentation on CSS Frameworks in which he asked the question: "so which one is the right one for me?" He then answered the question by showing a blank slide. His point was, that there are certainly some useful concepts built into most resets and frameworks, but the one that will suit you the best is the one that you write for yourself (it's worth the effort).
Why use css 'frameworks'?
If you are pressured for time.
If you do not know css, and don't
know someone who can write it for
you.
If you are not overly precious about
standards etc.
I know programmers who have been really happy to use blueprint or 960, as it allows them to put together a layout on their own, without turning to a front-end developer. This is ideal for personal projects, or startups with limited resources.
If you have decent knowledge of CSS already, then presumably you have a decent library of stock layouts already, so you clearly won't need a framework.
However, if you're a beginner and just need to get something up and running, then you might turn to a framework, as it makes basic layout much simpler, and tackling browser compatibility also.
Having said all that, many frameworks out of the box do make use of some horrible class names etc. I know of some websites that have taken a framework as a starting point and then customised it with their own class and id tags. But clearly there's a bit of work involved in that rewrite too. Using something like Compass, as mentioned above, does help to get around that.
So, CSS frameworks - they can save you time, at the cost of semantics. They might also hurt your knowledge of CSS, but that is more up to how much you invest in learning the subject in general. Whether you make use of them is up to you.
You'd have to ask yourself how effective the available frameworks are at solving your problems. Do they meet your requirements?
By using a framework, you can set some rules or details at the pixel level and devote the rest of your time to implementing and producing. It's a massive productivity boost. If you find yourself spending time adjusting things by a few pixels late in the project (micro managing the design), it's a sign that a framework can be useful.
Tip #17 in The Pragmatic Programmer says: "Program close to the problem domain". Using a layer of abstraction can get you closer to solving the real problems of layout. For example: you might be able to concentrate of enhancing the user experience with the extra time you have rather than minor adjustments of pixels.
This is not to say you must sacrifice quality for quantity. It's about efficiency.
On a recent project, I made my own framework because we had very limited resources and the popular frameworks didn't do what I wanted. Then, I set up the design team's PSDs to snap to the same grid I deployed.
A framework doesn't have to be any particular implementation of CSS. It doesn't have to be something bloated you downloaded from the interweb or something implementing outdated ideas. It's just a technique for getting a job done. I wouldn't be surprised if some coders already have their own frameworks and don't even know it. In fact, if you consider the DOM as a set of default elements you extend with CSS, then that's a framework by definition.
I actually spent a good portion of the last 24 hours investigating this on my own, heh. My conclusion was that a nice reset (I used YUI Reset), and maybe something else to set baseline stuff (YUI fonts was worthwhile in my case; maybe the "extra goodies" of BluePrint would be in yours) is a good idea. But, a "framework"---which is generally something like YUI grids---is too restrictive, forcing you to use their class names, ids, etc. and rarely fitting into your site like hand-made CSS would.
So in short: resets seem pretty nice; it's good to eliminate all the variation in e.g. margin-vs-padding for lists, or paragraph spacing, or whatever. But that's as far as I would take it.
i haven't used it yes, but i think emastic may be a good alternative worth a check. it it is similar to blueprint in scope, but also supports elastic layouts (hence the name) and you can specify values in px, em or %, and even mix them.
Compass I think is amazing. Make sure you see the screencast.
I am using 960.gs for a few websites and find it very simple and easy and worth the effort. Saves me a lot of work on layout. Make sure to check the custom CSS generator which goes away with the fixed width of 960 pixels.
I think that this video presentation by Site Point CEO Kevin Yank will answer your question. I really recommend to watch it.
Compass lets you rename your framework's classes and ids with your own semantic names, so you might want to check it out. It also provides access to stuff you just don't get with plain-vanilla CSS such as mixins.
I'm astounded by so-called "CSS experts" who criticize these tools without really having digged in and used them. Are they essential? No. If you like your own framework (you do have one of your own, right? A CSS framework is just a carefully defined library--everyone should be using one) then by all means, keep on using it. No one is forcing you to use other frameworks and I don't see people who are using frameworks telling CSS purists that they are "doing it wrong."
Criticizing frameworks from such a standpoint just reveals an insecurity as well as an ignorance. For example, the notion is laughable that a person would use a tool like Compass without knowing CSS. You realize, right, that a framework generally doesn't write all your CSS for you? You can still break out and write your own CSS within the context of most frameworks. In fact, if you don't know CSS you might get frustrated quickly.
For myself, I appreciate having a framework because it is already documented, tested by hundreds of other users, and I can apply my own classes and ids via Compass. If I need something that the framework isn't suitable for, then I'll code my own.
Matt Raible of AppFuse fame had a CSS Framework contest a while back to develop CSS Frameworks for AppFuse. The results are published here. There are a few variations and I have used some myself because I use AppFuse and find them very good.
I should add that these CSS Frameworks work well because they are used in themed applications. That is, if you stick to the rules then switching from one to the next is as simple as changing one value in a properties file.
I have used BluePrint with much success on a site (I could mention the site here but I am sure the post would be marked as spam!). I am not sure if I will use it in the future though because one of the ideas of CSS i thought was to not have layout logic hard coded. You shouldn't have css elements called span-24 and span-12 to define the layout but something like searchBox and mainContent. At least thats how I see it.
Good link I found : Top 12 CSS Frameworks and How to Understand Them
Here is my blog post about CSS Frameworks When to use CSS framework?
The only way I know of to use a CSS framework and retain semantic markup is to use a higher-level abstraction. At the moment, Compass is the only one I'm aware of that's mature enough to use, but Nicole Sullivan seems to be doing some interesting stuff with her "Object-Oriented CSS" project.
I find Compass' clever use of Sass mixins to be brilliant, and a big step toward the Holy Grail of maintainable semantic markup. I don't think I'd want to use a framework like Blueprint or YUI without an abstraction such as Compass to keep presentation classes out of the markup.
BTW, there's a nice-looking CSS framework called Elastic that looks good enough that I'm considering adding it to Compass.
I believe CSS is about simplicity. The goal is to have one or two places to check when you're referencing between the HTML and your stylesheet. Adding more lines, and especially lines that you did not write and are probably not that familiar with, will exponentially increase the complexity thereby volatility of the CSS code.
I would suggest your layouts as you write them and develop a generic template system from that. While I love making CSS more modular, often and depending on the design, your CSS may be very case-specific and not modular at all.
I've used Blueprint on a few one-off sites and it definitely saved time, primarily in cross-browser testing.
It definitely sucks adding presentation code to your markup, although on the bright side it's readable. While I love the concept of "you can redesign without touching the markup", if you're producing a site where that really isn't going to happen anyways and you just need it done yesterday, Blueprint is something to look at.
There are also tradeoffs in what types of layouts it can feasibly create though. If you wireframe the site from the start on a strict grid, it will be much easier to transpose into the framework with a minimum of fuss.
I have used BluePrint and YUI but I always get frustrated with some of the names they give their id and classes.
To each their own, but I prefer doing things from scratch, but after a while you develop a process in which you will use your previous work and apply it to new projects and just make some tweaks to make the web site look the way you would like it to.
Be sure to use a good naming convention, just in case someone else down the road comes in to edit the css, then they will have a good idea what each style name is referring to.
Craig,
Compass is what you're looking for: it allows you to rename your Blueprint CSS classes like "span-24" with your own names. It also expands CSS functionality with variables and mixins. Truly, those that prematurely judge frameworks without having checked out Compass are "missing the point." It's sort of like those folks who told us years ago that we are missing the point by using CSS instead of HTML tables for our layouts.
-Matt
check out http://www.ez-css.org/. one of easiest and lightest css framework to work on. :)
Take a look to this demo:
http://www.richstyle.org/demo-web.php
This framework is based on idea that "HTML tags should be enough".
I think re-usability is the most important factor for choosing a software component, including a web framework.
For web frameworks developers, the more you commit to standards, the more you guarantee re-usability.