Home
About
Categories
 Design
 General
 Inspiration
 Project Management
 Resources
 Strategy
 Technology


<March 2006>
SunMonTueWedThuFriSat
2627281234
567891011
12131415161718
19202122232425
2627282930311
2345678

Your best shot at happiness, self-worth and personal satisfaction - the things that constitute real success - is not in earning as much as you can but in performing as well as you can something that you consider worthwhile.
~ William Raspberry

Art. You never learn it.
~ Milton Glaser

 

 

 Friday, March 24, 2006
CSS, Web Standards and Clients

I often have to decide what techniques or technologies will be used to build a site. Some are defined by the project's requirements. Others can ALMOST be arbitrarily made. Examples include databases, MySQL or SQL Server; whether or not to include Flash in a site and to what extent; developing a data access layer or use single tier architecture; or should a table HTML structure or layers and CSS be used.

I can appreciate the benefits of no tables and separating content from formatting, but I have a few issues with the standards compliant way of doing things:

  1. There are no real standards. Therefore it’s almost impossible to build a site with any interface complexity that will view correctly in an acceptable percentage of browsers or situations. Table layouts are pretty much bullet proof.

  2. Time and money - If a standards site is done correctly and does view in all required browsers chances are it took a lot longer to build than if tables were used. Does the benefit outweigh the cost?

  3. Development resources - The one prevalent factor I always consider is who needs to work on the site in the future. It is important deliver a site for which a client can find development resources when changes are needed. I have experienced a couple times when a site was delivered that was too complex. Not only are the user's technological limits a factor, but the client's technological limits can sometimes also be a constraint.

    We once built a killer site with a dynamic content and Flash and within two years the client had a simpler one built because they wanted an intern to be able to make changes using Front Page. (shudder) We were not told this at the time. Another experience was we built a really nice interface for a web app in layers. When it was handed off to the development team they did not know how to make it work with the dynamic content as they said they could. We had to redo the layouts in tables.

The point is, in a perfect world the idea of compliant sites with clean separated code rocks, but the reality is, it's often not practical. Cutting-edge (scary that I'm calling techniques that are several years old cutting edge) always has added risk. Careful consideration must be made before choosing any technique. Rework is too costly.

Project Management
Comments [0]  



A practical look at strategy, project management, technology and design for today's web.

Blogs & Portals

 37 Signals
 Ad Pulp
 Adaptive Path
 AdRants
 Alltop
 Brandstorming STL
 Coudal
 David Byrne
 David H Hansson
 David Hayden
 Design Charts
 Design Observer
 DNN Creative
 Flash Authoring Team
 FWA
 Guy Kawasaki
 Joseph Jaffe
 Joshua Jefferies STL
 Kaliber 10,000
 Kottke
 Logic+Emotion
 Newstoday
 Paul Macfarlane STL
 Scott Guthrie
 Scott Mitchell
 Seth Godin
 TechCrunch
 ThoughtWorks Blog
 Tinic Uro
 Web 2.0 Workgroup
 Zeldman
Copyright © blend 2006. All rights reserved. | By James Bielefeldt. |