Over the past several weeks, I’ve been bombarded (in e-mail, in person, and over IM) with questions about CSS frameworks. I guess I wrote the book on this topic (and contributed, if inadvertently, to one of the most notable CSS frameworks out there), so it’s completely understandable people would come to me with these questions. The question almost always sounds something like this:
I’m convinced the people railing against CSS frameworks are just trying to drum up some false job security.
“I’ve read what you’ve written about CSS frameworks, and it sounds great…but [insert name of a usually-British CSS guru here] said they were bad. What do you think about what they have to say?”
Most of the folks that seem to be very anti-CSS frameworks have the following traits in common:
- They are friends of mine. I think we’re all grown up enough to debate this without it getting personal, but I’m not going to name names here, because I just don’t think it’s necessary to make my point.
- They make their living off writing CSS. That is to say, anything that makes CSS easier for the average joe makes them somewhat less valuable — their agenda is pretty clear.
- They’re British. This is totally irrelevant and doesn’t mean anything — I just think it’s interesting. They’re not all form the UK, but it does seem like most of them are, which is just a little weird. :)
So it’s been made clear to me that these folks don’t like CSS frameworks and don’t think they should be used (except, in some cases, for rapid prototyping). What’s not clear to me is why they feel this way. So, I’m asking publicly, and hoping these folks will show up here to give me their answers: What is it about CSS frameworks that bothers you?
A few preemptive notes about what I suspect may be some of the answers:
-
Some people say CSS frameworks are “un-semantic”. I’ve yet to see one that is “un-semantic”. None of them (that I’ve seen) encourage using presentational elements (like
b,i, oru), or using elements for purposes they weren't intended for (liketablefor layout). The ones I know of encourage semantic, valid (X)HTML, so I'm not sure where this argument against them comes from. - Some people say that CSS frameworks are “bloated.” I’m not sure at what point something becomes “bloated,” but the two most popular CSS frameworks, YUI and Blueprint, both weigh in at under 13k. Unless you’re building a mobile site or some other site where bandwidth is an extreme concern, I can’t see how 13k could possibly be a problem.
- Some people say that CSS frameworks encourage the use of lots of presentational class names. To this, I have three responses: First, CSS frameworks in general don’t encourage this. Some CSS frameworks use presentational class names for some of their components (YUI and Blueprint both use presentational names for their grids components). Many CSS frameworks don’t use any presentational class names. Second, CSS 3’s multi-column and advanced layout modules aren’t practical yet, so if you want to do complex, grid-based designs, how else are going to do them? And third, how do these presentational class names hurt the site? Do they negatively impact the user or business goals? I don’t think so. They only thing they hurt is the feelings of semantic markup nerds who go poking around the source of other people’s pages (apparently, they’re down with OPP).
Also, I’ll say this: CSS frameworks are not for everyone, or every situation. They’re especially great for those working on tight deadlines and those working in teams (teams wherein multiple people work on the same CSS — they benefit from having a consistent set of coding patterns), and also for those working on several sites of a similar nature (for example, a team working at a news company which runs 20+ newspaper sites). I’m definitely not trying to say everyone should be using CSS frameworks — but I think it’s inaccurate for these folks to be publicly saying that no one should be using CSS frameworks, too.
So, with all that having been said, I have a few questions for the peanut gallery, especially those of you who have been publicly railing against the use of CSS frameworks:
- What is it about CSS frameworks that bothers you so?
- Do you want CSS and (X)HTML to be easier for everyone, or would you rather it be a highly-skilled craft that requires the assistance of experts?
- Why is this just coming up now? Why did no one mind when Yahoo released their CSS framework, but people are bothered by Blueprint? What’s the difference?
- Do you simply oppose the idea of frameworks as a whole? Do you also dislike the JavaScript frameworks that have been so popular recently? Do you also dislike backend frameworks like Django, Rails, and CakePHP? Or is there something specific to CSS that renders it somehow inappropriate for these frameworks?
I hope to get some great answers, as this is a topic that interests me a lot. My gut feeling is that many folks who make their living off writing semantic (X)HTML and CSS are getting scared. They’re realizing that CSS and HTML are actually pretty darn easy, especially with the aide of tools like frameworks. They’re realizing that the only hard thing about writing CSS is troubleshooting lousy browsers — and they’re realizing that lousy browsers are fewer and farther between than ever, and getting fewer every year. They’re realizing, quite frankly, that their skill set may be less valuable in the future than it has been for the past couple of years.
I’d love to be proven wrong, but until someone speaks up with some good reason why CSS frameworks shouldn’t be used, instead of simply asserting that they shouldn’t, I’m convinced these folks are just trying to drum up some false job security.
Update: I’ve posted a follow-up to this entry.
Comments
There are currently 122 comments on this entry. If you have something to say, please consider adding your own.
You can also subscribe to an RSS feed of this entry’s comments.
Links in this entry
This entry’s tags
AuthenticJobs.com
- Web/Graphic Designer Extraordinaire
- Aimed Arrow, LLC
- Senior Web/UX designer
- TechnoPhobia Ltd.
- Sheffield, GB
- Interactive Developer/Technical Director
- Simply Interactive
- Austin, TX, US
- Web Developer
- Bantr
- San Francisco, CA, US
- HTML Developer
- Smith Brothers Agency
- Pittsburgh, PA, US
- Redonkulous Web Developer Wanted
- OnWired, LLC.
- Cary, NC, US
- Software Architect
- Arc90, Inc.
- Midtown East, New York City
- Web Developer
- Mekanism
- San Francisco, CA, US
- Flex User Interface Designer
- THINK Interactive, Inc.
- Atlanta, GA, US
- Front-End Coder (HTML, CSS)
- Muse Weddings
- New York, NY, US
001 // Mike D. // 11.17.2007 // 7:18 PM
Ouch… shot across the bow to the limeys! Maybe it’s the food.
002 // Jeff Croft // 11.17.2007 // 7:20 PM
Mike D., always the instigator!
003 // Stephen Caver // 11.17.2007 // 7:33 PM
I found the CSS framework I used to be limiting and had to go back and do some strange things to work with it. In the right design context it’s pretty powerful stuff, definitely and I’m totally open to using it in those circumstances. But with some advanced things its sometimes easier (at least for me, not saying this is universal) to start from scratch. At least with regards to the grid frameworks.
Now, the typography styles in frameworks I’ve found to be the exact opposite. I find that to be much more useful and easier to expand upon. At least, that’s my experience so far with them.
004 // Travis Isaacs // 11.17.2007 // 7:56 PM
I just finished (literally) a reboot of my personal site today. I went from comp to live site over the course of two days. A big part of that due to blueprint.
I’ve coded a lot of websites in the last 5 or so years. I quickly realized that no matter how different the sites are, I have to set the grid, baseline the browser styles, typography, browser testing, etc. Why start from scratch each time?
005 // Jonathan Christopher // 11.17.2007 // 7:59 PM
My initial reaction to the idea of a CSS framework was a lack of interest. With the release of Blueprint, more and more people began talking about it as a legit option. I looked into Blueprint in more detail, and also checked out some others (such as Tripoli) and I was pleasantly surprised at the organization. I thought about whether or not a CSS framework would be useful for me personally, and came to the conclusion that it wouldn’t be. I wrote a couple pieces on my reasoning, and also asked for the thoughts of others. There were some great replies, both in support and opposition to the idea.
At the end of the day, the pros and cons behind a CSS framework are very similar (if not identical) to any other framework whether it be based based in JavaScript, PHP, or otherwise. There will always be the problem of “learning the framework” as opposed to really learning the underlying technology. The major benefits come from organization and (production) speed enhancement. When it comes to CSS, however, for me I really don’t think a framework is going to help speed things up. As Stephen Caver mentioned above, I have found it both easier and quicker to put a stylesheet together from scratch as opposed to building the foundation with a framework.
As a direct effect of my opinion, if I were to be asked by someone very new to CSS whether or not he or she should work with a CSS framework, I would leave my personal opinion and suggest not.
When it comes to job security as one who works primarily with (X)HTML/CSS, I think there’s enough of a line between professionals and ‘that kid down the street who makes Web pages’ where mass CSS framework adoption wouldn’t bring an influx of self-proclaimed CSS gurus. As I see it, the developers working with and writing about CSS frameworks aren’t using them in an WYSIWYG editor.
I’m glad to see that other people are still wondering about CSS frameworks and their place — I really look forward to keeping an eye on this comment thread to read some more opinions.
006 // Jeff Croft // 11.17.2007 // 8:05 PM
@Stephen: Good feedback. Like I said, frameworks aren’t for everyone. If they don’t work for you, that’s totally cool. At least you’ve given them a go and know for sure.
@Travis: Well-said. And, lovely looking site you’ve got there!
@Jonathan: Also good feedback. Again, it’s good that you’ve actually looked into Blueprint and others before making judgement. It’s totally cool that they didn’t work out for you personally.
Just to be clear, I also don’t think CSS frameworks alone will create a situation where CSS experts are meaningless. But, I do think the days are numbered for people who have been making a good deal of money off simply writing semantic (X)HTML and browser-proof CSS. CSS isn’t only hard because of browser bugs. As browser bugs become fewer and fewer, CSS development is going to be get a lot easier for a lot of people. This is why I’ve sid in the past that web professionals really need to have some other skills (be it design, programming, copywriting, etc.) to complement HTML and CSS — I just don’t see HTML and CSS expertise being that valuable of a skill in the future.
007 // Jeremy Rickketts // 11.17.2007 // 8:06 PM
Quote of the month…”how do these presentational class names hurt the site? Do they negatively impact the user or business goals? I don’t think so. They only thing they hurt is the feelings of semantic markup nerds who go poking around the source of other people’s pages (apparently, they’re down with OPP).”
haha
I’ve slowly been warming up to the idea of using a framework, especially when marking up more complex grid layouts. The advantages of having a workable, intuitive framework making sense of what could otherwise quickly become a massive, complex stylesheet seem pretty clear. Sure, there are “un-semantic” class names, but really… show me the best designers in the business, and I’ll find you some presentational classes in their markup. Having a class named “column” or “sidebar” is no different than than “column-span-3” in my view.
008 // Jeff Croft // 11.17.2007 // 8:09 PM
@Jeremy: I agree completely. And, beyond the advantages you note, don’t forget that using Blueprint or another similar framework takes a ton of the cross-browser testing and tweaking burden off of you — the frameworks have already solved most of these problems.
009 // Josh Nichols // 11.17.2007 // 8:35 PM
I have to agree with Travis. These frameworks are great for getting some base typography styles down, but with Blueprint I couldn’t figure out how to customize the styles for my site in a timely way. It was just easier to start from scratch.
I can usually take a photoshopped site mock-up and create a XHTML/CSS template for our content management system in about an afternoon. By the time I get to coding the hard stuff is done. We’ve finished the content inventory and info. architecture, created wireframes, and decided on a visual style. The XHTML and CSS are the easy part. I don’t see how frameworks could make it any easier.
The one trick I use to speed up the process is start with a default style sheet that I created. I can do that because all the sites I create all belong to the same university and need to have a cohesive feel.
You’re right when you say that CSS is easy. I think it’s so easy that you don’t even need a framework.
010 // Jeff Croft // 11.17.2007 // 8:40 PM
In other words, you’ve written your own CSS framework! Well-done!
Are you sure? If so, why did you write your own? :)
011 // Colly // 11.17.2007 // 8:56 PM
I think it is interesting that it is us “limeys” casting the negatives over the rise of the frameworks. This is probably because as a rule we are a miserable bastards.
I must admit that I have not really explored all these new-fangled frameworks yet, so I shouldn’t comment, but I will. Certainly, I don’t perceive any threat to what we all do, or a danger to what you see as our lofty positions as CSS oracles, authors, teachers or whatever. I mean, its just another tool, and probably a very welcome one. I can’t say until I get some time to truly investigate, but in general nobody I know is openly dismissing them, not even on our usually angsty mail list.
However, arch limey Mr. Malarkey and I were discussing frameworks during the witching hour the other day, and I think he has a lot to say on the subject. Something along the lines of “good for establishing a basic starting point and for resetting values, but be sure to rip out all the bloated crap first” - I paraphrase him there, but what he said made sense at the time.
Three years ago I was tasked with building a framework, based around a 12-column layout, which I called “Twelve-Bar Blues”. I was very excited about it and it was robust, until I realised that each time I used it, I’d basically rip it all out and end up with none of it. It removed the fun for me. By building from scratch, I can make sensible decisions about naming conventions as I go along, and this does lend itself to a more semantic approach - perhaps.
Until I have a play with frameworks, I’m unsure of how useful they are, but from my point of view, each site I build is entirely different, has an entirely unique approach and starting point, and the best bit is opening a blank text file and creating that wonderful CSS from scratch. That way of working won’t suit everyone, especially newcomers or those who like to build up a library of CSS snippets, but its the way I prefer to do things.
Ultimately, I have sensed worries from some quarters that frameworks don’t aid learning. Not sure if this is true, but certainly for years we’ve all been advocating that folks use text editors to create code and step away from things like Dreamweaver - so are frameworks a step backwards in this regard?
One thing I will be keen to assess is how, when these frameworks are created to handle key things such as cross-browser evils, they cope with the infinite complexities of inheritance and those all too familiar knock-on effects as new rules are spooned in.
012 // Doug // 11.17.2007 // 8:57 PM
I have been using blueprint since it came out. I find it really hard to criticize something that makes marking up content in ie6 easier. Blueprint allows me to be more agile and quickly adapt to my clients needs. I find myself concentrating more time on flow/design of the site, and less time on ie6 bugs. So far the only negative (well for my competitors in my field) is it makes the end product better.
013 // Jonathan Snook // 11.17.2007 // 9:04 PM
Using a CSS framework will do nothing to harm the job security of those who do purely HTML and CSS work. Certainly no more than JavaScript frameworks have hurt JavaScript developers and no more than Django, Rails or CakePHP have hurt the Python, Ruby, or PHP developers out there.
If anything, it just creates a greater delineation between the pro and the amateur when things break.
014 // Josh Nichols // 11.17.2007 // 9:06 PM
I didn’t think of it that way. I guess I did! :-)
I can’t brag too much. My framework only includes the body tag and about 5 other classes. I guess I’m all for very basic frameworks.
My point was that of all the coding I do — PHP, XHTML, XML, JavaScript, Actionscript, CSS, XSLT — CSS is the easiest one. I also find it to be the one that is the most fun.
015 // Ricky Irvine // 11.17.2007 // 9:10 PM
Over the past few years I’ve developed my own habits of going from mockup to code, which, in a way, is a sort of framework itself. I’ve looked enthusiastically at Blueprint. I love the idea of working with a standard framework for all projects. The only trouble is the time it takes to learn it’s ins and outs. I’ll be working with frameworks whether they are habitual or published. So, as I see it, I might as well conform to a standard published framework.
016 // Jeff Croft // 11.17.2007 // 9:14 PM
Spoken like someone who hasn’t actually used any CSS framework. :)
Certainly. And of course, custom-built from the ground up will always be better than using off-the-shelf components. I could say the same for you and your CMS choice, Colly. I could assert that you’re limited by using ExpressionEngine — for the perfect solution, you should write PHP from scratch for each and every site you build, rather than adapting to decisions made for you by the ExpressionEngine team. But that sounds fairly ridiculous, doesn’t it? What’s the difference?
I’d say the only difference is that we don’t have a CSS framework that is as robust and good as ExpressionEngine is — yet.
017 // Jeff Croft // 11.17.2007 // 9:14 PM
Not to be too blunt, but if a fucking inane argument. I could say:
This is absurd, right? Yes, frameworks and pre-packaged tools (in any language) probably make some people not learn the language itself. But why is this a problem? You use ExpressionEngine instead of using PHP directly. Why? I’d say it’s probably because you don’t need to fully understand PHP itself. ExpressionEngine does everything you need. You’ve made a sound business choice.
Some people may not need to fully understand the ins and outs of CSS. And, for those who do, none of the CSS frameworks out there today get in the way.
So then you don’t use the same CMS over and over, but rather write a unique one for each site — right? :)
Build up a library of CSS snippets? You mean — a framework?
They’ll cope with them the exact same way you do with your own code when the same thing happens: they’ll cross that bridge when it presents itself.
I know I’m being a bit harsh here, and you know it’s not personal, Colly! I really appreciate your feedback. And, for the record, the whole British/Limey angle was just a joke intended to lighten the mood of the post. Thanks for coming ‘round! :)
018 // Jeff Croft // 11.17.2007 // 9:16 PM
I agree. That’s why I called it false job security. I don’t think frameworks actually harm the job security of these folks — but they’re acting like they think it will.
019 // Dan Shields // 11.17.2007 // 9:40 PM
I agree with you on most of your argument. I think really the only problem have with a framework like Blueprint or YUI are the grid CSS files. No one can deny that they don’t end up creating a reset, typography, print or other CSS files when creating their own projects. Maybe not everyone separates the styles into these exact categories but we all do it to some degree. I think if your not going to use a framework, the base styles in these file are great to have as a reference when creating your own.
It’s totally understandable that you guys had to create the grid file as you did because there isn’t a way to abstract it to fit in a non presentational way that works for everyone’s project. I am going to be presenting at our local Refresh meeting on the different frameworks and have been really impressed with both of what you guys and the YUI team has done.
I am a front-end developer and standards/semantic geek but I don’t see a huge issue with a framework if it helps speed up development. Like you say, what are you really loosing by saying a div is spanning 8 collumns or whatever. A person can still slap an id on it and style it from their site specific stylesheet. The only draw back essentially is the fact there are a lot of classes that might of been avoided if you didn’t use the framework. With the id’s attached to the divs along with the classes a person could still redesign their entire site with a new skin if they made sure not to change the structure of their grid. That really is the only way anyone could get away with not touching their HTML in a redesign in the first place.
The one thing that I don’t agree with you on is your statements on how CSS and HTML are so easy and that people who code it aren’t really as important to the development process as a designer, engineer, or IA. I’m sure you are going to say that is not what you said but I did interpret it that way. I think there is always going to be a place for us front-end developers. I mean it is true that its pretty easy to get a shell of a website up, like a three column layout with header and footer is pretty simple its the rest of the design brought to life in that layout that is the tricky part, and you throw in working with Javascript, and the backend platform.
Really all that the frameworks do are get you that initial structure and thats the easy part of HTML and CSS. More power to you guys for giving us a great example of how to create our own frameworks for our internal systems. I doubt I will ever use blueprint as it is but I will definitely take snippets of it all and use it in my own.
020 // Colly // 11.17.2007 // 9:45 PM
Oh blimey. Right. It is 3.30am here, so I’ll do this quickly.
I’m not worried by anything you said in your two comments, as I made it clear I hadn’t used frameworks, and was referencing statements I have heard others say. I just thought I’d share what I have picked up from my fellow limeys, and also pose a couple of questions about frameworks before I dig in and give them a go. The limeys thing is funny - don’t think for one second that offends any of us (not me anyway).
However, you make a lot of assumptions about the CMS we use (always, apparently), why we use it, and how we use it - and in some of what you said you are way off the mark. Still, you found a good method of ramming your point home with it. I think though that the argument/discussion needs to be wider than focusing on what one individual or company does, as everybody works in their own idiosyncratic ways across this multi-disciplinary industry.
The “library of CSS snippets” was indeed meant in reference to frameworks, my point being that many folks do use existing snippets or libraries but often they wouldn’t be so bold as to call them “frameworks”. You obviously missed my point on that one.
Interesting that you say the frameworks will cope with any inheritance issues when they present themselves, just like we humans do. How so? Are you suggesting that these frameworks can “think”? That is clever - maybe we will all be out of jobs if CSS can rewrite itself out of inheritance problems.
Back to my cave I think…
021 // Josh Nichols // 11.17.2007 // 9:51 PM
I have to agree with Dan on this. I can’t imagine using all of a CSS framework to save time, I’m too picky, but I could totally see myself using bits and pieces of it as I need it. Much the way you use a JavaScript framework. You grab the bits you need and cut out the rest.
022 // Doug March // 11.17.2007 // 9:53 PM
@Dan Shields - Don’t want to speak for Jeff, but I do not believe he was part of the team that created Blueprint. He is deff inspiration for it though. Blueprint was initially created by Olav Bjorkoy from Norway.
023 // Dan Shields // 11.17.2007 // 9:54 PM
I didn’t see the whole learning thing and just saw your responses. I totally agree with you 100%. Someone is going to have to know the principles of CSS to create a site with Blueprint. Otherwise your just going to have a bunch of crappy websites that look like the examples provided on Google :).
Just like in Rails the programmer still needs to know Ruby. Same for Django the programmer will still have to know Python. I really agree with this in terms of Javascript frameworks and how everyone says you don’t need to know any real Javascript to code with it. Sure this is true if your just slapping on some plugins and changing parameters but this isn’t the intention of the frameworks.
To use any of these frameworks on any real world web application the developer is going to have to know their stuff inside and out otherwise most likely the application will fail and no one will know how to fix it and then the owner of the site will end up starting all over with a new development team that knows what they are doing.
024 // Dan Shields // 11.17.2007 // 10:03 PM
@Doug March - I know that Olav is the one who created it but essentially it does come from Jeff and his former Colleagues, just with some adjustments and modifications. I guess really I meant thanks for getting the ball rolling with hyping up the frameworks, since Yahoo apparently couldn’t get this type of buzz for them.
025 // Joshua Bryant // 11.17.2007 // 10:31 PM
I was typing up a really long response to all this nonsense and then decided to delete it. It still bewilders me sometimes that it’s 2007 and so much energy is being spent on being negative about web coding tools/strategies. Seriously?
If a project ends up having the exact emotional response on the intended audience that the client wanted it to, and it functions exactly the way the client wants it to, what the fuck does it matter how it was coded or if a framework was used or not? I thought people arguing over web standards was a bit silly, and now people are arguing over what style of web standards to use? Whether or not to use a CSS framework strikes me as a personal preference, and one that should have no bearing on anyone else that’s not involved in that particular project.
And if people are so worried about their skills being irrelevant and loosing their jobs, then I might suggest they get off their ass and learn something new, valuable and marketable. Although I for one still believe there is plenty of room for quality front-end coding in a professional environment, whether its based on a framework or Mrs. Butterworth.
026 // Rob Goodlatte // 11.17.2007 // 11:05 PM
I’ve looked at Blueprint, and it didn’t really suit me. I didn’t really know why until I thought about it recently.
The problem I have is that Blueprint makes design decisions for you. You might say that’s a good thing, but every design calls for slightly different solutions.
Since Blueprint is a piecemeal framework, i’ll break it down by section:
Grids:
A 24 unit grid with 10px gutters and a 950px width doesn’t fit every project. And in order to come to that grid, you should be making justified decisions based on the design goals you have in mind. Going for a minimalist, type-centric design? Maybe a larger gutter width is called for. Maybe you want a 4:3 ratio between columns and sidebar — an 11 or 22 unit grid would make more sense in that case.
Forms:
All of the widths should tie into whatever grid I’m using. Color choices for things like error handling, link colors, and even border colors are heavily dependent upon the color scheme I use for the site. And aside from colors and widths, the rest is somewhat standard, but amounts to about 4-5 lines of CSS.
Typography:
This seems the most compelling to me, only because I don’t like defining styles for tags like dfn and pre. Typography is the only part I’d consider using, but I would likely spend as much time editing this as it would take me to write my own type styles from scratch. Give me some sexy stuff in here like fancy ampersands and nice acronym styling and maybe I’ll be more interested. But again, the typography for a project should be an informed decision, and not an automatic slap-on.
Reset:
Everyone already uses it, its great.
I don’t think anyone is concerned about putting CSS jockeys out of work. My concern is entirely over justifying design decisions — if you just apply Blueprint’s pre-packaged design solutions, you’re not really being a designer.
027 // Matt Robin // 11.17.2007 // 11:18 PM
I’m a friend (last time I checked), and CSS is one of the main things I use in Web Design, and I’m British…
As I haven’t bitched about CSS Frameworks…(not even once) - it must be one of those other British Geezers! ;)
What I know so far about Frameworks: it seems very useful. Note: I haven’t used it rigorously yet though.
028 // Rob Goodlatte // 11.17.2007 // 11:29 PM
Update: Just found http://kematzy.com/blueprint-generator/
Okay, the grid part is pretty useful.
</foot-in-mouth>
Death to CSS frameworks!
029 // Nathan Borror // 11.18.2007 // 12:33 AM
What do you really gain from a framework? A convenient way to float things and nice typography. The type part is great because it’s a pain to remember how things should line up and it’s easy on the markup. The layout part of frameworks pollute the markup with generic un-semantic class names. If you don’t care, use Blueprint. If you care about semantic class names, borrow a few things from frameworks and cook up the rest on your own.
We should be careful about propping up CSS frameworks next to OOP language frameworks. Not the same league nor the same sport. Bottom line is CSS is just a markup language and isn’t that hard to master which is probably why most CSS frameworks never catch on.
To each his own.
030 // Jeff Croft // 11.18.2007 // 2:17 AM
It’s not that I think HTML and CSS authors are any less important — it’s that I don’t think their jobs are as hard as those who do programming, design, or some other aspects of the web development process. Likewise, I don’t think a janitor’s job is as hard as a top executive’s might be — but it’s still and important job that needs to be done, and done well.
I agree completely, and I definitely didn’t mean to make assumptions about what you guys do or how you do it. I just made an example of you to make my point, and I shouldn’t have. Sorry about that, my friend.
I did miss your point, apparently. My bad. I’m still confused, though, as to why people that use libraries or snippets or reusable CSS are at the same time opposed to “frameworks,” when that’s exactly what a framework is. It’s seems hypocritical to me to say, “I don’t use a framework, I just use a library of snippets I’ve built up.”
Maybe I’m misunderstanding what you’re getting at, but what I mean is that they’ll deal with them just as humans do, because there are humans behind these frameworks. If there are bugs or issues with certain browsers, implementations of the cascade, etc., people will fix the bugs. That’s the beauty of open source.
Of course. Isn’t that the way anyone uses any framework for any language?
Hear, hear. Folks, this is probably the best comment ever posted on jeffcroft.com. Take notice!
031 // Jeff Croft // 11.18.2007 // 2:27 AM
@Rob Goodlatte:
You’ve retracted your grids comments now that you found the grids generator, so I won’t harp on those. But I will say that your initial reaction (“this grid is no good to me, it’s not flexible!”) is exactly the typo of FUD that is being thrown around about CSS frameworks in general. People that haven’t fully checked things out are spouting off about “it does this, and it doesn’t do this, blah blah” and they generally don’t know what they’re talking about. :)
I won’t argue with much of your Blueprint criticism.I actually agree with a lot of it. But you’re arguing against a particular CSS framework, not the concept of CSS frameworks. I was very conscientious to make this post about CSS frameworks, and not about Blueprint. I want to talk about the concept, not about individual frameworks. Saying you don’t like CSS frameworks because Blueprint didn’t work out for you is a bit like saying you don’t like automobiles because Hummers are total gas-guzzlers.
Yeah, but that’s not the point of Blueprint (or any CSS framework). The point isn’t to “just apply it’s pre-packaged design decisions.” The point, rather, is to give you a set of building blocks for you to design with. It’s like legos, man. You can build anything you want, we’re just giving you some plastic blocks to start with, so you don’t have to melt and mold the plastic yourself. YOu can use them, or not use, or use some of them, and also use some pieces you made yourself. It’s all up to you. YOu can build anything you want — we’re just giving you some blocks to work with.
This is great advice. Except, I think “un-semantic” is the wrong term, as I’ve stated in the post. Blueprint encourages semantic HTML. It doesn’t make you use
bor usetablefor layout. It does, however, include presentational class names (which in no way degrades the semantic-ness of your markup). If that bothers you, do as Nathan suggests. If it doesn't, try out Blueprint.I do agree with that!
And that! CSS is a simple little language that anyone can learn. Even still, when you learn it, you’ll find yourself reusing bits of code. These bits of code are your framework. A framework is not necessarily something that is packaged and released (as I state in my A List Apart article). It’s simply a library of reusable code. Anyone who says they don’t use a framework probably hasn’t written much CSS. If you have, you surely have code you reuse from project to project. If you don’t, you’re wasting time, man!
A-freaking-men. This is why the authorities saying, “you shouldn’t use CSS frameworks” at public workshops bothers me. This should be a decision each CSS author makes on his/her own.
032 // Jeff Croft // 11.18.2007 // 2:30 AM
For those keeping track: we’re now 30 comments in, and we still haven’t heard any reason why CSS frameworks are bad. We’ve heard a few reason why some people don’t like the grids implementation in Blueprint and YUI, but no reasons why we shouldn’t be interested in the concept of CSS frameworks.
Anyone?
033 // Dusan Smolnikar // 11.18.2007 // 3 AM
To me, css frameworks are just like any other frameworks (be it php, javascript, …) - useful to the novice kind of developers, but too limiting for an expert. Of course, you can always add your own styles or edit the existing ones, but not being the author of the code you have no idea what other segments are gonna break. Also, when something does go wrong (I realize it’s been tested thoroughly, but we’re all just human after all) it’s much harder to find the problem.
And then there’s the so-called “semantic” aspect of it. Surely, your visitors don’t care about it, but we as developers should. I just went trough a site redesign, where most of the work was done css-wise. By having a nice, simple code I could just tweak the css file to move the elements about and change their appearance.
But I guess the biggest problem I see, are the aforementioned novice developers. Does using a framework affect their learning curve? By using blueprint, does a developer ever learn the full power of css? I guess it depends on the person using it and how he’s using it.
But of course, these are all just my views as to why I wouldn’t use such frameworks. But other people have other needs, and if it helps them do some work faster, so much the better.
Personally, I haven’t heard of a css framework before blueprint. But you can be sure that the more people are talking about it, the better it is. :)
034 // Jon Hicks // 11.18.2007 // 3:01 AM
I’ve been deliberating whether to comment, as I don’t really have much to say on the matter (not very worthy of a comment!). However being a Brit I feel obliged!
I mentioned CSS frameworks on The Rissington Podcast, and my words were ‘make your own frameworks’. I think its a great idea to use and pick apart existing frameworks, but better when you make up you own.
The job security thing didn’t even enter my head! Ultimately, I really couldn’t give a shit either way - if they work for you great, if not, err…. great!
035 // Jeff Croft // 11.18.2007 // 3:06 AM
These are very good and valid points for the use of any framework. I think the authors of any framework (certainly the ones I use regularly) will tell you that you should know the ins and outs of what a framework does and how it works before you implement it. You should know what other segments are going to break if you go adding things, and you should know how to find the problem when something breaks. If you don’t, then you don’t really know the framework.
Don’t want to learn someone else’s framework? Fine — write your own and use it. By presuming that a framework has to be someone else’s code, you’re shortchanging the whole concept. You can know it intimately, or you can write it yourself. You don’t have to simply accept what other people have done on blind faith.
Why? Why should we as developers care if our code has a few presentational class names (I’ve been over this in previous posts — you should read those before you respond). They hurt nothing.
Exactly. It depends on the developer. And should frameworks be blamed for lazy developers?
Good comments, Dusan! Thanks for taking the time. :)
036 // Jeff Croft // 11.18.2007 // 3:09 AM
Beautiful, Jon! I couldn’t agree more. After all, I made my own (with the help of co-workers), and it became Blueprint (without my intending it to).
I’m not sure why some people associate the word “framework” with something that someone else writes, packages up, releases, and you use. It can definitely be something you’ve created for yourself and only yourself. A framework, as I defined it in my A List Apart article, is:
037 // Rob Goodlatte // 11.18.2007 // 3:22 AM
You’re right, I got bogged down in the specifics of Blueprint, but my complaint is the same for CSS frameworks in general: I want to make sure every design decision I make for a site is intentional. There’s just no reason to inherit a lot of style information from a framework that, as a responsible designer, I should over-write or exhaustively verify that they align with my design goals.
Again, tools are great — as long as they’re enabling you to make design decisions rather than making decisions for you. Thats why I changed my tune on grids the second I saw that generator — it’s not just a 24 column 950px-wide design solution in a box.
Typography and color styles don’t belong — those decisions need to be intentional, not copied-and-pasted.
I think the name is a bit misleading — I think of it more as a ‘style library’. I personally re-use a lot of my own styles from site-to-site. I’ll come up with an elegant solution for one site, and re-use it for others. But I’ve at least considered the problem once, and found a good solution. But with a style library, I never have to consider the design problem at all.
I’m not militantly against CSS frameworks. I just think too often they help you cut corners that aren’t worth cutting.
038 // Jina Bolton // 11.18.2007 // 3:43 AM
I think this is because nobody (that I know of) is even against CSS frameworks. Most people I have talked to (as well as myself) are actually for frameworks — though, as you stated, are not too crazy about the grids implementation in Blueprint and YUI.
If anyone thinks they’re not using a framework (whether it’s their own, or one created from someone else, and whether it’s multiple files or one long single file), they probably just don’t realize they are doing it.
039 // Patrick Gage Kelley // 11.18.2007 // 4:08 AM
Jeff, I am not sure you are going to find what you are looking for out of this discussion. By trying to find what is wrong with concept of a CSS framework (which, likely is nothing at all) I think the point of what your British friends may (or may not) be saying is missed. While the concept of a CSS framework can be beneficial, unless the actual framework being used is well suited to the way a designer thinks and designs it will become more hassle than it is worth. So for many designers who have been around the block they may have snippets they re-use, or even something like a footprint, that you can find repeated in many of their designs. However, as this differs for each of them, they speak out against ALL of the frameworks that exist, because unless they created it personally, it won’t work for them.
I have used Blueprint twice, and both times immediately removed all the grid bits, because I know that that is not the way I conceive of grids when I design, and so I do that myself and use it for its easy typography. And while I know that methods works for me, it won’t work for everyone.
Also, one last thing, that I won’t say is bad yet, but might be bad in the future. CSS frameworks will likely lead people to thinking about design in similar ways, guiding them to think about elements, typography, grids in certain ways-and this could lead people to start designing in similar ways. This may be good for people who don’t know much about design and just want to start up a website, but any sort of framework bounds creative expression, and I personally think that may be the largest problem with CSS frameworks.
040 // David Emery // 11.18.2007 // 4:32 AM
I would hazard a guess that the problem these ‘CSS Experts’ have with Blueprint, YUI and CSS Frameworks in general is that - almost by definition - they don’t need them! Why would they be interested in something that does what they think they already do in the best way possible?
Personally I haven’t investigated them in too much detail but I’m sure there are a whole load of use cases where they’d be really handy.
041 // Dusan Smolnikar // 11.18.2007 // 4:35 AM
It’s much easier to read your code after a few months, if it doesn’t. Say I make a website and I want a left menu. I create a class=”leftMenu” element. But later on, I decide to move it to the right side. leftMenu is now on the right. Who cares about it’s class name anyway.. But later on, when adding elements, redesigning, etc. this might confuse me. By just reading my html I’ll assume that I can put something inside of leftMenu to move it to the left side of my page. But it won’t. And what if I want to put a new menu on the left. class=”leftMenu2”? On the other hand, by calling this element “mainNavigationMenu” it gives me a bit more clue to what this is, regardless of where it is.
But of course, this might not be equally important on every project. Make a one-time presentational website and you wouldn’t care. But if you’re making a website that will evolve throughout years, maybe other developers will work on it as well, … then you would want a clean, semantical code that’s easy to understand.
042 // Kev Mears // 11.18.2007 // 4:45 AM
Is a presentational class name semantic in the context of a developer rooting around site templates, trying to figure out what bit of code needs to be changed, and how it’s gonna be presented on the page?
As I understand it semantics are about reflecting meaning. A presentational class name has meaning to the person tasked with using it.
I’m optimistic about frameworks, and their utility to me and my colleagues, mainly because I think there are plenty of clever, committed people who won’t be afraid to debate the merits and drawbacks out in the open where anyone can make up their own mind, and go away more informed than when they started.
Seems like
043 // Tor Lovskogen // 11.18.2007 // 5:45 AM
You say CSS frameworks are like lego blocks, how do you build a comfortable bed with static hard lego blocks? I think each site has different needs when it comes down to the CSS, thats why I like to handcrafting each sheet myself. But it feels like a design has to be adjusted for it to work, should all websites use a strict grid?
I do use the reset.css, which is good for giving a clean slate, but that’s it.
044 // Tor Lovskogen // 11.18.2007 // 5:46 AM
By the way, looks like your commenting form does not like the norwegian character “oe” ;-)
045 // Andrew Ingram // 11.18.2007 // 6:54 AM
Let’s see…
Having something generate your CSS framework for you is like having something that generates a special version of Django for you. If you need it, then the framework isn’t inherently flexible enough. Now, with CSS we obviously don’t have much choice, but let’s not dismiss the multitude of server-side tools like Moonfall that give you powerful new CSS options.
Having worked extensively on both the client and server sides of web development I can also point out another problem with using presentational class names - maintainability. Obviously this isn’t a problem for small sites and one off things, but web apps are generally extremely modular and component-based. The use of the grid aspect of a CSS framework not only puts in presentational class names (which I don’t particularly like but I can live with), but it also puts these presentational class names throughout the full stack of a fairly complicated component hierarchy. This means that should you ever decide to change the grid or amend some otherwise trivial design issues you potentially have a lot more work to do.
I have no problem with the typography or default style aspects of CSS frameworks.
It would be rather nice if everyone could use it, or at least understand how it allows content to automatically look like it’s supposed to.
For the record, I had exactly the same reservations about YUI Grids and I know I’m not the only one.
I like using frameworks very much, but in my experience the majority of them try to do far too much. Rails doesn’t give you quite enough control, the way ActiveRecord (in Rails) works is very nice and intuitive but ultimately too restrictive, especially when it comes to primary keys. The frameworks in the Java world are frankly awful, I’ve been using Tapestry at work and it actually makes it more difficult to get things done quickly. Django is perhaps the only framework I’ve looked at that doesn’t make assumptions about how the web should work, it’s the only one that doesn’t force the users into adopting the mindset of the framework authors.
But basically, I would love to see something like Blueprint done as the server-side aspect of a CSS-variables/inheritance solution so that I can use its handy features without having to worry about messing up my markup.
046 // Doug // 11.18.2007 // 7:15 AM
Two things.
If we all used frameworks (assuming we picked one that used the same class names) wouldn’t the web be more semantic? A layout microformat if you will.
When using frameworks do you load it in and over-ride/delete inside the framework files or do you create another file lower in the cascade to over-ride? I have found the latter easier. It does create more bloat but allows you to quickly update the framework and get the goodness that is in the next release.
047 // Andy Clarke // 11.18.2007 // 8:12 AM
Colly said: “However, arch limey Mr. Malarkey and I were discussing frameworks during the witching hour the other day, and I think he has a lot to say on the subject. Something along the lines of “good for establishing a basic starting point and for resetting values, but be sure to rip out all the bloated crap first” - I paraphrase him there, but what he said made sense at the time.”
Well that’s all true (apart from the words ;))
What I think I said, and I have gone on record many times during my workshops, is that Blueprint does a great job of pulling together reset CSS and the wonderful work that Mark Boulton, Rich Rutter and others have done for typography. These components worthing of commercial work.
However I would personally never use the presentational naming of the grid components in commercial work (possibly only during rapid prototyping) and I encourage people in my workshops to avoid them too. This is not because you or the creators of Blueprint have done a bad job, merely that the presentational nature of the markup elements and attributes lead to presentational thinking when writing markup.
048 // ben // 11.18.2007 // 8:13 AM
I’ve posted a full reply, including direct answers to your questions, at Frameworks: it’s the fidelity, stupid.
049 // Charles Roper // 11.18.2007 // 8:15 AM
I posted this somewhere before but I’ll say it again: to dismiss frameworks because of bloat, or lack of control/flexibility, or even to claim that “they’re only useful for rapid prototyping” is akin to dismissing Rails because of its scaffolding features (which many people did when it first came out), or dismissing TextPattern, WordPress or Expression Engine because they contain so much code (aka ‘bloat’) already. In fact the CSS frameworks (I’m thinking of Blueprint in particular) are less bloaty because you can very easily strip out the bits you don’t want. This isn’t as easy to do with code frameworks such as Rails, Prototype, jQuery, Django, etc and even less easy with stuff like Wordpress and TextPattern.
I have actually used Blueprint for my latest professional project having coded my own CSS from scratch for years. I didn’t use it just for rapid prototyping because the actual work was the rapid prototyping. I’m thinking Agile Development here; code fast, iterate often. I was astounded - yes astounded - at how much of a difference it made to my productivity. I was able to produce the HTML and CSS is half the time, if not less. Instead of pissing about fixing browser bugs I was able to spend my time on more useful things such as design, IA, semantics, etc. Instead of having to think too hard about achieving certain complex grid-based tasks in CSS, the framework handled them for me. This saved a huge amount of time. I did have to invest some time learning the framework, so for this project I think the timings just about balanced up, but for the next one, I’ll truly be saving time.
In terms of ripping out ‘bloat’, I’m going to remove any unused classes at the end of the project. Easy. So the bloat argument is bullshit.
I used the Blueprint Grid CSS Generator to create a grid suitable for my requirements, so I call bullshit on the argument that Blueprint lacks flexibility. It’s quite the opposite in fact.
To be honest, the naysayers do remind me of the naysayers who moaned on about frameworks when Rails and Django hit the scene. This was primarily due to an ignorance about what the frameworks achieve and how to use them effectively. If you go in with a closed mind and an unwillingness to make them work, then they’re just not gonna work. It’s a shame.
To be fair, I really don’t think this lack of enthusiasm from the ‘gurus’ is anything to do with professional protectionism (otherwise they wouldn’t blog or give so much back to the community), but simply an ease and comfort with how they’re doing things already coupled with a lack of deep understanding (through lack of use) of the benefits a framework can bring. Change is hard, especially when you’re really comfortable with how things already are.
p.s. I’m a Brit.
050 // Dan Shields // 11.18.2007 // 8:19 AM
Since we are talking about frameworks in general, I would say that the YUI doesn’t use non-semantic class names. It uses class names that describe the container such as doc, which is the document pagewidth. Then there is yui-t, which means a specific template, yui-g means grid holder and also yui-u, which is grid unit.
I don’t see these really being unsemantic, but just a little confusing if you haven’t read their documentation. They call it a microformat and like Doug says maybe if everyone worked together to create a proper microformat for grids then people would be less skeptical and confused with what the class names meant.
I do understand that there is a big difference in how the grid works with YUI and how Jeff creates his frameworks, but maybe this is the starting point for us to come together and create something that is much more universal.
051 // Tom Armitage // 11.18.2007 // 8:25 AM
I can’t say that CSS frameworks are objectively bad, because that would just be stupid. But I hope that this might explain why I think they are a bad thing for many of the people thinking about using them right now.
To wit: by and large, many people see CSS frameworks not as a way of standardising the front-end development process, but as a way of avoiding having to know too much. Rather than learning why browser bugs exist, and how to resolve them, it’s easier to pick up a framework that does what you want without you having to understand how.
This is bad, because that’s a leaky abstraction. When CSS framework “X” breaks, if you don’t know why it works the way it does, you’re not going to be able to fix the problem.
This is much like the current situation with Javascript frameworks. They are frequently used as a short-cut to actually learning the ins-and-outs of boring DOM scripting. As Simon explains: “Don’t use libraries as crutches; if you’re not prepared to figure out what the library is doing for you you’ll end up in a world of pain further down the line.“ .
Personally, I use jQuery wherever possible, simply because it makes the things I do all the time in Javascript easier. However, I learned how to do them the long way around first, if only so I have a better understanding of what jQuery does. Does that mean I should write all my XmlHttpRequest code by hand? No, of course not; that’s not workable in a production environment. But it does mean I should take the time to understand what’s going on before I take the shortcut.
I’ve seen many designers leap on tools like Blueprint as a way of making their lives easier; I’ve also seen many designers who don’t understand common browser flaws such as the hasLayout issue. In an ideal world, as you point out, they’d never have to. But right now, it’s a crucial part of IE6 bugfixing. For a while, these frameworks will make them happy, as they’ll make it easier to churn out beautiful layouts faster than before. But when they hit a bug in their own code on top of it… they’re going to be back to square one - only this time, the cognitive dissonance is going to hit harder, as up until that point, everything has been working by “magic”.
“Magic” is a dangerous metaphor: it’s all too frequently used to describe something being hidden from the end-user that they don’t understand. And for me, these frameworks are all too often perceived as “magic” to make development easier, rather than a way to streamline what coders already do.
So it’s not that the frameworks themselves are bad, and it’s not that they’re bad for everybody. But I think a lot of people leaping upon them with glee should perhaps spend some time learning things the hard way first. (And if, of course, the net result of that, is that you end up with your own micro-framework - even if it’s just a couple of rules you use everywhere - so much the better).
052 // Kev Mears // 11.18.2007 // 8:42 AM
Thanks Andy, for the rationale behind your reservations.
If I’ve understood you correctly, you’re reminding designers that they need to have the ability to switch between a semantic and presentational way of thinking about the markup and the content.
Sounds good to me.
053 // Dan Shields // 11.18.2007 // 8:49 AM
To be honest a framework like Blueprint really doesn’t solve all your browser issues. The only thing it really does is apply a fix to the 3px margin bug for IE 6 and they include a class for the clearfix hack. Oh and a couple other little fixes for some minor list problems and the incorrect styling of legends in IE 6.
This isn’t going to solve all of a developers browser issues its only going to solve it mainly on the grid columns. You still have put elements inside of these containers and your going to still have to know the different browser issues and fixes.
054 // Tom Armitage // 11.18.2007 // 9:06 AM
Dan - yes, fair enough. But perhaps that’s just the designers I’ve seen misunderstanding the benefits of such frameworks, then. The attitude they approach them with is “great, a way to avoid writing/fixing CSS“. Regardless fo whether they’re true or not, the frameworks are highlighting a flaw in the web design community - not a flaw in the frameworks themselves.
055 // Michael Montgomery // 11.18.2007 // 9:10 AM
Specifically regarding the coming capabilities of the Blueprint framework, just thought I’d point out something from Christian Montoya: Semantify, and CSS tools based on Blueprint …which talks about the grid generator, the visual layout builder, and Semantify (which I think can remove bloat and presentational class names).
056 // Dan Shields // 11.18.2007 // 9:16 AM
Tom - you are correct, it is a misunderstanding of the web design community that has this effect on frameworks. Take for example javascript frameworks. I can’t stand how much I hear designers or marketing people in the firms say well you should be able to do this javascript functionality really easy now that there are javascript frameworks out there that do it for you.
The only way you are not going to have to know a given language when using a framework is if you are doing a very basic site with simple functionality and/or layout.
057 // Nathan Borror // 11.18.2007 // 10:46 AM
Side note: Semantics doesn’t stop at tag names. Semantics means “to give meaning.” While a
tag may mean something is a paragraph,further means this is a description paragraph that possibly happens more than once on the page. Just sayin' :)058 // Charles Roper // 11.18.2007 // 10:53 AM
Malarkey raises a good point: should frameworks be employed when teaching CSS? I think not, just as you probably wouldn’t use a Django as a starting point for learning how to program (or perhaps you would?). But I do maintain that they are highly useful and time-saving in the professional context and shouldn’t be dismissed simply as “rapid prototyping” tools. As professionals we should know when and how to break the “rules” (e.g. thou shalt not use non-semantic presentational class names) in order to best achieve our clients’ objectives. Just like print designers (and increasingly web designers) know when to break with the grid to achieve their aims.
Arguing against Blueprint because it enforces presentational class names is bogus, though. You can use multiple class names to create your semantics (as I do) and, if you really want to or need to, you can later stuff the CSS from the framework classes into the more semantic selectors you created, which I don’t think is beyond the wit of most web designers seeing as there really aren’t that many grid selectors in Blueprint and probably even fewer of them are actually used in a project.
059 // ynw // 11.18.2007 // 10:57 AM
I welcome CSS frameworks as a sign of maturity CSS technology has reached.
060 // Samuel Cotterall // 11.18.2007 // 10:59 AM
Being an XHTML + CSS developer I’ve sworn by Prototype and Rails for the last few years because it takes something I’m not very good at and does it for me. When it comes to JavaScript and back-end development I wouldn’t think to work without a framework these days.
However I’m very comfortable writing CSS, which makes me reluctant to start using a framework. Although I’ll give Blueprint a try this week and I’m sure I’ll be blown away.
And yes, I’m British.
061 // beth // 11.18.2007 // 11:52 AM
A lot of people have really good arguments both for and against using CSS frameworks. Everyone works differently and every project is a little different, thus like anything else in the world they’re appropriate for some projects and people but not others. So what’s the fuss?
If they don’t work for you, don’t use them. Personally, they’re not my cup of tea because I’m a control freak and prefer to set everything by hand, but I can see how one might have been immensely useful when we were rebuilding the American Greetings site.
062 // Jakob Heuser // 11.18.2007 // 12:17 PM
This reminds me a lot of the same discussion that plagues programming frameworks, which as someone who has helped drive django adoption, I’m pretty sure you’ve heard before. The reasons for taking issue with a framework continue to be the same. They are “limiting”, “hard to work with”, and teach people to “program for the framework” (grr, I just closed these tabs or I’d link them in). The following seems pretty consistent across framework discussions though:
The big fear of frameworks (front and back-end) I’ve noticed in my day job is a fear of people who know how to use a framework, but don’t know how to solve a problem outside of the context of the framework. I see this fear in our web development team when we prepare for Interviewing candidates, people who know YUI for example, but don’t understand block scope or extension by the prototype keyword.
063 // Jeff Croft // 11.18.2007 // 12:23 PM
Definitely not. When people come to me asking how they can get started with Django, I say “learn Python.” Just the same, I would never advise people looking to get into CSS start with Blueprint. That’s flatly absurd. Rather, I’m suggesting that experienced CSS developers should be reusing code and development patters for much greater efficiency. That’s all I’ve been suggesting. Why is this so hard to understand?
JB, if this is true, then that’s awesome. However, I’m not convinced it’s true. I’ve heard with my own two ears CSS experts say, “frameworks are a bad idea.” Those exact words.
Here’s the thing: it seems to me the people that have a problem with these CSS frameworks come from a traditional design background, not a computer science one. If they were coming from a computer science background, they would know that a proliferation of libraries and frameworks for a particular language is a good thing: it shows the language has reached a certain maturity and a certain degree of critical mass. It shows, for lack of a better phrase, that the language is all growns up.
That doesn’t mean you have to use the frameworks. Don’t like ‘em? Don’t use ‘em. But the fear, uncertainly, and doubt that is being spread shows a massive lack of understanding of how the lifespan of a healthy language works.
For every other language in the world, “lots of available libraries” is a feature. People tout “lots of available libraries” as a reason they choose Python or PHP over Ruby all the time. When OS X first came out, some developers were slow to move to Cocoa because there weren’t many available libraries.
You may or may not like or use individual frameworks. You may never use a framework at all. You may build up your own framework and use it, rather than using someone else’s. But to say that “frameworks are a bad idea,” is to display a massive lack of understanding of how computer science works.
064 // Jeff Croft // 11.18.2007 // 12:30 PM
Good question. Here’s the answer: you build your bed frame with lego blocks, and then you hand-made a great mattress, some sheets, and a duvet. You could hand make the bed frame out of oak, too, and sometimes that will be the best solution. You could even go chop down the oak tree yourself, and that would be cool. But, it will obviously take you a lot more time and effort than simply building the bed frame out of lego blocks (you’re still going to have to hand-make the mattress and linens, either way).
Now, if you’re in the business of making super high-end, hand-crafted furniture, then obviously you don’t want to use legos. Awesome. But if you’ve got a commission to build a perfectly acceptable bed if 24 hours, you may not have time to go chopping trees and cutting wood.
I’m not here to say that a lyout built with Blueprint (or another framework) is going to be as exquisite as a hand-crated one (it won’t be). But I am here to say that sometimes, it’s good-enough.
065 // Jeremy Ricketts // 11.18.2007 // 12:33 PM
Ya cut me Jeff. Ya cut real deep just then Jeff.
Just because the language of CSS is is not as verbose as a full fledged programming language, doesn’t mean that it’s not hard. The thing about being a janitor is, let’s be very honest- if you have a human sized cerebellum, opposable thumbs, and a mop… you can be one. In fact, toss in some work ethic and you can even be a great janitor. On the first day! And if we could make robots that do this janitor job… we would. Just like street sweepers. We use machines now because the parameters of the work are very simple.
Maybe there is a large part of CSS that can be automated by software (and dare I say… frameworks). But at a certain scale or a level, we need to employ some serious creativity and ingenuity to get the job done right. This is exactly like programming. I’m a front end developer- I don’t know much Ruby, PHP, Python, etc. This is because in most of my personal projects and freelance work, all I’ve needed (so far) is Expression Engine. Bye bye programmer… I just automated your job. But at my “day job” at a large development agency, there’s no way any automation tool could tackle the tasks we need to accomplish. They would say the same thing about the CSS that I write. We need templates that scale well with any types of content our clients might throw at the system. We need solutions that must degrade properly and integrate with other technologies seamlessly. I need to write CSS that will make the “pixel-picky” designers happy, yet avoid being littered with presentational markup (so the developers are happy) and, in the end, have a layout that is flexible to the changes both sides will throw at me mid-project.
That’s hard shit.
And dare I say, I’m a reasonably smart bloke- I can design. I could program. For now, I throw my effort and ingenuity at front end development. There might be a day when CSS5 comes around (at the current W3C pace, I’d say the year 2057) and I find that it doesn’t take much ingenuity and effort to bring join the worlds of designers and programmers together and it’s just not that hard anymore. Then I’ll move into something more challenging.
Until then, I just don’t agree that CSS and front end development are the janitors of the development cycle. We’re not the rockstars of the show (the designers) or the master engineers (programmers) but at a certain level… it’s hard work. Work that a robot can’t do (yet).
066 // Jeff Croft // 11.18.2007 // 12:38 PM
@Jakob Heuser: Great comment. I agree with everything you’ve said, possibly excepting the idea that frameworks are bloated (some are, for sure, but I don’t think bloat is something that is simply inherent to every framework).
To your final point:
I agree that this seems to cause Framework Fear™. But, my response to it, as I stated earlier, is this: Is this really a problem with frameworks? Isn’t it, rather, a problem with lazy developers?
As a former boss of mine used to say all the time, technology can’t solve personnel a problem.
067 // Jeff Croft // 11.18.2007 // 12:41 PM
@Tom Armitage: Great comment. I agree with every single line of it. Very well-said.
068 // John Oxton // 11.18.2007 // 12:52 PM
So why write it then? It’s just dumb but hey that’s Americans for you!
069 // Jeff Croft // 11.18.2007 // 12:54 PM
It’s not as hard, and if you say it is, you’re lying to yourself. I’m sorry if that cuts you, man, but it’s the truth.
CSS isn’t as simple as being a janitor, and I never said it was. My point was simpler that just because every job is important doesn’t mean every job is equal.
But, it’s not that much harder, either. CSS, the language, is simple to learn. I feel 100% confident I could teach it to all of our Moms. There is one thing about CSS development that is truly hard: dealing with browser bugs. But dealing with browser bugs is something we shouldn’t have ever had to do, and we will have to do less and less as we move forward and the browsers get better.
Again, I’m sorry if it’s painful to hear, but I stand by this: if every browser perfectly implemented CSS, then learning CSS would be something we could teach every kid in, say, fourth grade. I really hope one day the lousy browsers will go the way of a dinosaur and it will really be that easy.
Absolutely. I’d like to think me and my co-workers put that creativity and skill in when we developed our framework. At the time, it felt like the perfect solution for our needs. It worked great.
That’s great. I do believe that day will come (even if it is 2057), and I’ve been telling anyone who will listen that just HTML and CSS isn’t going to be that valuable a skill set in the future. You need to have some other skills to complement these. It sounds like you do — so, well-done, you.
And, that’s not what I said at all. You’re totally putting words in my mouth now, man. :)
I agree completely, and I’m not interested in employing robots. Frameworks? Sure. Robots, no thanks (at least not yet).
070 // Jeff Croft // 11.18.2007 // 1:04 PM
Because I thought it was interesting. And, because I wanted you to comment, Mr. Oxton.
It worked! :)
071 // Nathan Barry // 11.18.2007 // 1:05 PM
To start off I would like to say that I am very new to CSS Frameworks. I had read about Blueprint and YUI, but didn’t actually start using Blueprint until last week.
As web designers and developers we should always be looking for ways to speed up our work flow and also to provide better quality code. As business professionals that should be obvious, if you are not constantly searching for ways to work faster and produce a better product, then you well go out of business.
Work Faster: To work faster we want to avoid repetition in our work. If there is any way you can save time and get the same or better result, then do it. It’s that simple. That is why I started using Blueprint, because it already has things built in such as the typography and especially the browser reset. These and other features save me a lot of time both in writing my code in the first place, but also in browser testing (my first site using Blueprint worked right out of the box with IE6) and future editing time by colleagues.
Better Quality: Plenty of people in the web design community are far better than I am. And those people write things like browser resets that are much more complete and well thought out then mine. So instead of trying to reinvent the wheel, I can just use their better solution. There are plenty of other great examples of what can be done to provide better quality code with frameworks.
Another way that I have used a “framework” is for theme development with WordPress. I found that when creating theme there are a lot of features I use every time, so instead of repeating myself, that I should write a WordPress theme framework.
With all of that in mind I wouldn’t suggest frameworks for someone learning CSS. It is important to understand the different ways CSS can be used before settling down to a specific framework or method. I think that frameworks are only limiting if you don’t fully understand their purpose, and also how to expand beyond it.
So, anything that saves me tim