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.
Where Web Standards and other best practices don’t provide great benefits, find solutions that do.
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:
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.
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 :)
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.
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.
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!
005 // Jeff Croft // 08.10.2007 // 1:38 AM
It’s great if you’re in a hurry. :)
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 http://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.
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.
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.
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?
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!
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.
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.
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.
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.
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.
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
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.
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”.
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.
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.
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?
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.
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! :)
022 // Matt Howell // 08.10.2007 // 11:07 AM
The only way you can keep HTML and CSS completely separate through redesigns is if:
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.
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.
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.«
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.
026 // Jeff Croft // 08.10.2007 // 1:58 PM
Hah. Touche! But, I would totally agree.
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.
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).
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.
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?
027 // c.s. // 08.10.2007 // 2:39 PM
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.
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?
029 // Jeff Croft // 08.10.2007 // 3:53 PM
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.
I would say that adequately describes what I’ve been doing for some time, too.
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!
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”?
032 // Jeff Croft // 08.10.2007 // 5 PM
“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.
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).
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.
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 http://Digg.com were especially outraged at this, although that might not be the best place for constructive criticism.
034 // Jeff Croft // 08.10.2007 // 6:36 PM
The people at http://Digg.com would be outraged at the sun coming out after 10 straight cloudy days.
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?
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.
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
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.
039 // Jeff Croft // 08.11.2007 // 2:18 PM
:) 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-xis a stretch, but I don't think there was anything more semantic we could have used, instead.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.
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.
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.
040 // Jeff Croft // 08.11.2007 // 2:19 PM
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.
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.
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.
041 // Jeff Croft // 08.11.2007 // 2:19 PM
Nothing at all. You should, and we did! :)
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.
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].
043 // Jeff Croft // 08.11.2007 // 2:55 PM
No, it’s not like that. I think you might misunderstand what
span-4means.span-4means that a column spans four grid units. It isn't meaningless at all (like$string1is). 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.
I definitely disgree with that. The beauty of Blueprint is massive class reuse.
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.”
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.
045 // Jeff Croft // 08.11.2007 // 7:15 PM
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.
:)
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.
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.
048 // Greg // 08.12.2007 // 8:53 PM
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 <a href=”http://version%5D%28http://www.globeandmail.com” rel=”nofollow”>http://version.
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.
050 // Ludwig Wendzich // 08.12.2007 // 11:26 PM
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.
051 // Jeff Croft // 08.12.2007 // 11:59 PM
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. :)
Indeed. Good point.
052 // Ludwig Wendzich // 08.13.2007 // 12:42 AM
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 :)
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.
054 // Jeff Croft // 08.13.2007 // 3:56 PM
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.
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.
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).
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.
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…
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.
056 // Jesse // 08.13.2007 // 5:16 PM
Regarding presentation vs. content…
That’s because we’re redesigning crappy, old websites which didn’t follow the standards in the first place :).
057 // Jeff Croft // 08.13.2007 // 5:46 PM
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.
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.
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.
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. :)
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.
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.
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.
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.
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.
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…
063 // Jeff Croft // 08.13.2007 // 11:56 PM
Too bad I’m not working on 15 redesign projects right now, huh?
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.
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.
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?
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.
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?
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. :)
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.
069 // Fredrik // 08.15.2007 // 1:07 PM
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.
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.
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? :)
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.
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.)
074 // Anton // 08.16.2007 // 12:57 PM
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.
075 // Jeff Croft // 08.16.2007 // 1:07 PM
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. :)
Sure, but Blueprint doesn’t supecede that at all.
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.
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.
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
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.
079 // Jeff Croft // 08.20.2007 // 1:05 PM
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.
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.
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.
082 // Jeff Croft // 08.20.2007 // 4:14 PM
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.
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.
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.
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.
084 // Jeff Croft // 08.20.2007 // 4:43 PM
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.
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.
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 . . .
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.
087 // Russell Heimlich // 08.27.2007 // 3:38 PM
Redesigns? Isn’t the idea to graduall