Jeff Croft

I’m a product designer in Seattle, WA. I lead Design at a stealthy startup. I recently worked at Simply Measured, and previously co-founded Lendle.

Some of my past clients include Facebook, Microsoft, Yahoo!, and the University of Washington.

I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.

But seriously, who gives a shit?

Link // 08.18.2008 // 11:24 AM // 8 Comments

Eric Meyer: The Lessons of CSS Frameworks

Again from Jeremy’s great live blogging of An Event Apart San Francisco, here’s Eric on CSS frameworks. I’m glad to see someone else broaching this topic, and in general it looks like Eric did a great job of rounding ‘em up. A few bits and responses:

> If you’re going to use a framework, it should be yours; one that you’ve created. You can look at existing frameworks for ideas and hack at it. But the professionals in this room are not well served by picking up a framework and using it as-is.

Generally speaking, I agree. I have made great use of Blueprint — but it’s worth nothing that almost all of the basic concepts were created by me (along with Nathan and Christian). As Blueprint has progressed, it’s gotten farther and farther away from what we created, and I’ve been less enthralled by it. The point is: something you created yourself is always going to be more useful to you than something you didn’t.

> Four of them use psuedo-namespaced class names beginning with grid- or container- or span- (which you would apply to a div!?).

I’m not sure if the parenthetical is Jeremy or Eric speaking, but this is also worth noting: in the original CSS framework Nathan, Christian, and I created, you were not necessarily supposed to apply those classes to a div. The classes were for any element, and there was no encouragement to liter your markup with extraneous div elements. The original Blueprint retained this philosophy, but later changed it, asking people to always use div elements as columns. I find this to be incredibly wrong, and I always override this Blueprint functionality when I use the framework. If you are going to use a div for every layout column/row/unit/whatever, you may as well just use tables. I hope everyone knows and understands that when I was touting Blueprint, it was before the made the boneheaded decision to require the use of a div element for every column.

Visit site...

Comments

  1. 001 // Matt Brown // 08.18.2008 // 12:53 PM

    Man oh man. I wish there was a transcript of the actual talk, so I could disagree with it line by line.

    The idea that “professionals must not use a framework” and/or roll their own is asinine. Why is it impermissible to use a set of layout techniques that someone else has tested and documented? If you understand a framework, it’s benefits and limitations, you’ll find that it just makes your work more efficient, which does not imply that you’re going to produce lower quality work. You’ll just do it faster, and have more time for the details.

    Keith/Eric really muddle the discussion by equating frameworks with templates. A template is an actual design, whereas a layout framework is just a set of patterns. Patterns which are based on basic grid theory, which most of us use on the majority of our work anyways. So, what have we lost or diluted, by using standardized rules for implementing designs based on rules themselves?

    Really, it’s just a load of FUD. My take is that Keith/Eric still want to equate wasting time on building or “crafting” CSS to some personal standard of excellence or whatever. I say meh. The true test of good CSS / HTML work is 1) is it logical and internally consistent and 2) can it be explained to a new project member in under an hour?

    Frameworks make it easy to archive both goals — you follow patterns, your code’s more consistent and all frameworks come with documentation / examples to get someone up to speed.

  2. 002 // Luke Stevens // 08.19.2008 // 3:55 AM

    @Matt Brown, Err.. I think Eric’s point was that professionals can happily role their own, and if you want to use one, that’s what Eric was encouraging you to do.

    @Jeff, I finally had a serious look at blueprint today for a very grid-oriented layout, so it seemed like a good opp. I was interested in your comment though that:

    [Originally] the classes were for any element, and there was no encouragement to liter your markup with extraneous div elements. The original Blueprint retained this philosophy, but later changed it, asking people to always use div elements as columns. I find this to be incredibly wrong, and I always override this Blueprint functionality when I use the framework.

    What do you do to override it? What else would you use for columns (apart from tables)? I don’t quite follow. (And I didn’t realise the direction had changed in that regard after you supported it, so thanks for mentioning it!)

  3. 003 // Matt Brown // 08.19.2008 // 9:43 AM

    @Luke,

    If that was the message, then I’m way off base :) However, I have heard before from this camp is that CSS frameworks are “only good for prototypes” and not ready for prime time or something to that effect.

    To me, they’re incredibly valuable in production websites, especially in team environments as they help standardize layout practices and normalize CSS / HTML code.

    Of course, all projects are different and there are times, especially in UIs, where frameworks slow you down, rather than speed you up.

  4. 004 // Jeff Croft // 08.19.2008 // 12:09 PM

    What else would you use for columns (apart from tables)? I don’t quite follow.

    Anything. An h2 can be a column. A p can be a column. A ul can be a column — just by adding the column class.

    The point here is that you should be using the appropriate elements to mark up your code and not littering your code with extraneous elements that are only there for styling hooks (when you can avoid it…sometimes you can’t). So, for example, if you have a column that contains on big paragraph, you should be able to do this:

        <p class="column">...lots of text here...</p>
    

    Instead of this:

        <div class="column">
            <p>...lots-of-text-here...</p>
        </div>
    

    I think ultimately I will do exactly what Eric suggests: take what I still like from Blueprint and roll it into my own framework — hich is a really roundabout way to get to my own framework, considering Blueprint started as my own personal framework. :)

    Blueprint’s bits are easy to override, but I get kind of tired of doing it every time I start a project…

  5. 005 // Luke Stevens // 08.19.2008 // 9:39 PM

    Ah sure, I see what you mean, thanks. I guess frameworks are essentially just a standardized(ish) collection/abstraction of the stuff us devs & designers grow tired of having to do every time anyway, and given we all have our own spin on things, for productivity/sanity sake rolling our own, or modifying existing ones as starting points seems pretty sensible (if frameworks are your thing), even if you have to re-personalize a project that started as a personal project :)

    Maybe they need to be a bit more modular though, so people can pick & choose (and add in) bits they like, without feeling they have to fork the whole project, or include different ‘flavours’ as override files, but +shrug+ that might be pretty messy too.

  6. 006 // Martin Bavio // 08.20.2008 // 7:30 AM

    I´m used to frameworks in the programming world, as I use CakePHP and Rails sometimes… and I think the problem here is that xhtml/css cannot be framed in a group of common patterns, there are too many ways of doing things and too many different scenarios. That´s why I dont believe in CSS frameworks. What I do use is in having a library with common code, so you can copy/paste whenever you need it. Anyway, it´s a non-end discussion, I´m just trying to give a different point of view and giving the why of my thought.

    Cheers,

  7. 007 // Jeff Croft // 08.20.2008 // 8:16 AM

    What I do use is in having a library with common code, so you can copy/paste whenever you need it.

    Isn’t that pretty much exactly what a framework is (except that with a framework you would just import the code fro where it lives, instead of copying and pasting)?

  8. 008 // Rio // 08.27.2008 // 12:10 AM

    we all agree that framework is the big thing and snippets is the modular thing.

    when much people understand how many modular things become much more, then they will become framework.

    we should find our own snippets one by one that we uses a lot. and you know what, we can find in frameworks out there. just don’t use one framework, framework are tend to be understandable not for production use.

Tags for this link