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?

Blog entry // 08.09.2007 // 9:26 PM // 123 Comments

The myth of content and presentation separation

One of the hallmark attributes of web standards-based design is the concept that proper use of semantic (X)HTML and CSS completely abstracts the presentation of a site from its content. One key real-world benefit of this separation is that come redesign time, one only needs to change or replace the CSS stylesheet, and needn’t lay so much as a finger upon the hallowed grounds we call markup. I’m here to say that this mantra isn’t much more than a fairy tale.

Don’t get me wrong. It is absolutely a best practice to separate your content, presentation, and behavior layers as much as possible. No doubt, doing so does make for easier maintenance — and brings several other benefits, as well. It’s a noble goal to strive for, and I think we all should do so. But the idea that a redesign of anything more than the most basic of sites will not require changes to (X)HTML markup is simply a myth. I’ve been in this web standards game for five years now and probably have over 100 standards-based sites under my belt. I can count the number of times I’ve be involved in a redesign where no changes were made to the markup on one finger. And that time, I wanted to change the markup, but couldn’t for reasons out of my control.

I bring this up in response to some criticism of Blueprint, a publicly-available CSS framework which borrows heavily from a CSS grid component Christian Metts, Nathan Borror, and I built at The Lawrence Journal-World. Although Blueprint has largely received very positive feedback from the web design community, some people are bothered by the non-semantic (and semi-visual) class names, some examples of which are span-4, pull-2, and prepend-6.

The concern is valid — Nathan, Christian, and myself were all bothered by it, too. But after some thought and playing with the framework, we realized a few things:

  1. Non-semantic class name hurt nothing.
  2. The productivity and efficiency boost we got by all designers using a consistent framework that already accommodated for browser issues was enormous.
  3. We were never, ever going to redesign our sites without changing the (X)HTML. It’s a nice thought, but it’s also a total pipe dream.

So, if we’re always going to revisit the (X)HTML at redesign time, use of visual class names doesn’t negatively impact our work, and we can create good, solid layouts in very little time — what’s not to love about (the framework that became) Blueprint?

If there’s one thing I wish I could use my position in the industry to convey to others, it’s this: Use Web Standards because of the great benefits you get from them. Don’t use Web Standards because Jeffrey Zeldman told you to. Where Web Standards and other best practices don’t provide great benefits, find solutions that do.

Oh, and check out Blueprint. It’s awesome. :)

Update: I posted another entry to more clearly define what I meant by the “Don’t use Web Standards because Jeffrey Zeldman told you to…” line.

Comments

  1. 001 // Lee // 08.09.2007 // 11:56 PM

    We’re never, ever going to redesign sites without changing the (X)HTML. It’s a nice thought, but it’s also a total pipe dream.”

    On the one hand, I’m glad to hear someone of your calibre say this. On the other hand, it’s a sad day… hearing you say that might see me give up trying :( I really thought that it could be possible… one day :)

    The way I build my sites at the moment - database layer, data access layer, presentation layer, and then template (html) - this way, a redesign means modifying the html template and presentation layers only. A compromise I think works pretty well :)

  2. 002 // Derek // 08.10.2007 // 1:23 AM

    Don’t use web standards because Jeffrey Zeldman told you to.”

    This made my day. Or my bedtime rather, as it’s 2am. We’re not sheep, we’re designers and developers. Learn from Jeffrey. And all the other XHTML/CSS web standard gurus out there. Don’t blindly copy them. I’d mention names but that would make this comment really long.

    I agree with this article 100 percent. And yes, Blueprint is amazing.

  3. 003 // Dylan FM // 08.10.2007 // 1:29 AM

    I’m rushing through a donation job tonight, maybe this is an opportunity to try out the grid component that I shied away from. I can always rename the class names anyway. I don’t feel too keen on the typography part of blueprint though - too many pixels.

  4. 004 // Ludwig Wendzich // 08.10.2007 // 1:38 AM

    I have summed up my thoughts on my own blog, my I believe that HTML can’t divorce presentation and content and although that’s a shame because as a believer in web-standards it’s a goal I’ve striven for a lot, but you’ve got to realize at some point that we have tools at our disposal which can separate content and design much better than HTML and CSS.

    I love the fact you stood up and said this!

  5. 005 // Jeff Croft // 08.10.2007 // 1:38 AM

    I’m rushing through a donation job tonight, maybe this is an opportunity to try out the grid component that I shied away from.

    It’s great if you’re in a hurry. :)

    I can always rename the class names anyway.

    You can, but I’m not sure I’d recommend it. If you go and rename the classes for each site you work on, you sort of ruin the abstraction that is so useful. The point of the framework is to have a set of CSS files that you can very quickly and easily plug in to any project — without modifying them — to set you on your way. Using the framework should be much easier than starting from scratch. If you have to rename the classes to go with each site, you may find it’s not saving you much time.

    Also, if you hack upon the Blueprint CSS files, you’ll find it much more difficult to upgrade to the next version of Blueprint, which will almost certainly have many improvements.

    As Wilson Miner said over on Khoi’s site earlier today: if you want the benefits of framework abstraction, you have to give up some control. You simply can’t have it both ways. It’s even true for me! Olav made a few changes to the class names when he took the LJWorld.com framework and turned it into Blueprint. Frankly, I liked the originals better, but I am willing to accept his changes because of all the other benefits using the framework gives me.

    It’s a trade off, and I’m sure it’s not for everyone.

    I don’t feel too keen on the typography part of blueprint though - too many pixels.

    That’s cool. Olav has mentioned adding relative font sizing to the framework. If he does, I hope it’s optional — I prefer pixels, myself. But he could easily include both options, if he wanted to.

    One of the beautiful things about Blueprint is that each component is separate (there’s that abstraction again), so you can only use the bits of it you need on each given project.

  6. 006 // Ludwig Wendzich // 08.10.2007 // 2:25 AM

    I understand that there are plans to modularise (that a word?) Blueprint, so that you can pick and choose which “sketches” (might be taking the metaphor too far, but it’s fun) you want to apply. Maybe you like the grid but not the typograpy, or maybe you want to pick the serif typography file instead of the sans-serif file.

    There are also talks about creating a Blueprints web app that will create the file for you, so you pick the column and gutter widths for example, and the amount of columns andso forth, and it outputs the various files for you. This could make developer’s lazy which is what I’m worried about - it’s why, I think, we turned to tables. Drag, drop, done.

  7. 007 // Andrew // 08.10.2007 // 2:47 AM

    It is true that we don’t redesign without changing the HTML; however, in the CMS based world it isn’t uncommon to move elements about to produce alternative layouts for the writer to choose from.

    I haven’t had a chane to play with Blueprint yet, but do the non-sematic names affect the ability to do that?

  8. 008 // Matt Wilcox // 08.10.2007 // 3:30 AM

    Well that was a refreshing post!

    My experiences are much the same - a visual redesign always means a HTML re-design. On the other hand I’m not so taken with presentational classes - I like my mark-up to be meaningful because that’s how I understand my document. I don’t tend to think in terms of visual presentation. That’s why I like the idea of blueprint, but have issues with some of its execution. On the other hand - if it works and saves time for a lot of people, great!

  9. 009 // Matthew Pennell // 08.10.2007 // 3:50 AM

    While it is true that it is very rare to approach a redesign job where you don’t touch the markup at all (as we’re usually redesigning the IA as well as the visuals), there are one or two scenarios where semantic classnames and less abstraction at the CSS level are a benefit - if you’re producing multiple ‘skins’ for a site (like Adactio with its multiple alternate stylesheets, or Blogger’s templates) then it would be beneficial to designers for the CSS to actually make sense.

    Of course, there’s nothing to stop you using semantic IDs along with your non-semantic framework classnames.

  10. 010 // Eric Eggert // 08.10.2007 // 3:56 AM

    Probably most people forget that an HTML document doesn’t contain content only but also structure. I’ve just published an article describing this (so see this comment as a manual trackback): Why content and presentation separation in HTML is a myth.

  11. 011 // Eric Florenzano // 08.10.2007 // 4:21 AM

    BTW, if you’re thinking of using the Blueprint CSS framework, I’d hold off for a day or so because the developer is coming out with a completely relative version of it (based on em instead of px) in the very near future for 0.4. That is, if you’re to believe what he’s been saying on the google newsgroups.

  12. 012 // Rob L. // 08.10.2007 // 6:54 AM

    This post is why I don’t bother blogging about web development. Every time some new tool or technique makes a notable debut, I take a day or two to articulate my thoughts to write a post, then peek at my feedreader to find that Jeff’s just written about it and there’s a nice discussion going on :^)

    Further to what Matt was saying above, experience has shown me that semantic markup is a tremendous help in a corporate web development environment where new people join a team and have to get neck-deep in a large-scale site very quickly. So the presentational aspect of Blueprint class names makes me a little wary, but I suppose you can still use IDs (and even other classes) for meaningful names to attach to elements (like say, class=”mktgMsg”) and use the Blueprint class names purely for positioning — does that bear out in folks’ use of the framework? So far I’ve only looked it over; haven’t started playing with it yet.

  13. 013 // cruster // 08.10.2007 // 7:31 AM

    If content and presentation separation is a myth, css Zen Garden is a myth as well. If so, then I guess I’m dreaming. Time to wake up. POOF I’m wake now. CSS Zen Garden is still there. So it can’t be a myth, nor my dream. So content and presentation separation can’t be a myth, nor a dream. It’s reality.

  14. 014 // Lee // 08.10.2007 // 8:16 AM

    cruster, Zen Garden is a great site, and people have done some fantastic things with it, but in all fairness, it is hardly the most complex of web sites.

    Show me input forms, data grids, error/information messages, javascripting etc etc etc

  15. 015 // Andrew Ingram // 08.10.2007 // 8:19 AM

    cruster, CSS Zen Garden is an idealised sandbox. It works because the designers don’t have deadlines and they don’t have to cope with unexpected dynamic content - they have time to come up with clever ways to rearrange the page but they’re ways that only work because all the headings never change (so they can do fancy graphics) and because there are a handful of empty divs which let the designers do a few fancy things (those empty divs are there purely for presentational purposes).

    If you look closely at the designs you’ll also notice that they’re not actually all that different, the main changes are in graphical style rather than layout. Fact is that in reality if someone wants a new design you’ll almost certainly have to redo parts of the HTML, especially if the new design includes new features.

    Now I’m not a fan of using non-semantic markup, I like my HTML to be as meaningful as possible, so I’m still undecided on whether I’m likely to use Blueprint. But I imagine that at the very least it’s a powerful tool for getting working versions of website designs up and running quickly. But one day a client is going to ask for some text to be put in multiple columns that have no semantic differentiation - only presentational - and since we can’t really use CSS3 yet the only option is to put in some presentational divs.

    I’m hopeful that CSS will continue to advance and browser support picks up, because the more powerful the presentational language is the more presentational markup we can take out of the content layer.

  16. 016 // Dimitri Glazkov // 08.10.2007 // 8:44 AM

    Just because you have given up, doesn’t meant that the others aren’t still looking :)

    I wrote about this a while back, but had a misfortune of offering tables as a solution: http://glazkov.com/blog/tilt/. People got too focused on the “table” part and didn’t seem to grasp the concept. Well, not well enough to be widely adopted.

    Today, there is no excuse to meddle with your markup anymore: observe exhibit A: http://antarctica.uab.edu/. Read the markup and try to find anything presentation-related… and no tables! Warning: the blog posts may contain presentation elements, since there were written by biologists who don’t really care about “shamantic markup”.

  17. 017 // Scott Nelle // 08.10.2007 // 8:51 AM

    With all the Blueprint buzz, I was a bit wary of the non-semantic classnames. You’re right, though: They don’t hurt anything. I personally prefer semantic classnames because they make styling easier for me (they jive with the way I think, and that makes navigating a stylesheet simple.) But I’m sure I can learn to work in other ways, and there’s nothing stopping me from adding a semantic classname in addition to the presentational ones.

    I would like to mention that I’ve redesigned my personal site a couple of times without changing the xhtml, but I use a very stripped down wordpress template and I don’t apply much ornamentation to it.

  18. 018 // Jonathan E // 08.10.2007 // 8:51 AM

    Very well put Jeff. I also had the same apprehensive feeling when I saw presentational class names like “span-12.” After giving it some more thought, I had a bit of an epiphany… could this type of markup be a little easier for those still doing layouts using tables? Could this be the type of thing that finally pushes them over the edge because it’s easier to understand? If so, then I think it’s OK to put up with some semantically incorrect class names.

    I think you’re spot on about redesigns never touching markup too. In an ideal world, this would be the case, but very rarely does a redesign include all of the old design’s components, so the old markup just doesn’t work for the new design. Once you start talking about new components or features of the new site design, then you’re completely out of luck if you just want to throw in a new CSS file and be done.

  19. 019 // beth // 08.10.2007 // 9:35 AM

    We were never, ever going to redesign our sites without changing the (X)HTML. It’s a nice thought, but it’s also a total pipe dream. ”

    This is so absolutely true. I mean, we all strive for this but how many times has some marketing person asked you to place an element somewhere that required you to add an extraneous element to your markup?

  20. 020 // Matt Brown // 08.10.2007 // 10:06 AM

    Right on! It’s always great to see the community loosen up a bit with regards to web standards. I’ve always thought the maniacal drive to separate presentation and content so explicitly was a bit misguided—a little ‘bleed’ between these categories can make developing sites much more efficient.

    Looking at it from a CSS maintenance perspective, do you really want to stuff layout information into your semantic CSS classes? Separating layout from the broader category of ‘presentation style’ is a cleaner, and easier to maintain development strategy. Anchoring layout information to somewhat non-semantic tags has the benefit of making your CSS much easier to read, and your layout code easy to re-use. Making layout a ‘shallow problem’ with a framework lets you spend much more time on the details of style—not fussing over floating divs.

    As a sidenote, I’m a bit sad to see some people bash on the YUI Grids Framework. I’ve seen many people complain that it’s bloated, which is quite untrue—it’s a 4.5kb file! While Blueprint seems to have a few nice typography features, and a more “designer’s grid” focus, I find YUI to be very simple, fast, and reliable—I’ve been using it for over a year and can’t go back. Regardless, having (at least) two great layout frameworks is a great thing.

  21. 021 // Jeff Croft // 08.10.2007 // 10:25 AM

    @Matt Brown: I personally like YUI’s grid quite a lot, and it definitely inspired what we did at the Journal-World (which eventually got integrated into Blueprint). We wanted something more precise (absolutely sized, not relative) and fixed-width, so it didn’t quite work for our needs — and also we found the class names there to be confusing — but the basic concepts in there aren’t too much different from what we did. I wouldn’t even bash YUI myself. It’s a nice framework, for sure — it just wasn’t exactly what we wanted.

    Glad to wake up to this generating so much discussion. Thanks for reading, guys and gals! :)

  22. 022 // Matt Howell // 08.10.2007 // 11:07 AM

    The only way you can keep HTML and CSS completely separate through redesigns is if:

    1. Your redesign is minimal, so you can use the HTML that already exists, or
    2. You somehow anticipated every future change that would happen to the site and coded in all the appropriate hooks from the beginning, which meant inserting extra markup (and yet another deviation from one of those idealized best practices of web development).

    Any kind of significant change is going to require messing around with the HTML. We don’t do what we do in some sort of idealized vacuum (although I’d love to get paid to experiment all day) — our stuff has to work visually and functionally, and it’s rare that you don’t deviate from the ideal.

    Another thing is that “content” is not synonymous with “HTML markup.” More and more, I’m seeing markup as just another aspect of presentation. The only real way to keep your content and presentation separate is to have all your content in an XML file or a database, and use a separate presentation technology to deliver it, like XSLT or HTML/CSS templates. Of course you want to keep your markup light and attend to its functionality across platforms, but the point is that we’re keeping content and presentation separate on multiple levels, at multiple scales across a project.

  23. 023 // Nate Klaiber // 08.10.2007 // 12:26 PM

    Jeff, this is an excellent post. I started writing a draft the other evening on this exact topic. Everyone would like to make it sound so easy, ‘all you have to do is switch your CSS and you can redesign.’ I have never been involved in a re-design that was that easy. We recently redesigned our company website, and the truth is - the markup was different, the content was different, and the underlying structure was different. It wasn’t as easy as just switching out a stylesheet. Sometimes the hooks are different, sometimes you need a little more.

    So, while everyone will preach this - and CSS Zen Garden shows the examples of what could be done - it is rare to actually happen in real life. I have more to say on the topic, but i’ll add it to my draft. Regardless, you have hit on a very good point.

  24. 024 // John Wrana // 08.10.2007 // 1:31 PM

    I would say: Don’t think separation of content and presentation is a myth because Jeff Croft told you so.

    I think you are looking at this from a webdesign professional point of view. In that case it may make sense. But for millions of private homepages, weblogs and non-profit sites without pressure and deadlines, there is no need to throw away the accomplishments of the last years, building a more semantic web.

    Naming classes »bla-5« and »foo-6« may not hurt, but it makes much more sense to give them names with a real meaning. Even teams working on the same code will benefit from this. (»Jeff, what stands foo-6 for?«) If we say, there is no need for semantic class names, then the next one may ask: »Why not use tables for layout? It won’t hurt anybody.«

  25. 025 // Wilson Miner // 08.10.2007 // 1:40 PM

    Classes aren’t an exclusive namespace. You can (and should) use semantic class names. If necessary, you can use layout class names as well. They don’t conflict, they don’t get in the way of each other. They don’t prevent your markup from being semantic in any way. It’s not either/or, and it’s not a battle. Use what works and what feels like the right thing to do in the context of your project.

  26. 026 // Jeff Croft // 08.10.2007 // 1:58 PM

    I would say: Don’t think separation of content and presentation is a myth because Jeff Croft told you so.

    Hah. Touche! But, I would totally agree.

    I think you are looking at this from a webdesign professional point of view.

    Absolutley I am. Frameworks, by definition, are designed to abstract routine tasks into easily reusable pieces. If you don’t have routine tasks because you only work on one site, or the sites you work on are totally different than one another, then yo probably don’t need a framework.

    However, I think far more people are in my boat, where they can gain a lot from a framework.

    But for millions of private homepages, weblogs and non-profit sites without pressure and deadlines, there is no need to throw away the accomplishments of the last years, building a more semantic web.

    I would hardly say I’m suggesting we “throw away the accomplishments…”. I’m only suggesting we the best we can within practical reason, rather than insisting on 100% pure semantics every time, when 100% pure semantics doesn’t gain you anything of real value (unless you can explain to me what it does gain you).

    Naming classes »bla-5« and »foo-6« may not hurt, but it makes much more sense to give them names with a real meaning.

    I agree 100%. It also takes much more time. When you’re dealing with 10 redesigns that all need to be done in a few weeks (actually the precise reason we developed this grid framework), and you’ve got multiple designers working on the same project, having some semablance of consistencty is a big efficiency booster.

    If we say, there is no need for semantic class names, then the next one may ask: »Why not use tables for layout? It won’t hurt anybody.«

    Nope, I disagree on this one. I can outline a whole host of real-world downsides to using tables. They are tons of them. They promote inaccessibility, they’re bloated, they’re limited design-wise, they don’t work well on mobile devices, etc. I can’t, however, think of a single real-world reason for not having some non-semantic class names in your markup. Can you?

  27. 027 // c.s. // 08.10.2007 // 2:39 PM

    But for millions of private homepages, weblogs and non-profit sites without pressure and deadlines, there is no need to throw away the accomplishments of the last years, building a more semantic web.

    All of the redesigns I’ve done in the past few years for my own personal purposes required changing the HTML templates because the needs of the design. One site needed to have advertising on it, which required restructuring the navigation elements to allow room. I wouldn’t have been able to do what was necessary if I limited myself to only touching the CSS file.

    No one is saying “start from scratch”. Believing that the HTML you write is 100% future proof for every possible design (or restructuring) you could think of… that’s the myth. Unless you’re willing to add in 50,000 extra design “hooks” like the CSS Zen Garden. Even then, I’m sure there are designs that could have more elegantly written CSS if touching the HTML was allowed.

  28. 028 // Fredrik // 08.10.2007 // 3:45 PM

    I’m just a stupid programmer, but is it really true that all you designer guys use application platforms where the HTML data that goes over the wire is generated once and for all?

    I haven’t used anything even remotely similar to that for years (even for completely static sites); all the apps I work on these days uses HTML rendering stages that generates the final HTML from various pre-existing pieces (usually XHTML fragments) on the way out (or rather, on the way to a cache). The source material are hardly ever modified if the design changes, but the byte stream that is sent to the client definitely changes.

    Why this obsession with the data that goes over the wire? What am I missing here?

  29. 029 // Jeff Croft // 08.10.2007 // 3:53 PM

    Why this obsession with the data that goes over the wire?

    You’re not missing anything, Fredrik. I totally agree. There’s way too much obsession with what goes out over the wire. As for why that is: my theory is that it’s because most designers are simply ignorant about what happens before the HTML rendering stage. They either don’t know, or don’t care. I have often wondered what all the fuss is about Microformats, for this same reason.

    The source material are hardly ever modified if the design changes, but the byte stream that is sent to the client definitely changes.

    I would say that adequately describes what I’ve been doing for some time, too.

  30. 030 // Rebeka // 08.10.2007 // 4:31 PM

    I can count the number of times I’ve be involved in a redesign where no changes were made to the markup on one finger. And that time, I wanted to change the markup, but couldn’t for reasons out of my control.”

    I’ve not been coding for very long, but I love CSS and the way it could be used to change style without changing mark-up. Since I’ve started doing it “the proper way,” I’ve never once not changed the mark-up either when I’ve redesigned. I’d always felt like I just hadn’t gotten the hang of it, but it’s good to know that it doesn’t necessarily work that way!

  31. 031 // Kevin Hamm // 08.10.2007 // 4:41 PM

    Ok, I’m of two minds on this, and I suppose that the real reason I’m of two minds is that I’ve been in both situations where doing a redesign required nothing be changed to the (X)HTML and where doing a redesign required huge changes to the (X)HTML - and in each case, it was semantic to begin with.

    What happened in the case where we had to touch the (X)HTML was new functionality was being brought to the site. That required that new CSS be written and plugged in, and the current layout didn’t allow for it. So we were allowed to change the entirety.

    My question to Jeff is: Were your redesigns where you changed the (X)HTML due to changes in the functionality of the sites? And if so, isn’t it convoluting this discussion by mixing “redesigned” with “evolving”?

  32. 032 // Jeff Croft // 08.10.2007 // 5 PM

    I’ve not been coding for very long, but I love CSS and the way it could be used to change style without changing mark-up.

    Could” being the keyword. :) Seriously, it’s a great concept, but when you have to work on several large scale sites, it rarely pans out in the real world. Like I said before, if you just have one or two small sites, it may well work. But I think more people are in the boat where it almost never happens.

    Were your redesigns where you changed the (X)HTML due to changes in the functionality of the sites?

    Many times, yes. And that’s kind of the point — a redesign is rarely just a visual overhaul. it’s really usually a larger-scale project that add things, removes other things, and changes the structure of pages, as well a the look and feel.

    But even in cases where you’re only changing the visuals, you often have to change markup. You may need extraneous elements to hang styles on. You may need to group chunks of code differently (as in, rearranging your divs — perhaps your nav was on the left, but now it’s in the header, for example. This will almost certainly require markup changes).

    And if so, isn’t it convoluting this discussion by mixing “redesigned” with “evolving”?

    Possibly. I guess my experience has been that there’s rarely much “evolving” involved in full-scale redesign project. Of course, you evolve in between redesign projects, and in those cases, you want your markup and CSS as separated as possible. But I don’t think Blueprint’s class naming scheme prevents this, either.

  33. 033 // Olav Bjorkoy // 08.10.2007 // 6:34 PM

    Great post Jeff, I think I’ll redirect people here when they complain about such classes.

    The people commenting at Digg.com were especially outraged at this, although that might not be the best place for constructive criticism.

  34. 034 // Jeff Croft // 08.10.2007 // 6:36 PM

    The people at Digg.com would be outraged at the sun coming out after 10 straight cloudy days.

  35. 035 // Erik // 08.11.2007 // 5:33 AM

    I don’t think the “non-semantic semi-visual” class names is a problem at all.

    Blueprint is a framework, and the class names are not only documented, they also have a very specific function.

    Anyone who wants semantic class names can just add their own.

    Actually, what would the most semantic name for a class that is only used to add a border/colour/other-visual-feature, be?

  36. 036 // Andrew Ingram // 08.11.2007 // 6:18 AM

    I’ve been thinking a bit more about this and I can’t help but think that there’s been a long-term serious misunderstanding about what separating content and presentation actually is.

    Using CSS and Semantic Markup was never intended to mean that you never change the HTML. The CSS Zen Garden was only meant to highlight what is possible when just the CSS changes, it’s a demo of the power of CSS - not a lesson in separating content and presentation or how to code for the semantic web.

    The whole point of separating modules isn’t to let us just ignore one of them from that point inwards (in this case html), but rather to let us make small changes without having to redo vast amounts of presentational code. Often you can completely refactor your CSS to optimise it without having to touch the HTML - though I usually find myself removing unnecessary HTML tags every time I try to improve the CSS.

    There are occasions (and they’re not actually all that common in my experience) when I actually have to add extra HTML so that I have some extra hooks to use. In those situations I refactor the HTML to give me that extra tag but in such a way that the extra tag has semantic meaning.

    As I’ve said in a previous comment there are situations where you may have to add markup purely for presentational purposes, multi-column text being the obvious example. But these situations should become fewer and fewer as CSS becomes more powerful. Heck there’s no reason why one day CSS can’t be used to actually add invisible presentational tags to the markup that it can use but which don’t appear in the HTML.

    Right now CSS isn’t ready to take the full load of all presentational needs, but there’s every reason to believe (ignoring the excessive the bureaucracy) that one day it will be able to.

    Oh, and the fuss about microformats isn’t that it’s a better way to do snippets of HTML, but that it’s a consistent way. Take hReview for example, a search engine that is based on crawling microformats would be able to take a query like “Doctor Who Review” and return just the pages that have reviews, rather than pages that merely feature those words. Semantic class names mean that one day search bots will be able to assign more meaning to content and provide even more accurate search results, but they aren’t that intelligent yet so we can help them out by providing standardised constructs for certain things - allowing the bots to look out for these things.

    I realise this is all very idealised, but my personal opinion is that I’m wasting my time if I’m not trying to achieve an ideal solution.

  37. 037 // Luke // 08.11.2007 // 10:03 AM

    I totally agree Jeff. Anyways, what’s to stop you from adding a third, more descriptive class to the element, or an id attribute that is more descriptive? Nothing I can think of. I really am enjoying playing with blueprint. I am actually borrowing ideas from it to incorporate into my company’s css “framework”. I really appreciate the work you did there… good job.

    offtopic… I used to like digg, and I’d get some of my news there, but the more I went there the more I realized that the people who go there just love to whine and talk crap about anything and everything even though a good majority are just know-it-alls with no actual talent /offtopic

  38. 038 // Scott Reynen // 08.11.2007 // 10:28 AM

    I think treating presentational markup as somehow non-semantic was always a mistake. Presentation is just a specific type of meaning. Meaningfulness is not a binary switch; it’s a spectrum. Class names should be as specific or as general as appropriate for describing the known meaning of each element. If you know nothing more about the meaning of an element than its presentation, presentational semantics are appropriately specific.

  39. 039 // Jeff Croft // 08.11.2007 // 2:18 PM

    Actually, what would the most semantic name for a class that is only used to add a border/colour/other-visual-feature, be?

    :) Exactly. If the class is solely to apply a visual element, there isn’t one. Anything you could come up with with be a stretch. span-x is a stretch, but I don’t think there was anything more semantic we could have used, instead.

    Using CSS and Semantic Markup was never intended to mean that you never change the HTML.

    It may not have been intended to mean that, but web standards advocates everywhere use it as ammo for why we should use web standards all the time. I know I have.

    The whole point of separating modules isn’t to let us just ignore one of them from that point inwards (in this case html), but rather to let us make small changes without having to redo vast amounts of presentational code.

    Yes, I agree. And there’s a ton of benefit in this separation. As I said in the post, I believe it’s a noble goal with real benefits, and something we should always strive for. But if 90% semantic-ness plus some visual class names gets you a massive productivity increase over 100% semantic-ness and you still get 90% of the benefits of separation, then I’m going to go with 90% every time.

    In those situations I refactor the HTML to give me that extra tag but in such a way that the extra tag has semantic meaning.

    Can I ask why? I would imagine it’s because you’re a perfectionist. And that’s great, man. I tend to be, too, and I would do the same thing (try to find a way to doit semantically). But why do we do this? I would contest it’s only because we are perfectionists and we want our code to be as clean and elegant as possible. I don’t believe you can justify this by saying it helps your users, the site’s performance, usability, design, maintainability, etc. Can you? It just helps make the code prettier. Which is great — but not my top priority.

  40. 040 // Jeff Croft // 08.11.2007 // 2:19 PM

    But these situations should become fewer and fewer as CSS becomes more powerful.

    This is absolutely true. If CSS3 were fully supported in every browser, something like Blueprint would look very, very different. But it’s not, so those of us who have real work to do for real clients who have real websites that are viewed by real users using real (crappy) browsers have to find ways of dealing with what the reality of today. The reality of today, in terms of browser support for CSS, is that it’s 100% better than it was a few years ago, but it’s still not great.

    I hope in a few years solutions like Blueprint’s class-naming will be looked back upon and laughed at. For today, though, it’s very useful.

    Oh, and the fuss about microformats isn’t that it’s a better way to do snippets of HTML, but that it’s a consistent way.

    I understand what Microformats are and how they work. My point is: designers are all aflutter about making their HTML super-semantic and all the while most of them have no semblance of semantics in their database. Most of them are using WordPress or MoveableType’s database structure to store things it was never intended for. These are blogging platforms, and people are using them for everything from photo galleries to portfolios to a showcase for web browser plug-ins (PimpMySafari). It just baffles me that designers can care soooo much about he data sent to the client (the markup) and not care one bit about the semantics of the data in their database. Microformats are a great idea, and one that are made much, much, much easier to implement if you simply start caring about the structure of your data before it gets to the HTML rendering stage.

    That’s all I was saying — but that’s another post entirely.

    I realise this is all very idealised, but my personal opinion is that I’m wasting my time if I’m not trying to achieve an ideal solution.

    Keep on trying, man. And I will too. But in the meantime, I’ve got work to do, and I need solutions that let me get it done quickly and elegantly. Blueprint is one of those solutions.

  41. 041 // Jeff Croft // 08.11.2007 // 2:19 PM

    Anyways, what’s to stop you from adding a third, more descriptive class to the element, or an id attribute that is more descriptive?

    Nothing at all. You should, and we did! :)

    Presentation is just a specific type of meaning.

    That’s an interesting way to look at it. Well-said, man. I still think it’s best to avoid purely presentational class names, ids, and elements, but you’re right: at times, that’s all you know about an element, and in those cases, I see nothing wrong with using them.

  42. 042 // Rebecca // 08.11.2007 // 2:34 PM

    Of course the HTML is going to change in a redesign; any redesign should involve a rethinking of the content as well as the visual design. But using non-semantic class names (ie, span-4) is like naming variables $string1. It gives no reference points for scanning the code, it is ten times harder to reuse styles, and it requires unnecessary changes in markup: decent markup should be reusable, in part if not in whole, within any new design.

    On the other hand, frameworks kind of change the game when you’re using them for every aspect of a project [content, markup, presentation].

  43. 043 // Jeff Croft // 08.11.2007 // 2:55 PM

    But using non-semantic class names (ie, span-4) is like naming variables $string1.

    No, it’s not like that. I think you might misunderstand what span-4 means. span-4 means that a column spans four grid units. It isn’t meaningless at all (like $string1 is). It has a lot of meaning — it’s just presentational meaning.

    And, if you want reference points for scanning your code, just add a semantic ID. The class names don’t get in your way at all. And, as Wilson said, class names aren’t an exclusive namespace.

    it is ten times harder to reuse styles

    I definitely disgree with that. The beauty of Blueprint is massive class reuse.

    decent markup should be reusable, in part if not in whole, within any new design.

    I agree. That’s the point of my post: “in whole” is almost never attainable, but “in part” certainly is. Blueprint achieves “in very large part.”

  44. 044 // Jeremy Keith // 08.11.2007 // 6:27 PM

    Just for the record, whenever I add a new skin to my site I don’t change the markup; I just create new style sheets. I quite enjoy the design challenge of working with that constraint.

    My situation is a bit different from most redesigns though: I don’t throw the older design away, I just add the new design as an alternative choice.

  45. 045 // Jeff Croft // 08.11.2007 // 7:15 PM

    I quite enjoy the design challenge of working with that constraint.

    Oh sure, it’s a fun challenge. But, as you said, that’s not like most redesigns. Besides the fact that you are only offering a new design as a choice, you’re talking about a personal site. No deadlines, no client requirements, etc.

    Sometimes I wonder if the people who hate these time-saving concepts like frameworks ever have worked in the real world. Of course you can take all the time you want to make your personal site perfect. But working on sites for client is another matter entirely.

    :)

  46. 046 // Ludwig Wendzich // 08.12.2007 // 2:53 PM

    I guess if you don’t want to ruin your semantic markup you could always use some DOM scripting and insert the span-x classes etc into your markup then. Ofcourse that complicates the matter and unless you are very profficient at Javascript could defeat the point of using a framework. Using Javascript also increase the files and loading times further.

  47. 047 // Jeff Croft // 08.12.2007 // 3:11 PM

    That’s a clever idea, Ludwig, but the purists who think Blueprint mixes the content and presentational layers would probably say that using DOM scripting doesn’t solve the problem, it just moves it: now you’re mixing the behavioral and presentational layer.

  48. 048 // Greg // 08.12.2007 // 8:53 PM

    But the idea that a redesign of anything more than the most basic of sites will not require changes to (X)HTML markup is simply a myth.

    Really? In February 2006 I was part of the team that redesigned globeandmail.com — the website of the Globe and Mail, Canada’s national newspaper. During that redesign we severely altered the (X)HTML by gutting any tables that were being used and by providing the structure with semantic id’s and class names. This past spring, the website underwent another redesign… and here’s the thing: instead of 7 of us working on the website redesign there were only 2 of us and we didn’t touch the (X)HTML. Changes were made to the stylesheets and everything just worked! Check out what the homepage looked like about a year ago and then take a look at the current version.

  49. 049 // Jeff Croft // 08.12.2007 // 9:12 PM

    Greg: Well-done. As I’ve said numerous times now, it is possible to redesign a site without changing the (X)HTML. However, it’s rare. Of the 54 comments on this thread, only two people have refuted the fact that markup usually needs to be changed. You are the exception, not the rule. Congratulations to you for that. Keep up the good work.

  50. 050 // Ludwig Wendzich // 08.12.2007 // 11:26 PM

    That’s a clever idea, Ludwig, but the purists who think Blueprint mixes the content and presentational layers would probably say that using DOM scripting doesn’t solve the problem, it just moves it: now you’re mixing the behavioral and presentational layer.

    If you give your elements semantic ids then you could easily just give them the correct class for the framework. This would ofcourse all be in a seperate .js file from your behavioral scripting and would mean that your HTML document retains its integrity and the presentational JS is seperate from the behavioral JS. This is being down with divs for rounded corners and it seems acceptable. I don’t see why not in this situation.

    I think the benefit here is that with Javascript you can seperate the presentational scripting from the behavioral scripting (which is what the behavioral layer is for, ironically) however in HTML you can’t seperate the structural markup from the presentational markup.

    I hope you understand what I mean.

  51. 051 // Jeff Croft // 08.12.2007 // 11:59 PM

    …it seems acceptable. I don’t see why not in this situation.

    Oh, it’s totally acceptable…to me. But I’m not a hard line standardista type. I’m more interested in getting things done quickly that work well than I am in doing things 100% “by the book” everytime — but there are definitely people in this industry that would rather be righteous than successful.

    So — I totally know what you mean, and I’m all for it. I was just kind of warning you — you might get some push back from the hard liners, just like Olav has gotten some push back from them on the non-semantic class names. :)

    I think the benefit here is that with Javascript you can seperate the presentational scripting from the behavioral scripting…however in HTML you can’t seperate the structural markup from the presentational markup.

    Indeed. Good point.

  52. 052 // Ludwig Wendzich // 08.13.2007 // 12:42 AM

    Oh, it’s totally acceptable…to me.

    Hmmm okay, it seems that a lot of people say that using unobtrusive JS to place the extra divs in, to avoid divitis, is OK.

    Anyway, Blueprint is great, take it or leave, it does little to harm your markup because you can always add another class to describe the content :)

  53. 053 // Jesse // 08.13.2007 // 2:16 PM

    You almost had me convinced Jeff, but there is one huge flaw in your argument (you cannot separate presentation from content.) By using the “Blueprint” framework (or any other CSS framework for that matter) rather than semantic class names you are actually creating a presentation-content dependency! Think about it for one second… Yes, by using a non-semantic class name you are not really hurting anything. But since that class name is part of a framework which gives that class name presentational information, you are now saying, div X has presentational information ABC. Now, when you go to do your redesign you must change the HTML markup. You can’t simply change the CSS because it is part of a framework!

    Now, suppose you gave div X a more semantic class name such as “externalAd.” Now when you are doing your redesign, there is no need to change the CSS class, because it still makes sense. Now all you need to change is the styles for that class name. People like Greg (Comment #53) are the ones who are pushing the limits and are proving that standartista ideals can work in the real world.

    Also, one other thing I’d like to point out…when doing a redesign, it almost always is the case that you need to edit your HTML markup. But, if you are doing this so that you can change your presentation, then you have bad HTML markup. The reason to change your markup is because the structure of the page needs to be modified. For example, with well thought out markup and CSS, changing a navigation element from a horizontal nav bar at the top of the page to a vertical nav bar on the side of the page should be fairly simple. But even with the most well thought out plans, doing something like moving a “recent comments” block from the “sidebar grouping” to the footer area should require changing the HTML markup because now you are associating that block with a different grouping of content. It’s not just stylistic in this case, it’s also a structural redesign. You simply cannot lump the two together as one. That is why you should be refactoring your HTML markup - for structural changes, not presentational changes.

  54. 054 // Jeff Croft // 08.13.2007 // 3:56 PM

    By using the “Blueprint” framework (or any other CSS framework for that matter) rather than semantic class names you are actually creating a presentation-content dependency!

    Jesse, I think you kind of missed my point (maybe I didn’t articulate it clearly enough). My point was that even without a framework, it’s nearly impossible to redesign without changing your markup — so adding a framework in loses you nothing. yes, you’re creating a dependency between your markup and your CSS, but my point was that such a dependency already exists, even before the framework enters the picture.

    Now, suppose you gave div X a more semantic class name such as “externalAd.” Now when you are doing your redesign, there is no need to change the CSS class, because it still makes sense.

    Of course. And that’s brilliant, if every single site you every create has an “externalAd,” If they don’t, you have to come up with a new class/id name every time. Which is fine — but it takes longer. Using a CSS framework is a tradeoff. If you use one, you will not be able to achieve 100% semantic purity. If you don’t, you won’t be able to achieve maximum speed and efficiency.

    Whether speed or semantics are more important probably depends on the project. Our grids.css file (which eventually got integrated into Blueprint) was created in an environment where fresh new grid layouts often had to be created in a matter of an hour or two, to accommodate a breaking news story. For us, speed was more important. For you, it may not be.

    But, if you are doing this so that you can change your presentation, then you have bad HTML markup. The reason to change your markup is because the structure of the page needs to be modified.

    Of course. But that’s beside the point. The point is, you’ll almost always have to revisit the (X)HTML. If you have to revisit the markup, then you can revisit the grid-oriented class names while you’re there without losing any efficiency. If you never had to revisit the markup, the adding in Blueprint would slow you down, because you’d have to add chanign your markup to your workflow. But if you have to change your markup anyway, it’s not a new step.

    Why you have to change your markup (presentation or structure) is irrelevant. The point is that you do have to change it when you redesign, almost always (both presentation and structure almost always change during a redesign).

    People like Greg (Comment #53) are the ones who are pushing the limits and are proving that standartista ideals can work in the real world.

    I’m not convinced. One guy said it worked for him. Everyone else — including you — has said they almost always have to change the markup when they redesign.

  55. 055 // Jesse // 08.13.2007 // 5:15 PM

    Regarding Blueprint…

    If the situation is that you need various layouts within a matter of hours, then yes, I’d have to agree that using a CSS framework would be very useful and would cut cost and development time considerably. Unfortunately, I can’t think of many sites with that requirement. For that small audience, it is a brilliant idea, but for the majority of web developers, this very rarely the case.

    Now, on behalf of the other 95% of us who don’t have these requirements…in which a redesign usually takes months as opposed to hours…

    The point is, you’ll almost always have to revisit the (X)HTML. If you have to revisit the markup, then you can revisit the grid-oriented class names while you’re there without losing any efficiency.

    But when you are redesigning a website, you’re always going to need to revisit the CSS as well. Often times your new layout is going to be completely different from the original version, so the styles will likely need to be completely rewritten. I am currently working on a redesign moving from a fixed width 3-column layout to a much more complicated varying width 2-column based layout. The old markup and the old CSS is completely useless to me. If the previous developer had used a framework, would it have cut down on my development time? Honestly, probably not.

    Sorry for sounding pompous, but CSS isn’t exactly brain surgery. When it comes to training new developers (which unfortunately happens quite often at my company) would I rather have them know how to use arbitrary class names to finagle a CSS layout, or would I rather have them actually know CSS and be able to understand the code behind the layout? I think you can guess what my answer would be :). A developer who knows and understands CSS shouldn’t need a framework. Why limit developers into using a rigid set of rules which often times they’ll need to break anyways?

    So for people who need a quickly changing CSS layouts, I think a CSS framework is a perfect fit. But developers need to pick the right tool for the job and for the other 95% of us developers out there, I would say that easily integrating a pre-made framework into a large-scale, already-existing website, is a fairy tale. And if you’re building a site from the ground-up (which isn’t going to be redesigned in say, a year), then how much time would learning, integrating, and using a CSS framework actually save??? Wouldn’t it be much more beneficial to learn CSS instead of a CSS framework?

    Don’t get me wrong, Blueprint seems like a very useful tool, but it’s almost as if all web developers have been brain washed into thinking that a CSS framework is something that they need for their website, when in fact, if your site won’t benefit from it, integrating one may actually hurt you and your team in the long run.

  56. 056 // Jesse // 08.13.2007 // 5:16 PM

    Regarding presentation vs. content…

    I’m not convinced. One guy said it worked for him. Everyone else — including you — has said they almost always have to change the markup when they redesign.

    That’s because we’re redesigning crappy, old websites which didn’t follow the standards in the first place :).

  57. 057 // Jeff Croft // 08.13.2007 // 5:46 PM

    For that small audience, it is a brilliant idea, but for the majority of web developers, this very rarely the case.

    Well, that’s the situation we created it out of. And I’ll bet that situation is a bit more common than you expect. But you’re right — there are a lot of people that don’t have those kind of deadline requirements and can feel free to take the time to achieve 100% pure semantic goodness every time.

    But when you are redesigning a website, you’re always going to need to revisit the CSS as well.

    I agree. My point is that you always (or almost always, anyway) have to revisit both. Books and standards advocates will often tell you that’s not the case, though. They’ll say, if you design your site correctly, you won’t have to edit the (X)HTML at redesign time. The point of my post was to point out the inaccuracy in this commonly-held belief. It sounds like you and I both agree: you’ll almost always have to edit both markup and CSS when you redesign.

    …or would I rather have them actually know CSS and be able to understand the code behind the layout?

    Oh, I would never suggest that anyone should use Blueprint without first fully understanding CSS. Just like you can’t use Rails well without knowing Ruby and you can’t use Django well without knowing Python and you can’t use YUI well without knowing JavaScript. Frameworks aren’t a substitute for learning a language. I never suggested they were — and I would never suggest that. I agree with you completely.

    it’s almost as if all web developers have been brain washed into thinking that a CSS framework is something that they need…

    Again, I agree. There is fair too much following that goes on in our community. Just as I wouldn’t want people to use web standards just because Jeffrey Zeldman said it was a good idea (I’d rather them understand the benefits and decide for themselves that it’s good idea), I also wouldn’t want people to blindly accept a CSS framework because I said it worked for us in the situation we were in. Each person needs to evaluate their needs and decide which tools are best for the job. They can’t do that very well if they don’t understand the tools.

    The Rails hype machine is a great example. Thousands of kiddos are running around spouting off about how great Rails is, and only a few of them even understand how Rails works or knows Ruby. I hate the follow-the-leader-ness of our industry. It’s very frustrating.

    Sounds like we don’t disagree much at all, Jesse. :)

    That’s because we’re redesigning crappy, old websites which didn’t follow the standards in the first place :).

    Heh. Perhaps so. Get back to me in a couple of years and let me know if you were able to redesign the ones you’ve just redesigned without changing the markup. It will probably be a bit more regular amongst redesigns of standards-based sites, but I still doubt if it’ll be common at all.

  58. 058 // Christian // 08.13.2007 // 8:16 PM

    Personally, I have redesigned sites by simply changing out the CSS. If you’re talking about content changes then of course you’ll have to change the HTML. I don’t think there’s any controversy there. Nobody ever said, “CSS is so cool because it lets you change the content of your HTML!” So why people are bringing up content changes is beyond me (and, yes, I know that there is some power to affect content with CSS). And if you’re talking about changing the functionality then that might also require changes to the HTML. But to call the separation of content and presentation a myth is going too far. And quite often I find that people who know HTML pretty well could stand to learn it better.

  59. 059 // Jeff Croft // 08.13.2007 // 8:42 PM

    Christian: No one is talking about content changes. No one said anything about content changes at all. Some people are, however, talking about structural changes.

  60. 060 // Christian // 08.13.2007 // 9:01 PM

    My comments about content were mainly referencing comments #15 and 23, both of which talked about content changing on a site. However, I will edit my remarks to leave out the part about content and my remarks will still be true, worthwhile, and valid:

    Personally, I have redesigned sites by simply changing out the CSS. If you’re talking about changing the functionality of a website then that might require changes to the HTML. But to call the separation of content and presentation a myth is going too far. And quite often I find that people who know HTML pretty well could stand to learn it better. The fact that there ARE sites out there that can have their presentation (including their layout) changed simply by changing the style sheet proves that the separation of content and presentation is NOT a myth. Yes, I’m fully aware that sometimes there’s no getting around modifying the HTML but that doesn’t invalidate the many times when it does not to be changed.

    Additionally, as some other commenters have pointed out, HTML is not just content but structured content. But it’s important to not confuse structure with presentation.

  61. 061 // Jeff Croft // 08.13.2007 // 11:07 PM

    Christian, I agree that it’s possible to redesign a site without changing the markup. I mentioned in the post that I have done it before, myself. But I find it to be very rare. Of course, this depends on the type of site, the frequency of the redesign cycle, the severity of the redesign, how much the structure of the content as it exists in HTML matches the new structure you want with the redesign, and so forth.

    I’m not debating that it’s possible. It definitely is possible. I’m simply saying that in real-world project, with the types of clients many of us web professionals deal with on a regular basis, it’s very rare.

  62. 062 // cpawl // 08.13.2007 // 11:50 PM

    Jeff- In the time you took out of your day to write this article and comment on it you could have easily defined semantic class names to at least 15 redesigns. The reality is that it is not that hard and does not take that much time to call a “cat” a “cat” rather than label everyone as “feline-4x”. If you don’t have time in your job to get involved in your work or to spend more than an hour re-designing a website a client probably paid 30 times your daily wage on then…

  63. 063 // Jeff Croft // 08.13.2007 // 11:56 PM

    Jeff- In the time you took out of your day to write this article and comment on it you could have easily defined semantic class names to at least 15 redesigns.

    Too bad I’m not working on 15 redesign projects right now, huh?

    The reality is that it is not that hard and does not take that much time to call a “cat” a “cat” rather than label everyone as “feline-4x”.

    Right. The process of adding the class names takes no time at all. It’s the writing and testing of the CSS that does. That’s all taken care of ahead of time by Blueprint.

    If you don’t have time in your job to get involved in your work or to spend more than an hour re-designing a website a client probably paid 30 times your daily wage on then…

    You know what, cpawl? You don’t know me, and you have no right to suggest such a thing. Personal attacks — on me or anyone — are not tolerated here. Disagreement and discussion of the topic at hand is welcome — assholish behavior is not. You know nothing about me, my work ethic, my clients, or my rates. How dare you, man.

    Come to think of it, you’ve been an ass in almost every single comment you’ve ever posted on this site. Consider yourself banned from commenting here.

  64. 064 // Richard Medek // 08.14.2007 // 2:36 AM

    I always try to use semantic class names when marking up a document, mostly because I usually end up handing off the HTML/CSS to a developer and it’s easier for them to see what’s going on if they need to edit anything. Plus, even though semantic class names aren’t really the crux of the standards movement, they contribute a bit (at least in spirit) and I’m web-nerdy enough to shoot for “perfect” HTML if I can get there.

    Having said that, I really don’t see any harm in a non-semantic class name. A class name—any class name—is a arbitrary title given to an attribute of a completely non-presentational element. There’s no harm to accessibility, none to search engine parsing, none to cross-browser viewing. The only thing I can think of is the possibility that “span-4” might need to be changed to “span-3” or something and that’s accomplished with a five second find-and-replace. In other words, what I’m trying to ask is…with all the hemming and hawing about how using a non-semantic class name is awful for web development, can anyone provide an actual, real-world example of some sort of harm brought on by using one?

  65. 065 // Aleksey // 08.14.2007 // 7:03 AM

    100% sematic (X)HTML is great and all, but to me the right solution is the one that maximizes quality/spent time/price ratio.

    Haven’t yet tried blueprint myself, but after reading about it and walking through the tutorial, I should say its advantages greatly outweigh its shortcomings and its use should be the right solution in most cases.

  66. 066 // Anton // 08.15.2007 // 10:52 AM

    So, we’ve got javascript frameworks, and now a css framework - but why didn’t anyone start with an (x)html framework where it all begins?

    Here’s what I’m trying to wrap my head around: assuming I were to use something like Blueprint, if I make MINOR adjustments to a block item, including a grid shift or similar layout tweak - does it make more sense to adjust the respective id style in the css, or are we expected to go in and change that block item’s classname in each html file?

  67. 067 // Jeff Croft // 08.15.2007 // 11:18 AM

    Anton: You would change it in the HTML, not the CSS. As for “each HTML file”: surely you wouldn’t have to change it in more than one place, right? I mean, doesn’t everyone use back-end templating these days? If you’ve got the same element duplicated in multiple HTML files, then I’d say your HTML isn’t very optimized. :)

  68. 068 // Ryan Chapman // 08.15.2007 // 12:47 PM

    Thanks for the intro to Blueprint. I agree that the html is going to have to change during most redesigns. Since I do programming and design I’ve always wondered about the parsing costs of having css modules in my database and calling them dynamically allowing me to have a whole set of modules that would serve as the framework with my static css file including the final presentation styling.

  69. 069 // Fredrik // 08.15.2007 // 1:07 PM

    but why didn’t anyone start with an (x)html framework where it all begins?

    Umm. Are you telling us that you don’t use an (x)html framework (that is, a templating system) for your sites? If you’re adding CSS framework ids/classes to anything but your templates, you’re definitely not using the framework in the right way.

  70. 070 // Jeremy Keith // 08.16.2007 // 3:57 AM

    Jeff, this just a brief aside and it has nothing to do with frameworks but I just wanted to draw your attention to a little discrepancy.

    In your response to Christian you say “Christian, I agree that it’s possible to redesign a site without changing the markup… I’m not debating that it’s possible. It definitely is possible.”

    But the entry summary for this post reads “In which I suggest that redesigning a site without touching the markup is simply impossible.”

    I think it was this assertion that led Christian and myself to point out examples of redesigns that don’t involve changing the markup. Your tone was somewhat strident in calling this practice impossible (in the summary) and “a fairy tale” (in the post); hence the counter-examples. I’m glad that you clarified your position in the comments. You may wish to update the post or the summary accordingly. Or not… I’m not trying to tell you how to run your site. :-)

    I now return you to your regularly-scheduled framework discussion.

  71. 071 // Jeff Croft // 08.16.2007 // 4:01 AM

    Fair enough, Jeremy. You got me. I said “impossible” in one place, when I meant, “nearly impossible for anything other than a super-simple site” (like yours, for example). I think in the actual post I made my point more clear.

    But you’re right. You got me. I hope it feels good. Pointing out the shortcomings of others is great, isn’t it? :)

  72. 072 // Jeremy Keith // 08.16.2007 // 4:15 AM

    Jeff, please, don’t take it so personally. What I was trying to do was clarify why Christian and myself were responding with our examples.

    The only shortcoming I’m pointing out is in the line of argument. There is a difference between saying “something is rare” and “something is non-existent”. The first is a relatively straightforward position to defend: others can argue against it but it’s hard to disprove. The second is a very binary argument and can be disproved by a single instance that contradicts it.

    This is why scientists talk in terms of theories and experiments rather than immutable positions.

    Again, please don’t take it so personally. It was not meant as a criticism of you, it was meant as a clarification of the responses from Christian and myself.

  73. 073 // Jeff Croft // 08.16.2007 // 4:34 AM

    Jeremy, I said you were right and I was wrong. You found a hypocrtisim in my wording. No futher clarification is necessary. I didn’t take it personally at all. I just acknowledged that you were right. I should have said “almost impossible,” rather than “impossible.” I’ll update the summary, as you suggested.

    I would have expected the smiley to signify that my “pointing out the shortcomings…” comment was a joke — sorry if that didn’t come across.

    (On a side note, it’s interesting and surprising to find out that anyone actually reads those summaries.)

  74. 074 // Anton // 08.16.2007 // 12:57 PM

    Jeff Croft

    I mean, doesn’t everyone use back-end templating these days?

    Fredrik

    Umm. Are you telling us that you don’t use an (x)html framework (that is, a templating system) for your sites?

    To clarify, I wouldn’t have any problems with this in my own (x)html, because I do happen to use frameworks and templates. However, I am well aware of some large corporations that are either forced to use legacy code from years back, or are either unable to, or not permitted to use dynamic pages under some conditions (yes, these types of conditions suck).

    So, web teams in those circumstances, are likely to use stylesheets (an obviously non-dynamic format) to do nearly dynamic layout control. Change the stylesheet and magically update the look of thousands of pages, isn’t that the point of CSS anyway?

    Don’t get me wrong, I’m not coming here to say that this is a bad thing (I actually think it can be quite useful). But trying to play devil’s advocate in wondering if this isn’t going to get abused or mis-used by designers who’ll end up editing more html than they do css to get layout changes done.

  75. 075 // Jeff Croft // 08.16.2007 // 1:07 PM

    However, I am well aware of some large corporations that are either forced to use legacy code from years back, or are either unable to, or not permitted to use dynamic pages under some conditions (yes, these types of conditions suck).

    In that case, I probably wouldn’t recommend using Blueprint. Those people have bigger fish to fry at their organizations than reuse of CSS code. :)

    Change the stylesheet and magically update the look of thousands of pages, isn’t that the point of CSS anyway?

    Sure, but Blueprint doesn’t supecede that at all.

    But trying to play devil’s advocate in wondering if this isn’t going to get abused or mis-used by designers who’ll end up editing more html than they do css to get layout changes done.

    Using Blueprint, to change the layout, you will edit your HTML templates. There’s no way around it. To me, this is a non-issue, because I consider he HTML templates part of the presentation layer, anyway (my content layer is my database).

    Using Blueprint, you don’t have to edit HTML to make style changes — only layout changes. I still maintain that 90% of the time, you have to make changes to the HTML in order to effect a layout change without Blueprint, too.

  76. 076 // Adrian L. // 08.17.2007 // 9:29 AM

    With all due respect to those people who think that CSS Zen Garden is about design, I think all of you should go back to your first year design textbooks and read the first line. For those of us who didn’t study design at the university level (me, for example) it probably goes something like this:

    Graphic design is the practice and methodology of presenting information in a manner that enhances the message.”

    CSS Zen Garden is about style. It is about aesthetic. It is about CSS/XHTML wizardry. There sure is some pretty stuff there, but it sure as hell is not about graphic design, and it sure as hell is not about presenting information ina manner that enhances the message.”

    Yes. I have a bee in my bonnet about the Garden, but I’m no link whore. If you’re really interested in it, you can go look for it on my site. It won’t be hard to find.

    Rest assured I consider the Garden to be one of the (many) crappier things to happen to the web design community. Pretty cool practice for stylists and front-end coders though.

    CSS/XHTML is a tool. Like Photoshop and Moleskines and pencis and paints and tubas, each of us use these tools differently. Jeff is absolutely right, that we cannot separate content from presentation. What we can do is assure that our content is accessible when stripped of its presentation - like the transcript of a television programme. We can assure this by coding to standards and thinking about the people who are making use of the information we are presenting.

    cos just like the hokey-pokey, that’s what it’s all about.

  77. 077 // Gabe da Silveira // 08.17.2007 // 7:46 PM

    Like Adrian before me, I agree that Jeff is totally right. Unlike Adrian however, I am a link whore.

    My response got too long so I stuck it in an actual post

  78. 078 // Christian // 08.20.2007 // 1 PM

    Whether the Zen Garden is about “design” or not is irrelevant to the discussion here. What it shows is that content structured with the exact same HTML code can be presented, formatted, and laid out in different ways simply by changing the style sheet.

    I still maintain that 90% of the time, you have to make changes to the HTML in order to effect a layout change without Blueprint, too.”

    Not if you know what you’re doing. Yes, I know that sometimes HTML changes are necessary but at least if you know how to structure your HTML properly from the outset you can make the separation of content and presentation much more of a reality than a fantasy.

  79. 079 // Jeff Croft // 08.20.2007 // 1:05 PM

    …but at least if you know how to structure your HTML properly from the outset you can make the separation of content and presentation much more of a reality than a fantasy.

    Christian, here’s the problem with that line of thinking: it presumes the structure of your documents will never change. That’s a fallacy. In the real world of client work and in-house design, structure of documents changes all the time in the redesign process.

    That’s how the Zen Garden and things like Jeremy’s personal site differ from real-world work. In those cases, structure almost never changes. But in real projects, it has to change…a lot.

  80. 080 // Christian // 08.20.2007 // 1:11 PM

    Well, I’ve handicapped myself because I can’t explain my whole line of thinking without writing a whole separate article. And we are all handicapped here when we can’t sit down and look in-depth at real-world examples. All we are doing is pointing out brief, fleeting examples.

  81. 081 // Andy Budd // 08.20.2007 // 4:01 PM

    Purely out of interest, if one accepts that it’s difficult to separate structure from presentation, or that it’s desirable to conflate the two in return for productivity gains, why not use tables with their built in colspan’s and rowspan’s. Aren’t we simply recreating a feature that already exists?

    One of the benefits I find with abstracting the presentation from the structure is the fact that it allows back end developers to start working on the functionality with little or know knowledge of the front end. By adding more dependancies into the equation, aren’t we forcing programmers to be reliant on the design, building more exceptions into their code and eroding some of the benefits of using CSS?

    I have to admit that I’ve not spent a lot of time looking at Blueprint, so this is more of a philosophical question based on the some the points you and others have raised. It’s very interesting what you and others have been doing, but I wouldn’t want to throw the baby out with the bath water, so to speak.

  82. 082 // Jeff Croft // 08.20.2007 // 4:14 PM

    Purely out of interest, if one accepts that it’s difficult to separate structure from presentation, or that it’s desirable to conflate the two in return for productivity gains, why not use tables with their built in colspan’s and rowspan’s. Aren’t we simply recreating a feature that already exists?

    This is a great question, and a totally reasonable one to ask, given that using Blueprint does, at time, feel like working with tables. My answer is that there is great harm in using tables that doesn’t exist while using Blueprint. In particular, using tables causes a lot of accessibility issues (which I won’t bother to outline, because I know you, andy, are well aware of them). Because div’s, span’s, and other elements Blueprint hangs its styles have no effect whatsoever on presentation (unless styled with CSS, of course), it doesn’t suffer from these problems. As a simple example: if you used tables to layout a page, screen readers and mobile devices would try to render the layout of that table (which, usually, is undesirable, from an accessibility standpoint). If you used Blueprint, instead, you wouldn’t have this problem.

    One of the benefits I find with abstracting the presentation from the structure is the fact that it allows back end developers to start working on the functionality with little or know knowledge of the front end.

    In the situation that back end developers are crafting the HTML, this makes sense. However, I’ve never worked in that environment. The environment this was created out of was one in which we designers crafted the HTML templates — the back end developers never touched them. It worked great for us. We created it specifically for us and never planned to release it (we never would have, ourselves) — as such, it might not work in all enviroments. But, it worked well in ours.

    …but I wouldn’t want to throw the baby out with the bath water, so to speak.

    I wouldn’t either! I definitely think anyone who is curious about Blueprint should evaluate it and decide if it works for them. As with most frameworks, it will be more beneficial to people working on many sites, and working on teams. Solo designers and/or designers working primary on one or two sites will find it less useful. It also works best in situations where the same people are doing both the CSS and HTML.

    It’s definitely not for everyone — but I don’t think there’s any harm in Blueprint, so it’s worth a look if you think it might work for you or your team.

  83. 083 // Christian // 08.20.2007 // 4:30 PM

    In an e-mail discussion with Jeff I was able to have clarified where he is coming from. I think we came to an agreement that the underlying (X)HTML coding will need to be changed when there are specific types of structural changes (i.e., moving a copyright statement from the footer DIV to a side bar DIV). But not every website redesign necessitates such changes. When those changes are not necessary then simply changing the style sheet should do the trick and can in many, many instances.

    I think that it would be beneficial for the whole wide web development world to see content and structure as two separate things. As I told Jeff, I believe a new mantra of, “Content, structure, presentation, behavior” should replace “Content, presentation, behavior.” Whether that will ever happen or not remains to be seen.

  84. 084 // Jeff Croft // 08.20.2007 // 4:43 PM

    But not every website redesign necessitates such changes.

    I agree with everything you said, except for this little bit. In my experience, almost every redesign of a major site does, in fact, necessitate these types of structural changes. You’re right — it might not be every one — but I think it’s close.

    As I told Jeff, I believe a new mantra of, “Content, structure, presentation, behavior” should replace “Content, presentation, behavior.”

    Structure definitely is really it’s own layer, even though no one really talks about it like that. I think the reason you don’t see web standards people talking about content and structure separately is that it pushes the content layer down to the database level — which is outside the realm of web standards.

  85. 085 // Christian // 08.20.2007 // 5:08 PM

    In my experience, almost every redesign of a major site does, in fact, necessitate these types of structural changes.”

    Regardless of the number or percentage of site redesigns that require such structural changes (be it 10% or 90%) you can change the structure yet still have exactly the same content.

    If I belabor the point any more I’ll look like an obsessive jerk. Over and out . . .

  86. 086 // Jeff Croft // 08.20.2007 // 5:16 PM

    I know, Christian. I’m totally agreeing with you. I’m just saying, 95% of the time, I have to change the HTML when I do a redesign. It is, effectively if not technically, part of my presentation layer, since I have to change it when i want to re-do the presentation. Therefore, i don’t mind if that HTML has some presentational elements in it. That’s all.

  87. 087 // Russell Heimlich // 08.27.2007 // 3:38 PM

    Redesigns? Isn’t the idea to gradually evolve over time now instead of cutting things loose and starting over? I totally agree that the idea of only changing a stylesheet seems absurd, but what is more absurd is the notion that you would scrap everything and give a site a completely new look. (My prospective is from a large, media website not a small, company website).

  88. 088 // Jeff Croft // 08.27.2007 // 3:57 PM

    Russell-

    The idea that you evolve gradually over time is a nice one, and one I’d strive for, myself. However, it’s not always practical. I also have worked on large media sites (newspapers, TV stations, etc.) and while we always did evolve over time, we also always found there came a time when things just needed to be started over, design wise. The last design of LJWorld.com lasted us over four years — but we did eventually have to throw it out and start anew. After that long, enough things have changed and you’ve improved enough that you’ll want to start over. Hell, I hate half my designs six months after I do them. :)

  89. 089 // Steven Champeon // 08.27.2007 // 5:56 PM

    By the same logic you’re using, we should stop using abstraction, because every time we think it’s about something else. And that’s silly.

    I spent years, both in my role as CTO of hesketh.com, and as the project lead of the Web Standards Project, trying to help people who didn’t understand the basic concept at hand. It’s not an easy concept to grasp, and unfortunately, it’s a really easy concept to dismiss - when you don’t understand it - and that’s too bad, especially when it can save you time, pain, money, and grief.

    At its simplest, the basic idea is that content (loosely defined, these days, but I always like to use text as the example) should be encapsulated (i.e., wrapped in markup) in a construct to which differing styles may be applied at presentation time.

    Back in the old days, this could have been SGML files wrapping the content, on one hand, and rules that generated troff or Postscript for a print version, and other rules that allowed for a dynamic, electronic display of the content (say, in expandable outline form). If you’ve never had the bad luck to work with content that IS NOT so separated from its formatting instructions, you won’t be able to appreciate fully how important it is. Try turning a UNIX manual page in its native format into HTML, or a Word5 document into a Windows Help file, and you’ll see how hard it can be. You simply end up stripping out a lot of useless junk and hoping that none of it affected the order in which the underlying content was to be displayed or organized. The basic distinction between “stuff you want to keep” and “incidental stuff that we need in order to view/print/render the other stuff” has been violated.

    On the Web, with its mix of pure content (text, graphics, video, etc.) and so-called “functional” content (layout frameworks, navigation menus, and so forth), you need to be careful to abstract the former from the latter; it can get ugly if you don’t. Confusing a navigation area for a section of a site, or the “layout framework” in which the nav and content will fit, with the text and structure of the press releases that will populate the content areas of each page in that section, or with the generic presentation to be reused by multiple sections across a site, can lead to some deeply weird layout and presentation problems. The cascade and other factors can make it difficult to deal with, but its certainly possible to deal with well.

    Yes, of course you’re right in noting that major Web site redesigns often involve changing the underlying markup. The needs of Web sites (and the organizations for which they are created and maintained) change over time. Sometimes, this involves a rethinking of what’s on the page, where it is on the page, how it works, how it looks, and so forth. That’s not novel nor is it terribly insightful to notice.

    (continued in next comment(s), because your comments system arbitrarily limits posts to 3000 characters).

  90. 090 // Steven Champeon // 08.27.2007 // 5:58 PM

    What’s disingenuous, however, is confusing the recreation of a Web site considered from the standpoint of its functions and content and implementation, with the progressive development and maintenance of a well-designed site whose underlying structure still supports the original mission. And to discourage people from doing as much as they can to make an existing site - whose function, whose mission, hasn’t changed - continue to work, and to allow gradual improvements without massive changes, well, that’s just pointless.

    Before we had CSS and javascript-driven layout frameworks and the like, ANY change to a Web site required massive changes across the board to the underlying markup, on every page, because the markup itself was intimately tied (or tangled, or knotted, or …) up with the presentation. Tables were hard to debug, cross-platform issues made the entire process a nightmare, and many organizations simply abandoned entire sections of their site or were convinced that a radical redesign, or shift to a CMS, or [insert expensive solution here] was required. And that was a waste of time, money, and the potential of the Web site to fulfill its original mission. And it left a very bad taste in the mouths of those organizations when they realized what the Web and their participation in it was going to cost them, repeatedly, for the rest of time. Tools to automate this (CMSes, site managers like Dreamweaver and Contribute, even micro-CMSes like blogging tools) haven’t necessarily changed the problem so much as made its side effects less painful - though they are, or some of them are, getting better at understanding the importance of the fundamental separation. But you don’t need a database-backed, template-driven site to take advantage of the underlying principles. And if the database-backed or template-driven site doesn’t take advantage of the principles, either, you’ve just adopted an expensive and clumsy non-solution to the wrong problems.

    A well-designed Web site (and by this I mean more than simply “pretty visuals” - design is more than what you can see) will, quite simply, allow the gradual adaptation of new visuals, and will lessen the amount of work required to introduce new display/content elements. The best of the breed will also allow for a single small set of styles to be adapted or replaced in order to implement a site-wide visual redesign as well as functional improvements to particular parts of the site.

    We’ve been using that strategy with our clients for several years; the approach to separating content from presentation we call “progressive enhancement”, and the approach to rolling improvements that minimize disruptive large-scale redesigns we call “progressive development”.

    (continued in next comment, because your CMS arbitrarily limits posts to 3000 characters).

  91. 091 // Steven Champeon // 08.27.2007 // 5:58 PM

    They work together to save our clients money and help us develop great ongoing relationships with them - which also helps because familiarity with their sites helps us understand how best to manage their needs on an ongoing basis (as opposed to the agency roundabout that some went through in the late nineties, where every two years saw a complete redesign by a new agency). I saw enough of those in my time with IBM’s PC Company (one) to last me a lifetime. Several months of time wasted for nothing - they ditched the new site within a few months.

    Anyway, just wanted to jump in here and see if I could clarify what you seem to be missing; I’d hate for anyone to see this post and think there was no point in doing a good job on something just because they might end up (needlessly, in my view) ditching it later.

  92. 092 // Steven Champeon // 08.27.2007 // 6:03 PM

    Oh, and to add irony to the whole issue: I found this article by way of a link I found on digg to a set of “45 excellent blog designs”:

    http://www.smashingmagazine.com/…

    You may notice that many of these blogs make use of exactly the set of principles we’ve been talking about: the best-effort separation of content from presentation, proving how successfully the same principles can be deployed in real-life situations. :-) Granted, they use the template/stylesheet/database model for the most part, but the point is still valid - and the wide variety of different functional breakdowns across different blogs as well as the large set of shared functionality, combined with the excellent visual design, suggests that there’s more validity to the principles than you admit.

  93. 093 // Jeff Croft // 08.27.2007 // 6:10 PM

    By the same logic you’re using, we should stop using abstraction, because every time we think it’s about something else. And that’s silly.

    If you believe this, you missed the entire point of what I said. I didn’t say we should stop trying to abstract content and separation — I said it was usually not possible to achieve it 100%. Of course we should keep trying. Like I said in the post:

    It is absolutely a best practice to separate your content, presentation, and behavior layers as much as possible. No doubt, doing so does make for easier maintenance — and brings several other benefits, as well. It’s a noble goal to strive for, and I think we all should do so.

    You and I agree completely, but you’re acting as if we don’t. You’re saying that we should try to separate them, but that “major Web site redesigns often involve changing the underlying markup.” That’s exactly what I said.

    I’d hate for anyone to see this post and think there was no point in doing a good job on something just because they might end up (needlessly, in my view) ditching it later.

    If anyone thinks that, they have clearly not read my words.

  94. 094 // Wayne Elgin // 08.28.2007 // 3:29 AM

    IIRC, Dave Shea made a comment a while ago that he wished he could make some changes to the Zen Garden HTML, but couldn’t because it would break all of the gallery items. Granted, the whole point of the Zen Garden is not shared with functional sites, however, it’s worth pointing out that no matter how much you plan your syntax in advance, you will want to change it.

    The alternate view to this discussion, which I saw some other mentions about, is the accessibility side. That is probably mostly a myth with the current technology, as well. I support the idea of writing accessible code, but we’ve been doing it for so long and we have yet to see accessibility tool devs fulfill their share of the bargain and provide real support for XHTML elements and non-screen-related CSS. It’s a chicken/egg problem of sorts, but it’s also a supply/demand issue and the demand, it would seem, isn’t quite there. Will it ever be?

  95. 095 // John Boardley // 08.28.2007 // 6:21 AM

    At last, a realistic and balanced approach, and a refreshing change from the rantings of the Web Standards Extremists.

    Where web standards and other best practices don’t provide great benefits, find solutions that do.

    is very sound advice, and BluePrint is wonderful.

  96. 096 // Steven Champeon // 08.28.2007 // 9:01 AM

    If anyone thinks that, they have clearly not read my words.

    See your first commenter.

    I must be confused. I read your entire piece, and the message I took away was that when you don’t like the standards, use something else. And this seems to be in defense of a somewhat pointless concern over the naming conventions you use for class names, which as far as I know, aren’t defined anywhere in the relevant standards.

    The “myth” you decry, that you can somehow update the functionality of a Web site solely through the use of new/different CSS without changing any underlying markup, well, I am not sure where you got the idea that anyone had ever claimed that.

    One key real-world benefit of this separation is that come redesign time, one only needs to change or replace the CSS stylesheet, and needn’t lay so much as a finger upon the hallowed grounds we call markup. I’m here to say that this mantra isn’t much more than a fairy tale.

    I think if you go back and re-read whatever it was that implanted that particular belief, you’ll find that what they were arguing was that it’s possible, and beneficial, to structure your markup so that you can change the CSS and in so doing effect a significant change in presentation with a lot less work than if you embed the presentation in the markup itself.

    Nowhere in that claim is the claim that markup and CSS aren’t linked, even inextricably. Nowhere in that claim is the claim that you’ll be able to “redesign” (in a functional sense) a Web site simply by “redesigning” (changing the display).

  97. 097 // JD Vogt // 08.28.2007 // 10 AM

    Amen.

    I’ll go out on a limb here and say that this statement could be qualified to be made even stronger:

    Don’t get me wrong. It is absolutely a best practice to separate your content, presentation, and behavior layers as much as possible. No doubt, doing so does make for easier maintenance - and brings several other benefits, as well. It’s a noble goal to strive for, and I think we all should do so.
    Client websites are finite things. They have a finite budget and a finite time for implementation. Compromises (yes compromises!) are made to accommodate these limits. And at the end of a project you have to answer the question, “Does the site deliver on it’s brand promise?”

    Because time and budget are finite, hours spent creating ‘perfect’ or even ‘ideal’ markup are hours that are not spent on user experience. And if the user experience falls short, well, the perfect code becomes nothing more than an exercise in self-gratification. It unfortunately becomes “Look how clever I am!”

    Separating content from display is generally a good idea. It’s not a good idea when it becomes dogma, especially when that dogma takes resources away from the site as a whole. User experience trumps code every time.

    Thanks Jeff for being a voice of reason.

  98. 098 // Jeff Croft // 08.28.2007 // 10 AM

    @Wayne: Agree with you in general, but I have to say that I don’t see any way non-semantic class names affect accessibility.

    I read your entire piece, and the message I took away was that when you don’t like the standards, use something else.

    That isn’t really the point of he piece, but I did say that. And I did mean it. If standards (or best practices, which is really the case we’re talking about with class naming conventions) don’t serve you well in a particular case, you have to find a solution that does. A good example is video. Web Standards (at least until HTML 5 is available) won’t serve you well for video — there is no video support in Web Standards. As such, you have to find a solution that does server you — like Flash, for example. I fail to see how this can be controversial at all. I’m a huge Web Standards advocate, but the idea of standards for standards sake is stupid. Use Web Standards because they’re useful (and 95% of the time, they are), not because they’re standards.

    …well, I am not sure where you got the idea that anyone had ever claimed that.

    If you don’t think anyone ever claimed that, then why do you take issue with what I said? It seems to me that you agree that it’s nearly impossible to do a large-scale redesign without changing markup (that was the point of my peice). Right? So what exactly is the part you take issue with?

    …they were arguing was that it’s possible, and beneficial, to structure your markup so that you can change the CSS and in so doing effect a significant change in presentation with a lot less work than if you embed the presentation in the markup itself.

    Which is precisely what I’m arguing. So again, we agree. Right?

    Look, the only place we disagree is that I’ve read people say (even in the comment thread right here) that they redesign sites without changing the markup. For example, from this very page:

    Since I’ve started doing it “the proper way,” I’ve never once not changed the mark-up either when I’ve redesigned

    I’ve been in … situations where doing a redesign required nothing be changed to the (X)HTML

    Just for the record, whenever I add a new skin to my site I don’t change the markup; I just create new style sheets.

    This past spring, the website underwent another redesign… and here’s the thing: instead of 7 of us working on the website redesign there were only 2 of us and we didn’t touch the (X)HTML. Changes were made to the stylesheets and everything just worked!

    Certainly people believe this is no only possible, but that it is what uing Web Standards is all about. You say people don’t believe that. Fine, apparently you skipped those comments in this thread. No big deal. Other than that, we agree completely. Right? So really, what’s the point in arguing?

  99. 099 // Jeff Croft // 08.28.2007 // 11:09 AM

    JD, you got my point exactly. Thanks so much for managing to say it more elegantly and sucinttly than I could.

  100. 100 // David Gould // 08.29.2007 // 2:50 AM

    I think that the major problem with the web is customers’ perception as to what their web site should look like. There is this perception that web sites must always look the same amongst web browsers, but this is totally impractical.

    From another perspective, Graphic Designers largely trained in the print industry, prefer to specify visuals based on per-pixel bases. Again this is impractical and simply doesn’t work reliably. It also goes against the grain - do all web site designers who develop sites that are less than 800px wide realise how silly they look on a 1680x1050 screen?

    In time, interpretation of XHTML and CSS will improve. Web Technology is only now starting to mature. With wide screens becoming the dominant technology, and mobile telephones becoming increasingly popular, more forgiving web site designs are critical.

    If you don’t get this, you will be left behind.

  101. 101 // Jeff Croft // 08.29.2007 // 3:01 AM

    With wide screens becoming the dominant technology, and mobile telephones becoming increasingly popular, more forgiving web site designs are critical.

    This isn’t directly related to the topic at hand, but I’ll respond anyway.

    I generally agree with you that changes in technology (such as mobile devices becoming more popular) mean there are new problems we face , but I would say this: “more forging web site designs” are not the only way to solve said problem. Another way, for example, is to create multiple contextual versions of your site. And there are yet other ways to address it, as well.

    A designer’s job, by very definition, is to solve problems. A good designer knows that there are always many ways to skin a cat. The trick is figuring out which one is the right way for the particular cat you’re working with at any given moment. Be careful about the “one solution fits all” thing — because it doesn’t.

  102. 102 // simon // 10.03.2007 // 10:53 AM

    I really like blueprint and like so many people took me a while to get use to the non meaningful markup, but now I have started to use it, well I quite like it, so quick and easy to use, mind you I have had to extend it to breath some life into it but thats our job, right?

  103. 103 // Karl Voelker // 10.27.2007 // 4:57 PM

    You’re right, but there’s a simple solution that preserves the separation between content and presentation: let HTML reside in the presentation layer, provide the content layer in XML, and connect the two with XSLT.

    What we have in XSLT is a standard powerful enough that your content layer shouldn’t have to change, in order to change your presentation.

  104. 104 // Brian Lalonde // 10.27.2007 // 7:51 PM
    1. It muddies the whole idea, though. An “orange” CSS class is every bit as stupid as an HTML tag would be. When you update the CSS, how can anyone tell what the hell .orange is used for? What effect will changing it have? A class like .companyname makes it easy to tell what will be changed when you change a style.

    2. That’s just retarded.

  105. 105 // jarek // 10.29.2007 // 12:41 PM

    There should be an intermediate layer between blueprint and html - something like a glue between semantic and visual way.

    e.g.

    Xcss: ;)

    .product { include: span-4, blueprint_x_x_x background-color: blue; }

  106. 106 // Stevie D // 11.12.2007 // 7:04 AM

    We were never, ever going to redesign our sites without changing the (X)HTML. It’s a nice thought, but it’s also a total pipe dream.

    I disagree.

    If we look at sites written a few years ago, that are now coming up for a redesign, we wouldn’t expect to see them meeting modern standards for accessibility or semantics. So yes, we do want to rewrite the backend code, to get rid of the Javascript rollovers and the layout tables and all the rest of it - great!

    We’re now approaching the stage where HTML is a mature and stable language. The development of HTML5 should complete this process - because of the increasing lag between code development and browser take-up on people’s computers, I don’t see any further major developments being likely, not for a long time. Even so, it could be a long time before HTML5 catches on, depending on how quickly browsers start to support it.

    Pages written in a stable and mature language shouldn’t need to be changed. So when a site does start to look dated - or when an organisation has a makeover and wants the website to follow suit - all that should need to be changed is the CSS.

  107. 107 // Stevie D // 11.12.2007 // 7:28 AM

    All of the redesigns I’ve done in the past few years for my own personal purposes required changing the HTML templates because the needs of the design. One site needed to have advertising on it, which required restructuring the navigation elements to allow room. I wouldn’t have been able to do what was necessary if I limited myself to only touching the CSS file.

    Following on from my previous post - I would not count this as “changing” the HTML. Adding to it, yes, but not significantly changing it. If the majority of the page remains unchanged, it’s more like a tweak than a change - the sort of thing you would have to do if you wanted to add another section onto the page. That is quite different from the redesign situation where you start with a blank screen in front of you.

  108. 108 // Jeff Croft // 11.12.2007 // 12:20 PM

    Pages written in a stable and mature language shouldn’t need to be changed. So when a site does start to look dated - or when an organisation has a makeover and wants the website to follow suit - all that should need to be changed is the CSS.

    I agree that (X)HTML shouldn’t need to be changed — but like I said, it’s a pipedream. It’s a beautiful theory, and that’s why it’s been touted for so long. But in the real world of web development today, it just doesn’t work that way. In the real world of web development five years from now, with HTML5 and CSS3, it probably will. I look forward to that. Until then, I’m not going to get too concerned with I have to changed the HTML along with my CSS for a redesign.

  109. 109 // Andreas // 11.21.2007 // 5:20 AM

    I think it depends on your design-approach. I develop my module-markup without a single thought about design and later when I draw the design I design it around whatever markup I have. If you design this way I believe it is definitely possible to do complete redesigns without changing the markup (csszengarden?).

    If you spend time thinking about the best way to mark up each module and keep them extremely clean (a div with an id around it and inside only semantic, class-and-id-free elements) then the only thing you would need to change is the actual grid, if you have to.

    You can create a range of different grids using only #content and #sub-content containers but not all so they would have to change if the design went from 2 to 3 columns for example, but with the new css3 advanced layout module we won’t even need grid-elements but all “gridding” will be taken care of from the CSS and all you need in your body-element is a bunch of module-divs.

    So, I don’t think we’re far from complete separation and if we could agree on the same ids for common modules (header, footer, navigation etc) we could swap styles with each other all over the place :)

    Of course, I’ve never done a redesign at work myself that did not require changes to the HTML. On my personal site, however, I never change it.

  110. 110 // Dmitry Yeskin // 01.23.2008 // 4:06 AM

    Hello!

    Yes, I agree. We started use a xhtml a long time ago and found that really it doesn’t make a life easier for us and our customers.

    Currently we are trying to not fight with w3 validator to have all 100% compatible and we just decided to use a useful and user-friendly cms drupal that work with xhtml 50/50. So we get a benefits from it and also don’t have a headache with strict markup.

    ;-)

  111. 111 // Michael // 03.21.2008 // 8:08 PM

    This post and the largely positive responses are proof that among the already converted a simple declaration without ANY evidence is ‘well put’, ‘well said’ and ‘spot on’ particularly if the sentiment paints an expert gloss on a very low bar.

    Let us pass lightly over the wisdom of taking anyone who writes in light brown on dark brown seriously on any topic remotely related to best practices and allow me sing to my own chorus:

    It is possible to redesign websites without touching the markup if the information architecture has not changed and this is what the best web developers do. Zen Garden does in fact make the case. Period. End of story. Capiche?

    Now wasn’t that convincing? Didn’t think so. But I feel very satisfied with myself.

    I’ve looked at blueprint, and gosh all that out of the box perfection is very tempting and attractive, particularly to those of us who have spent hours doing with divs and spans what we used to do in minutes using tables. But there’s the rub. See, I am kind of hardpressed to mark any significant difference between all those ginned-up blueprint spans and all the table-based layouts we have spent hours and dollars scrupulously avoiding. If your divs and span aren’t semantic, even in basic ways like what they are named, why not just put in a reset.css and do the rest in tables?

    There is this idiotic religion going on that goes, so long as you do whatever klugey thing you are doing with spans and divs and not cells, even if you give things needlessly self-obsoleting names like column, row, left-sidebar, right-sidebar, pink-background, you are somehow doing better layouts than the ones we used to make in the days of N4.7

    There is also the problem of all those pixels. How nice that you prefer them, but how unfortunate is that preference for any of your visually impaired IE users. If you work, as I do, for an enterprise that has a very strict accessibility mandate, you just plain can’t use them.

    I have a coworker who ridicules the whole idea of standards, is averse to any kind of group agreement on best practices and like the person posting here is quite unappealingly sure of himself. He also equates declarations with reasoned argument. Managers are fond of him because he is as quick as he is shameless in cutting and pasting his way to short deadlines. I am quite sure he has cost my group thousands of dollars not simply because he reproduces one impossible-to-maintain site after another but also because he belittles anyone who aims higher. I am reminded of him here.

  112. 112 // Jeff Croft // 03.22.2008 // 2:18 AM

    If your divs and span aren’t semantic, even in basic ways like what they are named, why not just put in a reset.css and do the rest in tables?

    Simple: because tables are semantic, whereas divs aren’t. Using a table in your markup says, “this is a table, it contains tablular data.” Using divs says no such thing.

    Divs were created precisely to be non-semantic grouping elements that mean nothing. Tables have an inherent meaning, and it’s inappropriate to use them in a place where that meaning doesn’t apply.

    Capiche?

  113. 113 // Jack // 03.30.2008 // 7:43 PM

    IMO, standards are important within the scope of a project to help development and future maintenance. However, standards change every year or more often at least it seems.

    What we learn is that its very difficult to avoid changing the (X)HTML if the presentation wasn’t anticipated in the design phase. For example, we learn that DIV nesting is important to present certain layouts. While alone DIVs have no meaning, oops all of a sudden there relationship with other divs does…

  114. 114 // Andy // 06.14.2008 // 2:30 PM

    Presentation and content are two different things. Period.

  115. 115 // Mike // 08.12.2008 // 7:40 AM

    I agree with”Andy” - don’t get two notions mixed up.

  116. 116 // Chris // 08.29.2008 // 9:03 AM

    This is a fantastic discussion, probably the longest amount of time spent on one blog article for me at least.

    I tend to agree with Jeff, with a healthy dose of caution at all times. On one hand it could be classed as the slippery slope but on the other until a better solution is available, then Blueprint it is.

    Purism doesn’t pay my bills and allow me to meet deadlines, and I’d be interested to hear the contrary.

  117. 117 // Henrietta Hopper // 11.12.2008 // 1:43 PM

    rwl7ig2jpx0mamfd

  118. 118 // Jamie - Familienrecht Rechtsanwalt Stuttgart // 01.13.2009 // 5:59 AM

    yeah Cris! this is really a fantastic discussion!!! and it’s no real to read from up and till the same down all these pros and cons with detailed arguments! may be it’s useless, but still interesting and capturing!

  119. 119 // John - Classifieds // 01.20.2009 // 1:31 AM

    hi! i’m not interested in CSS or other things like this and can’t comment on the contest of the article. but my brother has birthday soon and he’s keen on different things like the ones you are writing about, so i decided to make a collection of useful links for him. so you are going to be number one in the list)))

  120. 120 // Christian Romney // 08.14.2009 // 9:39 AM

    Now you can have your cake and eat it too. The Compass CSS framework lets you make any element a blueprint column without having to pollute your html with presentational class names. Even though it’s a Ruby tool, you can use it with any technology. http://compass-style.org/

  121. 121 // UB // 09.06.2009 // 5:10 AM

    One should point out-What is seen as “best practise” isn’t always the best development for a project either.

  122. 122 // GodsArse // 12.14.2009 // 2:07 AM

    Good discussion. I’ve been making websites for over 20years, yes 20!! And i’ve gone with the flow all this time. However, i still think that seperation of style & content is now pointless. Redesigning one and not the other rarely happens, so why not make life easier. Also, users getting content and then style (like dialup users) alsways complain the text keeps jumping around as style arrives. Its an out-of-date idea. We always need new technologies, so lets stop with stupid old-fashioned ones. Give it a try: build a website where style and content go hand in hand (you’ll obviously have to ignore all the validation stuff). You’ll be surprised. Small, compact, easily changable, amazing looking websites - that work in ALL browsers. ha.

  123. 123 // ppjm // 02.05.2010 // 4:30 AM

    Interesting comments to read - actually more revealing than the original blog item imho.

    One thing though, where did you get this colour scheme from???? White text on dark, with some dark shait on even darker shait. Very designery, very wrong. Had to switch of css to read the damn thing.

Tags for this entry