!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Unrestricted

2 July 2004

15 comments

A Blue Perspective: !DOCTYPE html PUBLIC

There's so many things you have to worry about when you're making a table-free web site: box models, 3-pixel mystery whitespace, relative font sizes, cascading rules, floats ... but really, none of it matters. When you're designing a web site you shouldn't think about them.

When it comes to web design, pure graphic designers have blessed ignorance. They don't have to think forward and think about how they're going to implement their design; they don't have to wonder exactly how you can get a footer at the bottom of the window all the time. And this is how web designers should do it.

Standards-based design is still at a fledgling stage. Everywhere you look you see tutorials on how to make XHTML/CSS Web sites, and new techniques come out every day. Without pushing design, without not thinking about implementation, no one would push the boundaries of Web Standards and they probably would have disappeared right about the time that someone asked "how do I make 2 columns equal height?"

Design isn't about the tools, it's about creating the best experience for the user. A design should be based on usability, accesibility, aesthetics, but never on floats, lists or background images.

When I start to design a Web site it's purely a graphical excursion. Photoshop and Illustrator are my only limits – within those bounds I can create a five column, sticky-footered layout with drop down menus and a floating font-colour chooser. Don't care whether I can implement it or not – it's what I'd love to see.

Then ... then the problem solving begins. It's the analytical side of web design that makes us web designers lick our lips, makes us part Turing, part Picasso (really small parts). Maybe finding that solution to that layout shouldn't be as hard as it sometimes is, but I relish in the challenge and take on all comers.

The goal of Web Standards is to make them invisible, display no differently than tables or a quagmire of presentational tags. So it's our duty to design well and Standardise later.

(Adapted from a talk given to the Web Standards Group)

Categories

,

Comments

  1. 1/15

    Scott commented on 2 July 2004 @ 10:25

    You my friend have written an awesome article!

  2. 2/15

    Christopher Bourque commented on 2 July 2004 @ 11:04

    Amen - it's all about effective communication. Design boils down to getting the right message to the right audience and doing it effectively. What will our tools for doing that be in 5 or 10 years? I doesn't matter. It's still all about good design. Period.

    Great article!

  3. 3/15

    Christopher Bourque commented on 2 July 2004 @ 11:12

    Sorry for a second post. I just had to follow up that I believe in web standards, best practices, or whatever we want to call it - I just don't ever want to loose sight of our goal. Which is:

    Saying what we need to say and saying it well through good design.

    I'm not saying that poor methods, tag soup, and things that hinder the advancement of good coding practices are irrelevant compared to effective design. We just can't focus too heavily on them and miss what's most important.

  4. 4/15

    Rob Mientjes commented on 2 July 2004 @ 15:15

    Well, I build, add, rebuild, validate, (usually fix :P) add, publish and by that time, it's more than what I had in my mind. It's just a living process, which can be scary. But I like it nevertheless.

  5. 5/15

    Razvan Pop commented on 2 July 2004 @ 17:45

    Nice article. I make some nice designs in Photoshop but when it comes to cutting and putting in HTML i have to make lots of adjustments to get it right.

    I will try harder. Keep going with the good work. :)

  6. 6/15

    Keith Bell commented on 2 July 2004 @ 21:06

    You're absolutely right, Cameron. Most of the time, I've been responsible both for the layout design and the coding of client sites, and I know that what I have done with the layout has been tempered by the knowledge that I have to code the damn thing -- so I've always had half my brain on what it's possible or easy to reproduce in code. Recently though, I've worked on a few sites where I was handed the layouts in the form of a few graphics files, and asked to build table-free HTML templates and accompanying CSS files. It's been an interesting departure from my usual experience, and I'm pleased that so far, nothing has "defeated" me. We might complain about the current limitations of the CSS spec and the poor support amongst browsers, but even with the tools as they are, it's remarkable what you can do when you put your mind to it.

  7. 7/15

    Mel hogan commented on 5 July 2004 @ 00:35

    Agreed! One of my biggest issues is handing my design over to programmers who have no interest whatsoever in the aesthetics of the design. I'd much rather code the entire site my self, solving the problems along the way, and end up with what I designed, without massive hacks and "fixes" used by most coders today. Half of the fun of this business is the problem solving, people forget that too often I believe.

  8. 8/15

    Mike D. commented on 5 July 2004 @ 04:20

    Agreed, absolutely.

    The main draw of XHTML/CSS to me was never about adhering to some obscure set of rules I played no part in creating. It was about using a set of tools which made my life easier.

    You mean I can alter the typeface of my entire site with one change? Great. I'm all for it. I can more easily redesign my site in the future? Again, great.

    But adhering to a set of rules for the sake of adherence alone was never a motivation for me. I'm all for doing whatever makes both my life and my users' lives easier. Revalidating my site ever hour doesn't fall into that category.

  9. 9/15

    Charles McCN commented on 2 August 2004 @ 16:36

    The role of designers is to design. Where people have enough resources to get a rpoject right, the designers do just that.

    Then the Web encoding geeks go away and figure out if the design will work - and come back to say "So what should it look like on a phone?" or "What should it sound like?". Unless the designers did a really good job, so that stuff is obvious.

    And then, in an ideal world, the web geeks code it up, the punters happily use it, and everyone goes away smiling.

    The problem is that in my world there are lots of things taht can go wrong - somewhere between teh great design and what I am actually reading is a bunch of implementation. Whether it is the stupid browser I use, or a poor bit of CSS coding, the system breaks down. And since most Web designers these days are both the design department and the web geek, it's up to them to realise what won't work and find out how to do something different.

    Paper designers are constrained to work on a fixe size, with little interactivity. Whether or not those are ideal features of whatever they are trying to convey. Web designers are in the opposite end of the wrld, where nothing is fixed. Deciding whether to compromise your design for all users, or whether to tell some users that you're not interested in their problems is a tricky decision without many generally applicable rules. But it's what the people who work in the middle - the implementors - have to do. When they are also the designer, they get used to measuring their cloth before they start designing, which is a restriction on how they can work. Right one or not? depends...

    (nice presentation. *^&(^(*&^ Opera 7.52 messes up your style sheet somehow)

  10. 10/15

    Tim Madden commented on 16 November 2004 @ 14:16

    It's like a print designer shouldnt think of the printing process when he is designing something to go to press.

    Seperating design from the development is fraught with danger. I think that there is a small level of seperation but mostly I think that development and design overlaps and I can't see how it cannot.

    Print and Web designers are all constrained by one major issue,,,, client budget.

  11. 11/15

    Julian Doncaster commented on 17 November 2004 @ 03:55

    Yes - escape from the constraints

    It seems to me that by limiting yourself to the graphical, you are reimposing the limitations we escaped when we left paper behind.

    Our thinking must include the user interaction with a *web*-site. It is a web, not a page.

  12. 12/15

    oliver stieber commented on 24 December 2004 @ 17:12

    Well, that's all fine until.... you have to make the design dynamic.

    this page, for instance would start to look very silly if you have a few hundred comments, it would also start to grind to a halt and put a huge load on the servers.

    Designing a web page is like designing a car.

    Make a card look too nice and it will turn into a wing and take off (not very safe).

    Just concentrate on how 'a' page looks and you loose site of the interactive medium that is the web.


    That said, I don't think that you should let XHTML get in the way of the design, but then again when you can knock up an XHTLM page to any layout you like in an hour it doesn't get in the way, it becomes you pallet.

  13. 13/15

    下载 commented on 28 January 2005 @ 00:35


    Thank you  I am learning of new things all day! And it is good to know of my RSS already work.

    I think I need add button of RSS to make this thing clear.

  14. 14/15

    SEO commented on 30 January 2005 @ 11:14

    Where do I start? Let's see. If you use the same building tools and process for building all your client sites, then desgning a site with well-designed navigation is definitely the first and most important step. It is however valuable to know how the coders will cut up your design, or how your template may talk to your database of content effectively. This leads into issues relating to CMS etc. It is always wise to build with the end in mind. We come across so may good looking websites which no one can find via search engines as they are totally lacking in basic html standards or are built via a graphical interface like Dreamweaver, where all the code is built on the fly with no control by the designer.
    All in all, when you build a website, the process is ongoing, ensuring you are keeping up with the times and demands clients have of their websites. The ownice is on the designer and webmaster of course. The more learned this person is, the less they have to think about any issues that may arise regarding their client's websites.

  15. 15/15

    Fahed commented on 15 February 2005 @ 01:03

    I find that i have had a lot of benefit from web standards. There is a lot that you can do in CSS that cleans up your web pages and once you're used to it, you can accomplish the impossible.

    I have seen webpages that are 500 lines long get cut down to 50 using CSS.

    And then, of course, there is the satisfaction of seeing the output "this site is valid XHTML/CSS/RSS".

     

  16. Leave your own comment

    Comments have been turned off on this entry to foil the demons from the lower pits of Spamzalot.

    If you've got some vitriol that just has to be spat, then contact me.

Follow me on Twitter

To hear smaller but more regular stuff from me, follow @themaninblue.

Monthly Archives

Popular Entries

My Book: Simply JavaScript

Simply JavaScript

Simply JavaScript is an enjoyable and easy-to-follow guide for beginners as they begin their journey into JavaScript. Separated into 9 logical chapters, it will take you all the way from the basics of the JavaScript language through to DOM manipulation and Ajax.

Step-by-step examples, rich illustrations and humourous commentary will teach you the right way to code JavaScript in both an unobtrusive and an accessible manner.

RSS feed