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.29.2007 // 12:31 AM // 78 Comments

On standards, Web Standards, and “standardistas”

A couple weeks ago, I posted an entry with the (admittedly sensationalist) title The myth of content and presentation separation. The point of the post was this: Come redesign time, anything other than very minor changes will almost always require changing the markup as well as the CSS. Therefore, fretting over things like the non-semantic class names the Blueprint framework uses is, well, silly at best.

However, I also said 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.

I said this, and I absolutely meant it (even if it wasn’t the main point of the article).

In hindsight, it was probably a bad idea to leave this tidbit out there without further clarification. Some people seem to have taken it as an attack on Web Standards. So, I’d like to revisit that comment and clarify what I really meant.

Before we get started, let’s define a few terms, here. First, let’s talk about standards (lowercase). Google shows several definitions of the word, but the one I think best applies here is this:

Agreed principles of protocol. Standards are set by committees working under various trade and international organizations.

Now, what about Web Standards (which I’ll type in uppercase, as a proper noun)? According to Wikipedia:

Web Standards is a general term for the formal standards and other technical specifications that define and describe aspects of the World Wide Web. In recent years, the term has been more frequently associated with the trend of endorsing a set of standardized best practices for building web sites, and a philosophy of web design and development that includes those methods.

That’s a great definition, because it includes the idea of “best practices.” This is important. Web Standards, as a movement, cares about things like not using tables for layout and not using obtrusive JavaScript, even though these things are perfectly acceptable, as far as the technical specs are concerned. Likewise, Web Standards often encompasses things like Microformats, which are best practices (and technical specs) that haven’t been ratified by any “official” body (like the W3C).

With that out of the way, I’ll say this emphatically: I don’t care about standards. Not at all. Not even a little bit. People that know me have worked with me will describe me as practical moreso than pedantic. As such, “standards” will never appear on my priority list. When I’m working on a project, my priorities look something like this:

  1. Create solutions that solve the client’s stated problems.
  2. Find ways to achieve the client’s stated goals.
  3. Find ways to solve problems the client doesn’t even know they have.
  4. Use tools that are elegant and efficient, and help me produce quality work within the client’s budget and timeframe.

Really, that’s about it. Notably missing from the list is: Use Web Standards (including established best practices).

However, I use Web Standards a lot. 95% of the time, or more. Why? Because, most of the time, they fit right into my fourth stated priority. Using Web Standards is usually the most elegant, fastest, cheapest, and highest quality way to produce a web site. So while I don’t care about standards (those agreed principles of protocol decided by some committee), I do care very much about Web Standards (the tools that help me accomplish my priorities).

But there are times when Web Standards just don’t make sense. There are times when Flash makes sense. There are times when Java applets make sense. There are times when proprietary HTML, CSS, and JavaScript, written for exactly one browser rending engine makes sense (yes, really!). There are times when non-semantic class names make sense. There are times when creating a site just for one device makes sense. There are times when a desktop app makes sense, instead of a web app. Hell, there are even times when it makes sense to tell the client to spend their money on direct mail and forget about the Web all together.

And even more to the point, there are times when it makes sense to generally use Web Standards, but in a looser sense in which you may not be overly concerned about a few unencoded ampersands or a few non-semantic class names.

If you are so caught up in doing what’s “right” — meaning what you read in Designing With Web Standards, or on ALA, or on webdesign-l, or even at JeffCroft.com — that you ignore the sorts of priorities I’ve listed, then you are doing your clients a grave disservice.

My point, when I said what I did a couple weeks ago, was that you should evaluate all available tools — including Web Standards — and select the one(s) that are appropriate based on factors like the client’s needs, the project’s budget, and your level of expertise, rather than selecting them based on what some mysterious group of non-web designers say is “right”. If you’re like me, your analysis will jive perfectly with the righteous ravings of your local standardista much of the time. When it doesn’t, remind that standardista that you are the only one who can adequately make these decisions, since you are the one dealing with the client.

Most of these standardistas who insist on being 100% semantically pure every time and never having even a single iota of JavaScript inline and encoding every single ampersand at all costs are, quite frankly, living in an academic fantasy world. They don’t have clients. They don’t do real work. Rather, they sit at their computers all day and night tinkering with their personal website until it’s perfect enough that they feel comfortable attacking people who only got 95% of the way there.

And you know what? That’s fine. More power to them. If that’s the world they live in, so be it (I’m not sure how they make any money, but I guess that’s not my business). But keep in mind: their list of priorities would look very different from mine. In the world I live in, there are clients, budgets, deadlines, resource limitations, and bosses to answer to. My list of priorities reflects that.

And that’s why I said: Use Web Standards because of the great benefits you get from them, not because Jeffrey Zeldman told you to. Web Standards are a means to an end, not the end itself. In other words, if you’re a working web designer, put serving your client’s needs ahead of impressing your pedantic standardista friends.

Comments

  1. 001 // Nik Steffen // 08.29.2007 // 2:24 AM

    Very well written as always Jeff. I agree fully with you, and I am pretty sure I am not the only one. For some reason there seems to be a notion amongst some web developers that not sticking to an exact guideline as set out by Web Standards, you are automatically rendering your site unusable by mobile devices, people with dissabilities and other alternative methods and users of the web.

    To be honest, the separation of content, presentation and behaviour as advocated by many fails even if you stick to Web Standards? Ever considered that the :hover, :active and other CSS controlls are behaviours?

  2. 002 // Kevin // 08.29.2007 // 2:28 AM

    There are times when non-semantic class names make sense. Yes, but later when you change .redText to blue, they no longer make sense. So while I get your point, there are some limits to which “best practices” you can leave out and still serve clients into the future.

  3. 003 // Gabe da Silveira // 08.29.2007 // 2:37 AM

    If you are so caught up in doing what’s “right” — meaning what you read in Designing With Web Standards, or on ALA, or on webdesign-l, or even at JeffCroft.com — that you ignore the sorts of priorities I’ve listed, then you are doing your clients a grave disservice.

    Very well said Jeff. As a web generalist, I have a vast array of best practices to strive for. The fact is that priorities must be set, and the ability to prioritize according to business need is the single most important factor in doing quality work. Web standards have been an amazing boon to efficient web developers and designers, but not as a religion—they solved huge problems that we collided with head-first in the 90s. The only justification standards need is a look at how we did things 10 years ago.

    Most of these standardistas who insist on being 100% semantically pure every time and never having even a single iota of JavaScript inline and encoding every single ampersand at all costs are, quite frankly, living in an academic fantasy world. They don’t have clients. They don’t do real work. Rather, they sit at their computers all day and night tinkering with their personal website until it’s perfect enough that they feel comfortable attacking people who only got 95% of the way there.

    Ouch! Way to give a harsh reality check. This level of pedantry is totally arbitrary. The kind of people who do this rarely have done deep reasoning why they chose this particular detail to obsess over. Often it serves as an easy way to dismiss other people’s work. People who probably are paying attention to dozens of other details below the standardista’s radar.

    Actually this seems to be common in all kinds of technical work. Just look at the holy wars that rage around programming languages. A lot of people will carefully construct a specific programming worldview as a defense mechanism against the possibility that somebody else may have a better way of doing things. The reality is that a lot of these decisions end up being pretty arbitrary—you can’t always be right, and you can never know anything. To accept that, and strive to simply do the best you can to meet actual business goals is the healthiest and most effective way to operate.

  4. 004 // Joshua // 08.29.2007 // 2:38 AM

    Very well written and I agree wholeheartedly. Sorry for the lame ass comment, but there’s not much to say, you pretty much summed it up! ;)

  5. 005 // Jeff Croft // 08.29.2007 // 2:49 AM

    Yes, but later when you change .redText to blue, they no longer make sense.

    That would not the the instance in which I was referring to. I would agree, that type of class name is a bad idea, pretty much always. The specific instance I was referring to was the use of the Blueprint framework, which offers extreme speed and layout flexbility at the expense of 100% pure semantics. If you don’t believe there is a time for this tradeoff, then I would say you’ve never been on a journalist’s deadlines.

    So while I get your point, there are some limits to which “best practices” you can leave out and still serve clients into the future.

    You’ve also made the assumption that “the future” matters. It doesn’t, always. Many of the special features we put up at the newspapers sites I worked on will literally never be touched again. They ran once, and that was it. That was their job.

    So my point remains: there is a time and palce for these thigns. There are times when the speed and flexiblity offered by something like Blueprint is more valuable than high levels of flexibility going into the future. An example of that time is when the deadline is very short and the page will never be touched again after it’s published.

    Actually this seems to be common in all kinds of technical work

    It also seems to be common amongst people who perfer online discussion to face-to-face conversation. I find that these people are much more likely to act like assholes than those who have to respect the face that I might physically reach out and punch them in the nuts. :)

  6. 006 // Kev Mears // 08.29.2007 // 7:42 AM

    Very nice article Jeff. I totally agree with the pragmatic approach you take. I come from a University perspective, where I work on a team looking after our sites, and sometimes university wide initiatives to get ‘Web Standards’ are mooted. These are often more about claiming some bogus notion of compliance than a more rounded view of the function of a site.

  7. 007 // Dimitri Glazkov // 08.29.2007 // 8 AM

    Duude, you just left a bunch of your readers (including myself) wondering if you called them names.

    Overall, you’re right. Specific problems require specific solutions. Web standards are a means, not the purpose.

    Where I would offer a discourse (gently, ‘cuz I don’t want to be one of them standardistas who apparently live with their mothers and eat kittens for breakfast), is keeping the big idea in mind. For me, the big idea is that 100% semantic markup is possible, and every project that I do, every bit of code that write, however imperfect it might be, I use to glean more insight toward making this idea a reality. For me, this duality of today vs. tomorrow is inescapable and haunting. If you are able to disconnect them, you’re one lucky fella. But I ‘spect you ain’t.

  8. 008 // Brent O'Connor // 08.29.2007 // 8:40 AM

    Amen Brother! I couldn’t agree more!

  9. 009 // Kilian Valkhof // 08.29.2007 // 9:25 AM

    While I agree there is a line to cross where web standards stop making sense and other technique’s do, I think you are giving the impression that that line will be stumbled upon way too soon.

    Real life web developers won’t frown upon the use of Flash or obtrusive javascript when it makes sense. (for example, is there sense in making a google maps mash-up with unobtrusive javascript?)

    For the most you are preaching to the choir. of course Flash is to be used for video’s and other interactive thingamajingy’s. But seeing how 95% of the web is text anyway, why not incorporate as much best practice as possible, on the fly when creating a site. You seem to do that, but you give the impression that you value time more than clean code in a way that you’d rather type “h” than “header” as a class name.

    In academic circles, academic logic prevails. In business circles, business logic prevails. It’s as simple as that.

  10. 010 // Megan // 08.29.2007 // 9:46 AM

    I agree with most of what you’ve said here. I’ve written a few times about the over-emphasis some web designers place on standards and/or validation. There’s lots of writing and discussion about standards, which is good. For a long time we really needed that.

    But there are so many other things we should be worrying about and often aren’t. It doesn’t do much good if a site is perfectly “standards compliant” but doesn’t solve the client’s business problems. I think many of us spend way too much time thinking about semantics and making sure everything validates and not enough time communicating, marketing, and solving problems.

  11. 011 // Eric Puidokas // 08.29.2007 // 9:54 AM

    One thing I would have like to see in your priority list is something about creating long term solutions.

    While things outside of the technical specs (like non-semantic class names) won’t break in future browser versions, unencoded ampersands could. Just because it works fine in today’s browsers, doesn’t mean it will work correctly in future browser releases.

    Sure, the unencoded ampersand is a weak example as it seems unlikely to cause problems in the future, but I do feel that following the technical specs for the reason of forward compatibility deserves some mention.

  12. 012 // Derek Kinsman // 08.29.2007 // 10:11 AM

    The perfect follow up. I agree whole heartedly. I fear that you may have angered the giants (W3, WCAG, ALA evangelists [they’re the ones that think that what’s written is 100% absolute] ), so to you I suggest you sleep light ;)

  13. 013 // Jeff Croft // 08.29.2007 // 10:11 AM

    is keeping the big idea in mind. For me, the big idea is that 100% semantic markup is possible…

    For me, that is definitely not the big idea. My big idea is to using this incredible global network we’ve built to share ideas, communicate, and establish relationships never before possible.

  14. 014 // Jeff Croft // 08.29.2007 // 10:17 AM

    One thing I would have like to see in your priority list is something about creating long term solutions.

    That is in my priority list. If a client needs a long term solution, then it becomes part of the goals and problems we are trying to reach and solve in order to serve them.

    Bear in mind, tough, that not every client does need a long term solution. Sometimes projects really do only need to work in today’s browsers, and it really doesn’t matter if they work in future ones or not. Not often, but sometimes.

    You really can’t set the same goals or priorities for every project, which is why the priorities I listed here are very generic and abstract. One size never fits all.

  15. 015 // David Mihm // 08.29.2007 // 10:20 AM

    Jeff, great piece here. Client goals & budget are always the most important things for me to consider when I’m working on a project as well. If I can do a one-browser hack in 5 minutes where it’d take me 5 hours to figure out a Web Standards-compliant fix to the problem, I’m always going to go for the hack.

  16. 016 // Jeff Croft // 08.29.2007 // 10:36 AM

    If I can do a one-browser hack in 5 minutes where it’d take me 5 hours to figure out a Web Standards-compliant fix to the problem, I’m always going to go for the hack.

    Well, I wouldn’t go that far. I always strive to produce quality work, and I’ll always do my best with the resources I’m given. I wouldn’t choose a five-minute-one-browser hack over a real solution to the problem unless the deadline for the project was in five minutes and that one-browser hack would truly meet the clients needs. Most project do need to work well across multiple browsers. There are a few that don’t (for example, if I was commisioned to work on the HTML/CSS/JavaScript in the iTunes store, I wouldn’t spend a lot of time worrying about how it looks in IE or Gecko, since people will only ever see it in WebKit) — but most do.

    Don’t use client requirements like timeframe and budget as an excuse to not to quality work. I’m not suggesting that. What I am suggesting is that “quality work” is a continuum wth tradeoffs — and in some cases, delviering 90% quality on time and under budget may be more important than delivering 100% quality if doing so means you’re over budget and past deadline.

  17. 017 // Dimitri Glazkov // 08.29.2007 // 11:24 AM

    For me, that is definitely not the big idea. My big idea is to using this incredible global network we’ve built to share ideas, communicate, and establish relationships never before possible.

    Yes! You’re right, of course. I didn’t think this through. There are many big ideas, intersecting and containing each other. I see one (semantic markup) as part of the other.

  18. 018 // Ben // 08.29.2007 // 11:46 AM

    Jeff, I’ve enjoyed your past few articles discussing the subject of “sensible” and “practical” implementation of Web Standards. Have you read this article about “semi-professionals?” You may find it interesting.

  19. 019 // Joe Clark // 08.29.2007 // 2 PM

    Getting 95% of the way toward Web standards (defined by the easy proxy of valid HTML and CSS) puts such a developer in the top 0.5% of all developers. Being off by an ampersand or two isn’t the end of the world, but if it can be corrected easily, it should be.

    So I don’t know whom you’re accusing of ivory-towerism, if I might use a neologism.

  20. 020 // Jeff Croft // 08.29.2007 // 2:19 PM

    Certainly not you, Joe! Well-said.

  21. 021 // Michelle // 08.29.2007 // 2:34 PM

    Wonderfully written! My favorite line:

    Rather, they sit at their computers all day and night tinkering with their personal website until it’s perfect enough that they feel comfortable attacking people who only got 95% of the way there.

    While I am all for web standards, I also need to make a living. I’ve labored over “perfect” sites before and then had nothing but problems when the client upgraded a browser or had a colleague look at it through an older browser. The reality is that we cannot tell our clients to use a certain browser or ditch outdated browsers. With hundreds of clients, I cannot be a slave to a validator just so I can put a small button at the bottom of a page. Strive for perfection, but settle for getting the job done and on time.

  22. 022 // Arik Jones // 08.29.2007 // 3:09 PM

    Standardism is a killer of productivity and met dead-lines. Its becoming more of an epidemic and less of a tool. Its sad really.

  23. 023 // Matt Robin // 08.29.2007 // 8:17 PM

    22 comments already!

    Okay, here’s my comment (no one will read this low in the comment thread will they?!)…

    This is an excellent elaboration of the points you’ve been stating over the past weeks.

    This one line sums it up best for me:

    Web Standards are a means to an end, not the end itself.”

    Oh, this is so true! ;)

    In fact, I’ll also say I don’t even like the word ‘standardistas’ all that much anymore - it is getting a negative association for an unrealistic Web Standards Elite…which is just ugly, bad for Web Standards, and bad for the Web.
    I appreciate some people’s passion, commitment and enthusiasm for encouraging the use of Web Standards (a good example is: Molly) ….but there are other people who are just code-perfect ‘Standardistas’, the Elitists - and I hate them because they are almost entirely pointless!

    Your comments, and the article itself, clearly highlight that Web Standards is just one set of techniques available to us…a tool for the trade of actually doing web design professionally….the job is what matters - (it is what pays your bills right?!)…not whether every single line of your code is semantically perfect and able to work on every browser application ever made!

    Like you Jeff, I use Web Standards because it helps me do web-related tasks (call it Web Design or Web Development - I’m not opening up that wound! Hahaha) much better than I could in the dark, old days before using Web Standards best practices at all. Sure, you might see me commenting on this site, Molly’s site, ALA, Zeldman’s place, and a whole bunch of others too…but I’m not using Web Standards just because some people say we should…I use it because it works much better for my objectives…generally.

    For me, that is definitely not the big idea. My big idea is to using this incredible global network we’ve built to share ideas, communicate, and establish relationships never before possible.”

    Same, same, same!! (Nice to know I’m not the only one who thinks along those lines!)

    I feel sort of sorry for anyone who misunderstands the points you’ve made in this article.

    • You are not Anti-Web Standards
    • You are a realistic Web-Professional who acknowledges that Web Standards can not always be fully used in all real-world terms
    • It is about getting the job done right for the client….and Web Standards is great if you can include it too.
    • Web Standards Elitists are not the final word on everything to do with how Web Standards should be used in the Web Industry.
  24. 024 // Stephen Hay // 08.30.2007 // 2:09 AM

    Joe’s right: although some may not like to admit it (imagine the drop in speaking engagements), valid code gets you 95% there. I’d be happy if more than 1 out of 20 websites I visit could even achieve that.

    Jeff, you’re a designer in a world where programmers consider themselves designers. And for programmers, arguments about who writes better code are as normal as your morning coffee, though admittedly less pleasant. Take it with a grain of salt.

  25. 025 // Albert // 08.30.2007 // 7:11 AM

    ..Moreover, even die-hard standards purists might not always be able to entirely separate structure from presentation—at least not in XHTML 1. But that separation of structure from presentation (of data from design) is an ideal toward which we can make great strides and from which even hybrid, transitional layouts can benefit…

    Zeldman dixit (Source: DWWS, p.171).

  26. 026 // Jeff Croft // 08.30.2007 // 8:03 AM

    Thanks for that, Albert. I don’t see that in my copy of *Designing With Web Standards,” so I presume it must have been added for the second edition. Glad to know Zeldman is on the page as I am. :)

  27. 027 // Christian // 08.30.2007 // 12:12 PM

    I work on a bunch of sites and on some I think, “This is a site that I think I can code 100% to web standards,” and I have achieved it very easily and on some I get very, very close. On others I just bang the whole thing out and they, just through fate or whatever, are 90 - 95% of the way there.

    The thing is, if your knowledge of web standards is good then all your coding should follow it strictly (and almost entirely without effort) from the very beginning. No developer (coder, programmer … whatever) should have to say, “I just code my sites however then go back through and clean up the code and make it perfect and then I put the button on my page.” If you do that you are making unnecessary work for yourself. And if you are doing it the chance is there that you don’t have a good enough grasp on good coding practices to begin with. The only time a deviation would need to occur is if you came to a spot in a page where you knew one browser would handle a particular element better than others and you say, “Okay, that is the browser I’ll code for in this spot and I don’t care if it validates or not,” and if there really is no other way around it then go ahead and do it.

    And if you really knew how to code your HTML well you would realize that standards-compliant pages aren’t only viewable on cutting-edge browsers. It cracks me up when people say, “Yeah, we have to use FONT tags for this project because not all our viewers have IE7 or higher.”

  28. 028 // Joe Clark // 08.30.2007 // 7:18 PM

    Michelle, your development will go faster if, at important intermediate stages, you make sure you have valid HTML and CSS. Suddenly things will start to work in old or unforeseen browsers.

    Now, what happens to your site after you hand it off to your client is an intractable problem.

  29. 029 // Jeff Croft // 08.30.2007 // 7:30 PM

    Michelle, your development will go faster if, at important intermediate stages, you make sure you have valid HTML and CSS.

    I find this to be true, as well. Whenever some CSS isn’t working the way I expect it to, the first thing I do is validate my HTML. I almost always have made a silly mistake, like forgetting to close an element. Most of the time, validation points out the error to me, and it’s usually a simple fix.

    But there again — the validator (and valid code, in general), is simply a tool to help me get my job done in the most effective and efficient way possible. Achieving valid code is never my end goal — but it helps me get there.

  30. 030 // Christian // 08.30.2007 // 8:08 PM

    But there again — the validator (and valid code, in general), is simply a tool to help me get my job done in the most effective and efficient way possible. Achieving valid code is never my end goal — but it helps me get there.”

    Exactly.

    Moreover, even die-hard standards purists might not always be able to entirely separate structure from presentation—at least not in XHTML 1.”

    I wish I could see an example where somebody simply can’t separate presentation from structure.

  31. 031 // Jeff Croft // 08.30.2007 // 8:35 PM

    I wish I could see an example where somebody simply can’t separate presentation from structure.

    I’ll give you an example, and it’s a very common situation in the agency world. The job is to create a set of four or five layout templates that will be used for all sorts of content. Say it’s for a magazine’s site. You might create a two column layout, a three column layout, a layout that features a large graphic element, and a general “listing” layout that could be used for anything from search results to stories in a section.

    As the designer, you have no idea what the content is that’s going to go into these pages. As such, you don’t know the content’s structure. It’s not part of your job. Your job is to design a system that will work well for lots of different types of content.

    This is exactly the situation that Blueprint was created out of. That’s why the class names are span-4 and not sidebar. Because we have no idea if it’ll be a sidebar or not. All we know is what it looks like, visually.

  32. 032 // Christian // 08.31.2007 // 2:39 AM

    I was kind of hoping for a code sample where a developer felt they had to work presentational cues right into the (X)HTML rather than in a CSS file.

    As the designer, you have no idea what the content is that’s going to go into these pages.

    I kind of see what you’re getting at but I don’t see how that means you can’t have all the presentational cues in a separate CSS file. Or maybe I should state it as: I don’t see how that forces the presentational cues to be in the XHTML.

  33. 033 // Jeff Croft // 08.31.2007 // 10:02 AM

    Or maybe I should state it as: I don’t see how that forces the presentational cues to be in the XHTML.

    If you don’t know what the content is, or how it’s structured, and you only know about the presentation (i.e. what it’s going to look like), then you have* to use visual class names and ids. It’s all you’ve got o go on. What else would you use?

    You can try to make it as generic as possible (with class names or ids like column1 and column2, for example), but if the only thing you know about is the presentation, then your names are undoubtedly going to be presentational in nature.

  34. 034 // Christian // 08.31.2007 // 11:36 AM

    So you’re talking about how classes are named. If you have to name something “span-4” rather than “sidebar” I don’t think that’s so bad.

  35. 035 // Jeff Croft // 08.31.2007 // 11:44 AM

    Is that not what you were talking about? My apologies, if not.

  36. 036 // Elliott // 08.31.2007 // 3:06 PM

    I have followed your articles about this topic with interest from the standpoint of a newer developer/designer and learner of Web Standards.

    I can say that I agree with what you are saying! It’s nice to hear from someone that it’s ok to put an extra div in here or there to get the layout correct without getting cut down in the battle over “bloated content” and non-standards based design. Now, I’m not talking about going over board with divitis, or trashing the code to get a site to look correct or pretty, but I feel that a few extra lines of markup here and there to get something to layout correct is fine.

    Using this method gets away from the table based designs of WYSIWHG markup, doesn’t add much markup to the overall page size and from what I can tell, hasn’t affected usability or accessibility.

    Thanks for the refreshing insights, and now I won’t feel so bad about not reaching full compliance with the standardista’s!

  37. 037 // Christian // 08.31.2007 // 5:21 PM

    That’d be funny to make some buttons that say “This page isn’t Valid XHTML 1.0 Strict But It’s Close Enough and It Still Works!”

  38. 038 // Jeff Croft // 08.31.2007 // 5:28 PM

    Christian: I think that’s pretty much the idea behind the button at the bottom of Mike Davidson’s site. :)

  39. 039 // Grant Blakeman // 09.01.2007 // 1:39 PM

    applause - it needed to be said :-)

  40. 040 // Doug // 09.01.2007 // 8:08 PM
    1. Create solutions that solve the client’s stated problems. 2. Find ways to achieve the client’s stated goals. 3. Find ways to solve problems the client doesn’t even know they have. 4. Use tools that are elegant and efficient, and help me produce quality work within the client’s budget and timeframe.

    So basically you have no agenda or ideals of your own.

  41. 041 // Brian Ford // 09.02.2007 // 2:27 PM

    So basically you have no agenda or ideals of your own.

    What?

    As a professional designer, who is paid by clients, his primary agenda is to earn clients, and that is accomplished by a secondary agenda — serving the clients he has.

    With that said, I can’t tell if you’re being snarky, or not. I’d say he has a pretty commendable set of ideals.

  42. 042 // Jeff Croft // 09.02.2007 // 6:16 PM

    I am also unsure if that was a snarky comment or not, but Im assuming it was…

    I do have agendas and ideals of my own, and I will, at times, attempt to impart them into my client work — but only in the case where I can do that, and fully serve the client’s needs. For example, I care about Django and the Django community, and I have a vested interest in seeing Django succeed. So, I’d like to use Django for client work. But, I would never recommend it if I didn’t believe it was the best choice for the client’s success.

    As a professional designer, I think my first responsibility is to my clients. They come to me (or my company) for solutions, because I/we are experts in that area. They come to me because they want my opinions. I give them to them.

    In the end, my job is to help make my client’s successful. Note that my job is not to give them what they say they want. My job is to figure out what they need in order to reach their goals and solve their problems, and provide that. What they say they want and what my experience says they need are often two very different things.

    I am not a slave to the client. I don’t simply do what the client tells me to do. That’s not design — that’s construction work. But even though I am not their slave, I am their advisor and consultant, and it is my job to serve them well in that capacity.

  43. 043 // Jonathan Christopher // 09.03.2007 // 11:12 AM

    I can’t help but compare this article to the mood I find myself in from time to time. I do have client work, and work on that work every day. While I can definitely see a value in a semantic naming convention, speed is absolutely of the essence at certain points.

    Articles like these, from authors who are very respected in the industry, help me to keep any overzealousness of mine in check. I had recently written an article specifically on the semantic-less nature of CSS frameworks, which was bombarded by both fantastic arguments against it as well as support. Damning CSS frameworks purely for their lack of semantics wasn’t my point. My main concern is the nature of the framework itself. I simply feel that many up-and-coming developers will come upon Blueprint and base every project on it without knowing how it works. My article didn’t come off as such and more-so pointed a finger at the lack of semantics involved. The fact remains that element naming is often tied to a particular design, and is partially unavoidable.

  44. 044 // Jeff Croft // 09.03.2007 // 1:55 PM

    I simply feel that many up-and-coming developers will come upon Blueprint and base every project on it without knowing how it works.

    Jonathan: I think this is a very valid concern, but I also think it’s one you can’t blame Blueprint or its developers for. That’s a bit like saying we shouldn’t allow Ferarris and other supercars, because of the possibility an inexperienced driver will not know how to handle one and wreck.

    This same thing applies to every type of web development framework. Be it Django, Rails, CakePHP, YUI, Prototype, jQuery, or anything else — if you don’t understand how they work, you’re probably going to cause more harm than good by using them. But that doesn’t change the fact that they’re incredible time-savers and (in most cases) great paths to elegant solutions when they’re used properly.

  45. 045 // Doug // 09.04.2007 // 8:53 AM

    So basically you have no agenda or ideals of your own

    I guess my point is that as a web designer/developer you also have a responsibility to yourself and the other members of your profession. Anyone who has worked in the field before standards became “standard” knows how much more of a joy it is to work with semantic html and css. And that their use has improved the quality of information on the web. To say that you “don’t care about standards” is disrespectful to the work that has been done to get the profession to this point.

    You say that you use Web Standards because:

    Using Web Standards is usually the most elegant, fastest, cheapest, and >highest quality way to produce a web site.

    Which implies that if another method came along that was perhaps a bit better in these categories, you would use it, even if it was perhaps harmful in the long run to the web design profession and the quality of the web itself.

    [ And no, I would not include Flash (used appropriately) in that category. If you want to use an alternative display technology, make an argument for how it is complementary to the ideal of standards, rather than dismiss them entirely ]

    My point is that there are reasons to use web standards that go beyond their usefulness in making you and your clients money.

    Standards are not always the absolute “best” way to do something, in any profession. The “best” way to do something is often subjective and debatable (think of the arguments about which is the “best” programming language). However, the benefits of standardization in an open and free medium such as the web often outweighs other shortcomings.

    Having said this, code nazis who demand 100% validation are also missing the big picture. And I think we all wish the speed at which web standards are amended were faster.

    But don’t confuse implementation and creation with the idea (and ideal) of standards (and Web Standards) themselves.

  46. 046 // Jeff Croft // 09.04.2007 // 10:08 AM

    Anyone who has worked in the field before standards became “standard” knows how much more of a joy it is to work with semantic html and css.

    I started working professionaly doing web design in 1996, so I certianly know what you mean.

    To say that you “don’t care about standards” is disrespectful to the work that has been done to get the profession to this point.

    Did you miss the part where I said I do care very much about Web Standards. That was the point I was making: “standards” are just policy and proceedure. Web Standards are useful tools.

    Which implies that if another method came along that was perhaps a bit better in these categories, you would use it, even if it was perhaps harmful in the long run to the web design profession and the quality of the web itself.

    Does it imply that? Do you not consider “the quality of the web itself” to be encapsulated in my words when I talk about elegance and quality?

    In general, you’re right. I don’t use Web Standards because they’re standards. Rather, I use them because they’re useful — to me, to my client, to users, and to the web itself. If another tool came along that is also useful to all parties, I would certainly conider using it.

    And no, I would not include Flash (used appropriately) in that category. If you want to use an alternative display technology, make an argument for how it is complementary to the ideal of standards, rather than dismiss them entirely

    I would include Flash in that category. But that’s besides the point. You think I’ve dismissed Web Standards entirely? Maybe you need to re-read the piece, my friend.

    My point is that there are reasons to use web standards that go beyond their usefulness in making you and your clients money.

    No, there’s not. If there are, let’s hear them.

    However, the benefits of standardization in an open and free medium such as the web often outweighs other shortcomings.

    Bingo! Now, tell me this: who benefits from them? Do me and my clients not reap some of these benefits? Yes, we do. And that’s why I usually use Web Standards — because the open nature of them provides a lot of great benefits to me and my client. God knows it’s not because they offer great design tools!

    We’re making the same argument, just in different ways. You think we should use Web Standards because of all these benefits (that you aren’t naming, but I know are there). I’m also saying you should use Web Standards for all these benefits (which include things like maintainability, lower bandwidth consumption, speed of development, speed of rendering, and more). The only difference is that you think we should also use them because they’re standrds, and I think the benefits they provide (in part by way of them being standardized) is the only reason to use them.

  47. 047 // Doug // 09.04.2007 // 11:16 AM

    The distinction between standards and Web Standards: Are you talking about the difference between formal standards and de-facto standards?

    Policy and procedure may be boring, political, and infuriating at times, but they are the necessary foundation that Web Standards are built upon. Do you suggest an alternative? Perhaps there is more room for more democratic participation in the adoption of these standards and I think that is what you are getting at with more inclusion of web designers.

    Do you not consider “the quality of the web itself” to be encapsulated in my words when I talk about elegance and quality?

    Not necessarily. One could argue that you can make a quality website that is elegantly conceived in terms of how it serves your client but detracts from your big idea:

    My big idea is to using this incredible global network we’ve built to share ideas, communicate, and establish relationships never before possible

    Are standards not integral to making this a reality? People working with the same set of tools (which are derived from a formal protocol which is consistent, open, and documented)? Do you not think that some corporations (which may be your clients) would want to do things in a manner that goes against your ideal?

    My point is that there are reasons to use web standards that go beyond their usefulness in making you and your clients money.

    No, there’s not. If there are, let’s hear them.

    See above

    The only difference is that you think we should also use them because they’re standrds, and I think the benefits they provide (in part by way of them being standardized) is the only reason to use them.

    This argument could go forever round and round in circles. If you should use them because of the benefits they provide, and if (at least some) of the benefits they provide are because they are standardized, then logically it follows that you should use them because they are standards.

    Perhaps your post is meant to be provocative - to help move things along. And it is a positive statement of how far things have come that we can even have this argument. I think what you are really arguing for is a reformation in the way standards are conceived. In that case, perhaps you should care about standards more. Maybe we all should so that they reflect our needs to an even better degree.

    You think I’ve dismissed Web Standards entirely? Maybe you need to re-read the piece, my friend.

    No I don’t think you have. I just think you are missing a major point - you cannot separate standards from Web Standards. You can’t say you care about Web Standards and then say you don’t care about standards.

  48. 048 // Christian // 09.04.2007 // 11:19 AM

    Christian: I think that’s pretty much the idea behind the button at the bottom of Mike Davidson’s site. :)

    Oh, yeah, I think I’ve seen that before.

  49. 049 // Doug // 09.04.2007 // 12:24 PM

    Eric,

    While things outside of the technical specs (like non-semantic class names)

    As far as I know, how you name classes is not part of any technical specification. It is only a suggestion.

    Jeff,

    Most of these standardistas who insist on being 100% semantically pure every time and never having even a single iota of JavaScript inline and encoding every single ampersand at all costs

    Likewise, only unencoded ampersands will keep your code from validating and then, it depends on what doctype you use.

    The specific instance I was referring to was the use of the Blueprint framework, which offers extreme speed and layout flexbility at the expense of 100% pure semantics.

    Again, Blueprint does not violate any technical standard.

  50. 050 // Jeff Croft // 09.04.2007 // 12:29 PM

    The distinction between standards and Web Standards: Are you talking about the difference between formal standards and de-facto standards?

    I’m making distinction between policy/proceedue and tools. I hate policy and proceedure. I refuse to to anything just because someone told me too. Rather, I like to evaluate the options and make my own decisions as to what is appropriate. To me, “standards,” are formalized proceedure that you’re “supposed” to follow. Web Standards are a set of specs, tools, and best practices for web site design and development.

    One could argue that you can make a quality website that is elegantly conceived in terms of how it serves your client but detracts from your big idea:

    I guess, if they were analyzing my words pedantically and out of context rather than looking at the big picture of my post, they could. That’s not what I meant.

    If you should use them because of the benefits they provide, and if (at least some) of the benefits they provide are because they are standardized, then logically it follows that you should use them because they are standards.

    Or, you could look at it like this: if they provided no benefits, even though they are standards, I wouldn’t use them. So I’m not using them justbecause they’re standards. Right?

    Perhaps your post is meant to be provocative - to help move things along.

    Of course it is.

    I think what you are really arguing for is a reformation in the way standards are conceived.

    Nah. What I’m arguing for is for web designers and developers to not blindy buy into Web Standards because someone else (Zeldman, Meyer, the W3C, whomever) told them they should, but rather to evaluate them — and other available tools — with the context of each project and decide when and where they make sense. I’m basicaly arguing for people to think for themselves (and on their client’s behalf), rather than adereing to Web Standards as religion.

    In fact, religion is a very good analogy. I have no problem with organizaed religion or faith. But, I would suggest to nyone that they take them time to understand a particular religion and evaluate other option before they blindy adhere to a religion just because, for example, their parents do.

    No I don’t think you have.

    You certainly suggested that’s what you thought.

    I just think you are missing a major point - you cannot separate standards from Web Standards. You can’t say you care about Web Standards and then say you don’t care about standards.

    Maybe. Like you said, this could go ‘round and ‘round forever. My point is simply that people sould use Web Standards — and any other tools in their stable — for the benefits those tools provide, not because of blind faith.

  51. 051 // Jeff Croft // 09.04.2007 // 12:30 PM

    As far as I know, how you name classes is not part of any technical specification. It is only a suggestion.

    Which is precisely why I was careful to include “best practices” in my definition of Web Standards. Likewise, using tables for layout is not invalid in any way, but it’s certainly aganist the spirit of Web Standards. Yes?

    Again, Blueprint does not violate any technical standard.

    No, but some have suggested that is violates the best practices that are also part of the Web Standards movement.

  52. 052 // Doug // 09.04.2007 // 2:59 PM

    My point is simply that people should use Web Standards — and any other tools in their stable — for the benefits those tools provide, not because of blind faith.

    Ok. I totally agree with you there. But I think your post suggests far more than this when you say “I don’t care about [technical] standards”.

    Technical standards are what browser manufacturers use to develop their applications. We all know why this is important.

    I hate policy and proceedure. I refuse to to anything just because someone told me too. Rather, I like to evaluate the options and make my own decisions as to what is appropriate

    You code with Python right? Do you hate that you have to indent all of your code for it to work properly? If HTML/XHTML/CSS parers were more stringent in how they handle errors, we wouldn’t even have the luxury of having this argument.

    So if designers are going to use

    any other tools in their stable

    they should take into account not only the benefit they and their client are getting, but also the impact using these tools will have on the state of the web and of their profession as web designers. Specifically, this refers to proprietary extensions to existing languages and to new proprietary languages. It is because of the nature of the web as a free and open medium for communication that this is more important perhaps than in other professions.

    Web Standards, on the other hand, are much more fluid and changeable. They come about as part of an organic consensus, not as a technical specification. They are more suggestions than ultimatums. Therefore, if there are things that are part of Web Standards that you find useless or less than optimal, make you case for why things should be done differently. Otherwise, why bother getting involved in the discussion?

    As Joe Clark noted:

    Getting 95% of the way toward Web standards (defined by the easy proxy of valid HTML and CSS) puts such a developer in the top 0.5% of all developers.

    You are at the point where you can make much finer distinction between what should and should not be sacred. But for someone just starting to learn and being introduced to the profession, they don’t know enough yet to make such distinctions. So in their case, they should

    use Web Standards because Jeffrey Zeldman told [them] to

    until they know enough to be more subtle about their choices.

    Having said all this, I think I understand now where you are coming from. But I also think that while you innovate and challenge convention, don’t forget the shoulders you are standing on.

  53. 053 // Jeff Croft // 09.04.2007 // 3:31 PM

    You code with Python right? Do you hate that you have to indent all of your code for it to work properly?

    No, I love it. I can immediately see many benefits of proper indentation, so I’m thrilled that the languages forces this best practice on me.

    If HTML/XHTML/CSS parers were more stringent in how they handle errors, we wouldn’t even have the luxury of having this argument.

    Right. But they don’t.

    they should take into account not only the benefit they and their client are getting, but also the impact using these tools will have on the state of the web and of their profession as web designers.

    I’m not disagreeing with you here — am I?

    Specifically, this refers to proprietary extensions to existing languages and to new proprietary languages. It is because of the nature of the web as a free and open medium for communication that this is more important perhaps than in other professions.

    I’m not sure where I’ve advocated for proprietary extensions and proprietary languages.

    You are at the point where you can make much finer distinction between what should and should not be sacred. But for someone just starting to learn and being introduced to the profession, they don’t know enough yet to make such distinctions.

    So they should learn.

    Having said all this, I think I understand now where you are coming from. But I also think that while you innovate and challenge convention, don’t forget the shoulders you are standing on.

    Of course.

  54. 054 // Doug // 09.04.2007 // 4:22 PM

    Right. But they don’t.

    So that means would shouldn’t enforce best practices on ourselves? Rendering engines have been left flexible for the precise reason of allowing non-professionals an easy entry in web publishing. Not to allow seasoned designers and developers to be sloppy.

    I’m not disagreeing with you here — am I?

    Nowhere in your original post do you include any mention of the the larger (in scale) priorities of the state of the web or of the web design profession.

    I’m not sure where I’ve advocated for proprietary extensions and proprietary languages.

    From your original post:

    There are times when Flash makes sense … There are times when proprietary HTML, CSS, and JavaScript, written for exactly one browser rending engine makes sense

    I don’t necessarily disagree with you, but I do disagree that the only way to judge whether these should be used is based on your four stated priorities which include only yours and your clients needs.

    So they should learn.

    great advice. again, a lack of regard for the profession as a whole.

  55. 055 // Jeff Croft // 09.04.2007 // 4:51 PM

    So that means would shouldn’t enforce best practices on ourselves?

    When those best practices have obvious benefits to the success of our work, then we absolutely should enforce them on ourselves — and I always do. Wehn they don’t have obvious benefits, I’m much more lax about how much they matter to me.

    Nowhere in your original post do you include any mention of the the larger (in scale) priorities of the state of the web or of the web design profession.

    Sorry about that.

    I do disagree that the only way to judge whether these should be used is based on your four stated priorities which include only yours and your clients needs.

    I would very strongly disagree with that, as well. I definitely never said people should use my stated priorities in deciding what’s right for their project. On the contrary, I said only the designer actively working with the client can make these kinds of decisions adequately. Neither me, nor Zeldman, nor the W3C, nor any book on the shelf is going to be able to provide a better solution than a seasoned designer who knows what his clients wants and needs in order to be successful.

    great advice. again, a lack of regard for the profession as a whole.

    Your right. You win. I hate the web design profession. The reason I’ve been blogging about it for the past five years is that I have a total lack of concern. You win, man. Congratulations.

  56. 056 // Doug // 09.04.2007 // 6:05 PM

    I hate the web design profession. The reason I’ve been blogging about it for the past five years is that I have a total lack of concern.

    Not the point of my posts. I only think that as a person will a modicum of influence over the web design profession that this post in particular should consider larger ideals when dispensing advice. This particular post comes off as cynical and self-serving at best and at worst an attack on a particular group of people.

  57. 057 // Jeff Croft // 09.04.2007 // 6:11 PM

    Doug: This is my personal blog. I say what’s on my mind. It is self-serving. All personal websites are self-serving. I’m sorry if that’s not what you want it to be, but it’s my personal site, and I use it as I wish.

  58. 058 // Doug // 09.04.2007 // 6:51 PM

    fair enough

  59. 059 // brandaggio // 09.05.2007 // 8 PM

    Code as well/thoroughly as you can given the scope and budget of a project. Make compromises when/if you deem necessary. Consider details, if the scope and budget allow, that others might not, because they will matter on certain devices/browsers/displays.

    Seems simple enough…pay attention to what you know and can impact…

    Though most of us should have learned this in kindergarten.

    If I really look out for my clients best interests, they will notice, and I will have a long time client. This has more to do with CRM than web standards I agree - but as you convey, there is value in addressing issues that escape the client, some of which may involve sparkly, semantic markup and fully abstracted JS and CSS.

    IMHO, this is what being a “professional” is all about - reading between the lines.

    A good writeup Jeff - reminded me of what I have to deal with most every day.

  60. 060 // Jeff Croft // 09.05.2007 // 8:18 PM

    Very well-said, brandaggio!

  61. 061 // Luke Visinoni // 09.06.2007 // 9:59 AM

    Wow, it’s refreshing to hear somebody say that. I agree with you. Sometimes I get so caught up in trying to make everything 100% perfectly standards-compliant when in fact, that isn’t even realistic when there are deadlines and clients who don’t know (nor care) about web standards. I know you’re not saying not to use web standards or that they take too long, but I agree that freaking out about every amperstand that didn’t get encoded is a luxury only afforded by those who aren’t working for clients in the real world.

  62. 062 // Ryan Joy // 09.06.2007 // 10:51 AM

    I came across this yesterday and had a good laugh:

    web standards, noun A large stick or cudgel, used by the slightly more anal-retentive to beat the slightly less anal-retentive. http://www.eod.com/devil/archive…

  63. 063 // David Comdico // 09.06.2007 // 2:14 PM

    To hell with bad browsers AND standards. Amen, but sooner or later (probably soon), a generation of designers will come along and want to demolish the idol of Web Standards for the sin of being conflated with standards small s. This is what I can see happening, and for the reason of a simple misunderstanding.

    Designers get bored with the status quo — and we’re living in it. Yet, out in the hinterlands, there are designers still using Dreamweaver coded tables for layout and clients who don’t know they shouldn’t be throwing away good money on such things. And they look at you cross-eyed when you mention the term Web Standards.

    Had we but world enough and time we could get everyone up to speed before careening after the next big thing. But the big wheel keeps turning, faster and faster.

  64. 064 // Matt Williams // 09.06.2007 // 4:33 PM

    I think the point that a lot of people seem to miss (not saying that you are one of them) is that best practices, web standards, etc., are tools. If you were carving a sculpture out of wood, you’d use a different chisel than if you were carving the same sculpture out of granite. The tools exist to make our lives easier so that we can work smarter — not harder.

    I’ll gladly use tools like blueprint.css where appropriate so that I can concentrate on other parts of the code, particularly in cases where there are time constraints. It’s another tool to add to the toolbox and to be pulled out when appropriate.

    I really feel that people get so caught up in the idea of “Doing the Right (TM) Thing” (as they perceive it) that they lose focus on why they’re doing it in the first place, to do a task. But I’m a pragmatist.

    The nice thing about standards is that you have so many to choose from.” — Tannenbaum

  65. 065 // Doug // 09.07.2007 // 10:20 AM

    I’d like to respectfully disagree with those who are referring to web standards as “tools”. They are not tools.

    If you were carving a sculpture out of wood, you’d use a different chisel than if you were carving the same sculpture out of granite.

    Except in this case, web standards (HTML/CSS/DOM) are the granite or wood, not the chisel. Dreamweaver is a tool. TextMate is a tool. The Flash Development Environment is a tool. Your MacBook is a tool. These are tools web designers/developers use to build websites from these standardized languages.

    When you are writing a article, the pen (or the web browser) is the tool not the english language.

    Its not directly related to the idea of whether we should use web standards or not, but I suspect that this error in distinction is creating confusion in the profession.

  66. 066 // Jeff Croft // 09.07.2007 // 10:42 AM

    Doug: I can get behind your version of the analogy (even though I’ve called Web Standards “tools” several times now…fact is, I don’t really know what else to call them). You’re right — Web Standards aren’t quite “tools” in the same sense that Dreamweaver and TextMate are.

    To take the analogy a little further: when you’re making a sculpture, you’d choose the right material for the job. You’d choose the one that gave the look, durability, emotional response, etc. that you were going for. You’d consider things like where the sculpture is going to be placed (i.e. will it have to endure weather?) and what type of people are going to be viewing it in making your choice. Right?

    And that’s basically all I’m suggesting. That we are not so obsessed with granite (Web Standards) that we are too blind to see to see times and place where wood (Flash, Java, whatever) might be a more appropriate choice. Rather, that we are sure to evaluate each sculpture and thoughtfully determine which material(s) are most appropriate for its needs.

  67. 067 // doug // 09.07.2007 // 1:39 PM

    I actually think that the language analogy is better than the materials analogy. Unless you are Lou Kahn wondering “what does this brick want to be?”, materials don’t have inherent meaning, while languages do.

    In that case, technical standards (HTML, CSS) are the language and Web Standards are the grammar used to construct that language in a way that makes sense.

    For example, tables did not violate the “language” but violated the “grammar” because they were used in a way that did not make sense. One of the revelations I had when I started using Web Standards was not only that they were efficient and more productive, but they “made sense”.

    The question that is still up for debate is whether Blueprint “makes sense”, or is a step backward not quite to the level of tables, but in that direction.

    Part of the problem is that div and span have no inherent meaning and thus need semantic class names to give them meaning. HTML 5 seems to be addressing this. The other problem is the lack of a good layout mechanism in CSS. This looks to be addressed in CSS 3.

    So what do we do in the meantime? Blueprint may fill that gap, but it may not be a direction we want to go.

  68. 068 // Jeff Croft // 09.07.2007 // 1:56 PM

    In that case, technical standards (HTML, CSS) are the language and Web Standards are the grammar used to construct that language in a way that makes sense.

    I like the analogy. I’d point out, though, that Web Standards are only one available language. Flash, for example, is another.

    The question that is still up for debate is whether Blueprint “makes sense”, or is a step backward not quite to the level of tables, but in that direction.

    That does seem to be a question people want to debate, but so far, no one has been able to offer up a good reason why Blueprint’s class name are a step backward. People assert that they are, and then can’t explain why. I’ve asked this several time, and still haven’t gotten an answer: what real-world problem does using Blueprint create, that doesn’t exist when using “semantic” class names.

    I put “semantic” in quotes, because I would argue that Blueprint’s class names actually do offer meaning: the describe the visual presentation of an element. That’s semantics. It just visual semantics. In many cases, those DIVs and SPANs you refer to are only there for visual reasons. People want to pretend they’re “structure,” but they’re not.

    Part of the problem is that div and span have no inherent meaning and thus need semantic class names to give them meaning.

    DIVs and SPANs have no inherent meaning. Giving them a class name doesn’t really give them meaning, either — it may give them some meaning to you, but it doesn’t give them any meaning to the rendering engine.

    But here’s the question: why do you think they must have meaning?

    I’ve got no problem with DIVs and SPANs hanging around that have no meaning, and act only as visual or behavioral hooks. I’d like to limit them to as few as possible, just for the sake of reducing clutter, but they certainly don’t hurt anything…do they?

    HTML 5 seems to be addressing this. The other problem is the lack of a good layout mechanism in CSS. This looks to be addressed in CSS 3.

    I’m not too convinced CSS 3 has a “good layout mechanism,” but it’s certainly better. At the rate we’re going, I’m really looking forward to being able to give it a try in 2012.

    Blueprint may fill that gap, but it may not be a direction we want to go.

    Again, I would challenge you to explain why. You and other keep suggesting it’s a bad “way to go,” but I’m still not hearing the justification for that position.

    So what do we do in the meantime?

    Whatever we can to get shit done, in the most elegant fashion possible with the limitations we have. I’d argue that Blueprint fits right into that.

  69. 069 // doug // 09.07.2007 // 3:39 PM

    Flash, for example, is another [language]

    It’s not really, not in the same way. Its more of a “program”. It is not self-descriptive. This is why it is not well suited for text based presentation.

    You and other keep suggesting it’s a bad “way to go,”

    I’m actually not. I haven’t decided yet how I feel about Blueprint. My argument is more about what criteria we should use to determine whether or not it is the way to go. And I think the criteria should go beyond mere “practical” everyday concerns. Perhaps you do too, when you say “most elegant fashion possible”, but I believe the point needs more emphasis.

    There should be some middle ground between “whatever we can to get shit done” and standards fascism - a ground that takes into account both the needs of the designer and the client, and a larger understanding of what HTML is and how it should be properly used.

    Again, I think that you are implying it, but I think it is something that bears explicit exploration.

  70. 070 // Shaal // 09.07.2007 // 5:25 PM

    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.”

    Holy Cow, isn’t this clear enough ? I am surprised how and why would some feel it was an attack on Web Standards~huh

    P.S: Atleast i learned using a few Markdown syntaxes, for an HTML dude it was something new for me~

  71. 071 // doug // 09.08.2007 // 1:28 PM

    That does seem to be a question people want to debate, but so far, no one has been able to offer up a good reason why Blueprint’s class name are a step backward. People assert that they are, and then can’t explain why. I’ve asked this several time, and still haven’t gotten an answer: what real-world problem does using Blueprint create, that doesn’t exist when using “semantic” class names.

    I’ve been looking through Blueprint in greater depth. I think it is a great piece of work. I think the reset, typography, and buttons libs are excellent.

    Looking over the grids lib, I don’t think the non-semantic class names create any new problems in an of themselves. But, I also don’t see any great benefit to using the non-semantic class names (technically semantic refers to a description of the content, not to how it is displayed which is independent of its meaning).

    While I think it is great in showing how to create a multicolumn layout, why not just add those styles to the css of the specific element(s) that you want to display that way? If there are several that you want to display in the same way, group them together. Does extracting the information out really save that much code and time (if any)? (this is a real question - what is your experience?)

    I also think there that it could make the CSS/HTML harder to follow for someone new coming into the project. Since the declarations are abstracted out, one would need to search for them in multiple places to find out what is going on with the basic structure of the page.

    I think the other problem is more psychological. I think it freaks people out to see column and span because it reminds them of tables! So perhaps that is one reason for the backlash.

    But also, what is happening here really isn’t a “span” is it? It’s really just a width and a padding. I think things could get confusing really fast, especially if you start nesting.

    So in the end, I think I would use it as a template for how I should create a grid layout, but I would abandon the non-semantic class names because I think the abstraction would not add enough benefit to justify breaking the grammar of web standards.

  72. 072 // Jeff Croft // 09.08.2007 // 1:45 PM

    But, I also don’t see any great benefit to using the non-semantic class names

    The benefit is, when you’re working on 30 different sites, you have one set of class names to deal with. You have to appreciative the environment this was created in. When we created the grids library, we were working on 30+ news sites on a team of four designers. We needed a consistent set of class names and conventions that everyone could keep track of and that applied to every site. We couldn’t have one guy calling something “content” and the next calling it “main”.

    Also, we had to create layouts independently of their content. We had to create layouts that worked with all sorts of content. As such, it was often impossible to give clear content-related name, because we simply didn’t know what the content was going to be.

    Finally, we often times had to create several of these layouts in a matter of a few hours.

    Understand this: I don’t think Blueprint (or any CSS framework) is appropriate in every case. But when you’re working on teams on several different sites and the projects have to be completed quickly, having a consistent, abstracted way of doing things can be a huge efficiency booster — and at the cost of what? Nothing, I’d say.

    why not just add those styles to the css of the specific element(s) that you want to display that way?

    You can, you should, and we did. You should definitely not create extraneous div elements for no reason. You can, and should, apply span-14 to an h1 without first putting a div around it.

    Does extracting the information out really save that much code and time (if any)?

    For us, it saved am amazing amount of time. We, quite literally, redesigned entire newspapers sites with thousands of pages in a matter of two or three days.

    Again, I’ll point out that it won’t save that much time for everyone. But our circumstance was a perfect scenario for the use of a consistent framework. If you’re one guy working on a handful of sites, you’re not going to see the same benefits.

    I also think there that it could make the CSS/HTML harder to follow for someone new coming into the project

    Not if those people are first trained on how the framework works. Rather, it makes it easier, because every site is the same.

    I think the other problem is more psychological. I think it freaks people out to see column and span because it reminds them of tables! So perhaps that is one reason for the backlash.

    I think that’s accurate, but that’s their problem, not mine. :)

  73. 073 // Jeff Croft // 09.08.2007 // 1:46 PM

    But also, what is happening here really isn’t a “span” is it?

    It’s not a span in the sense of tables, but we were never thinking of tables when we came up with the name. You got a better name for it?

    I think things could get confusing really fast, especially if you start nesting.

    Try it for yourself and see. It made sense to us, and that’s who we created it for: us. We never expected it to get released to the world.

    So in the end, I think I would use it as a template for how I should create a grid layout, but I would abandon the non-semantic class names because I think the abstraction would not add enough benefit to justify breaking the grammar of web standards.

    I think that’s a perfectly reasonable thing to do in the case of someone working on one website. If, however, you’ve got to create 20 layouts for 5 different sites in the next two hours, that is simply impractical.

    To repeat myself, in an effort to be clear: Blueprint is not perfect for every situation. I don’t think everyone should use it. When we created it, we did what made sense to us, for the situation we were in. In my A List Apart article about CSS framework, I deliberately did not put any of our code out there, and rather recommended that teams come up with their own framework specific to their needs. Olav took our code, ran with it, and released it (with a lot of changes) to the public. That’s fine — I’m glad he did. But please do understand that even though I wrote a lot of the code, I don’t necessarily believe it’s right for every situation. I’m only defending it’s use in situations similar to ours. And what I’m really defending is the concept of framework and libraries, moreso than this particular framework and its libraries.

  74. 074 // doug // 09.08.2007 // 2:35 PM

    Also, we had to create layouts independently of their content. We had to create layouts that worked with all sorts of content. As such, it was often impossible to give clear content-related name, because we simply didn’t know what the content was going to be.

    I think this is the best argument for the non-semantic class names. This is a peculiar phenomenon to the web, isn’t it? We need to do it, but somehow it goes against what content design is, which should flow from the content out. The dynamic nature of most websites these days makes it sometimes difficult to describe what you are displaying.

    Also, there is a fine line between what is presentational and what is descriptive of content. I wonder if the orthodox web standards practictioners have an issue with “sidebar” as a class or id name. Isn’t “side” a presentational description?

    Perhaps an argument can be made that “column” and “span” are structural class names rather than presentational. Like the difference between a buildings structure and its ornament.

    But I guess it’s just all “semantics” :)

  75. 075 // Ool // 09.16.2007 // 9:06 AM

    hmm ajax with blueprint css class names…

  76. 076 // Bob H. // 09.18.2007 // 9:18 AM

    So basically you live in the real world. It’s nice to hear it from a popular web designer. Us no-names get tired of being beaten down by the standardistas.

  77. 077 // Johan // 09.19.2007 // 8:37 PM

    Jeff Croft - A man who sees thru cruft and knows his craft.

  78. 078 // SEO // 09.20.2007 // 5:11 AM

    It’s amazing what a hornet’s nest talk on semantics stirs up.

    if your knowledge of web standards is good then all your coding should follow it strictly (and almost entirely without effort) from the very beginning.”

    Very true, through good habits from the beginning it isnt “that” difficult.

    Achieving valid code is never my end goal — but it helps me get there. ”

    Also true, that should go down in one of the famous history quotes.

    Carly,