INTRODUCTION

The title of this article is controversial … the truth often is.

In my effort to reveal (what I consider to be) a huge disservice to the web design world, I continue to hammer home the fact that the web standards movement has gone too far – it has promoted bad practices and bad web design.

WEB STANDARDS ARE GOOD … WHEN USED AT THE RIGHT TIME.

Before I go on, I want to stress that I believe web standards are a good thing – it makes sense that browser makers agree on how things should work … it makes web design and web application development much easier and cheaper

That said, let’s try to remember that web design is not a mathematical equation to be balanced (or validated,) it is about creating effective websites that work today!

A LITTLE BACKGROUND.

I was building websites in 1994 back when the W3C was formed. For those of you who may not know, the W3C is an organization put together to define the specifications for web technologies like:

• HTML
• XHTML
• CSS

The web standards were created for browser manufacturers to implement and not for web designers. Well … at least not until the browser makers can get their act together and properly support the web standards. 

It makes no sense for web designers to try and force web standards based code to work in browsers that don’t support web standards properly.

WEB STANDARDS-CART BEFORE THE BROWSER-HORSE

Those who lead the web standards movement, must have forgotten the wise old proverb: ‘Don’t put the cart before the horse.’

In the context of web design, this means that you shouldn’t try to use technology/techniques and code that is NOT YET supported in the majority of browsers being used. Unfortunately, the web standards movement has done just that, and now there is a cost a lot of people are paying.

THE COST OF ZEALOUS ADHEARENCE TO WEB STANDARDS 

In a reality where (currently supported) CSS is not well suited for page-level layouts and buggy/inconsistent implementation between the major browsers (Internet Explorer FireFox,) are a fact of life, designing web sites following the now popular web standard zealot practices, has wasted countless hours for no real benefit.

Consider these facts:

1. CSS for layout is not intuitive at all. Since when is: ‘margin:0px auto’ intuitive for creating center aligned layout.
2. CSS is buggy and inconsistent between browsers.
3. The only true advantage of CSS based layouts is the separation of structure from formatting. This translates into the cross-device compatibility. A questionable need for most websites at this time …

CSS code for page layout stinks in terms of intuitiveness … it is the worst technology for page or user interface layout I’ve ever seen.   Anyone who has designed screens with Java or VB knows this. Actually, anyone who has used HTML tables for page layout knows this!

For example:

Creating a center aligned fixed or fluid layout, where the height expands perfectly in all browsers (without the need for hacks) is trivial and intuitive with an HTML table. With CSS, it is a tricky thing that requires hacks.

In fact, a whole culture of ‘hackery’ has developed because of this flaw in the thinking of the web standards zealots – the foolish practice of ‘putting the cart before the horse.’

TROUBLE WITH CSS HACKS

Because of the aforementioned problems with CSS and the browser bugs, hacks have been created to shoe-horn web standards based web sites into working with the browsers. At first glance the hacks seem like a viable solution … but they aren’t.

In fact, hacks should be avoided because CSS hacks rely on ‘broken’ aspects of browsers … things that can get fixed. Any programmer (with just a little experience) knows that basing your work on a broken technology is a recipe for disaster … because things get fixed.

THE DISASTER HAS OCCURED – IE7 WILL BREAK MANY WEBSITES THAT USE THE PROMOTED HACKS

One of the major arguments the web standards movement has used to convince people to ignore reality (the reality that CSS based layouts suck in many ways,) is the famous (infamous) forward-compatibility argument.

The myth of forward compatibility in a nutshell:  if you build your sites to standards, they are guaranteed to work in the future.

As it turns out, the first time this argument was put to the test (IE7) it failed miserably.  IE7 will be web standards compliant - so much so in fact, that many commonly used CSS hacks will break in IE7, forcing many well meaning web designers to have to go back and change their code – who’s going to pay for that time?

Some web standards zealots might argue that hacks are not ‘really’ promoted by the movement … this simply not true. Every web standards book, every web standards guru mentions, uses and promotes hacks. It too bad, since many web design books published in the last 3 years will have to be trashed since they teach techniques that will break in IE7.

THE SOLUTION

The key to this whole mess is found in common sense and a little experience:

Don’t leverage specifications until they are supported in the browsers.

Ok, how about making things work in both IE and Mozilla based browsers? The best solution is to use IE conditional comments. This is one example where thinking outside the web standards box makes perfect sense.

Stefan Mischook (a.k.a.: the web design heretic)

The term bait and switch has a slightly negative connotation, but I use it anyway because it sounds good … 

For small and medium sized web design projects, clients will typically want a final price for the project – it’s rare that they will let you work on a per-hour basis. Strangely enough though, clients will ask what you charge by the hour …

This is where this tactic comes in handy; the idea is to give them a per hour rate that sounds good … make them feel as though they are getting a special price. If what you charge per hour actually does sound good, then this tactic is not useful for you.

On the other hand, if you’re a cracker-jack designer, who charges more per hour because your work is that much better, or because you’re just faster at what you do, then bait-and-switch is what you need.

In a nutshell: it comes down to how many hours you actually work. Your clients will have no idea how long it will take you to complete the task! So if your rate is normally $50/hour (and $25/hour is the price that makes your client happy,) and you estimate the job will take you 10 hours. You can tell your clients that the job will take 20 hours at only $25/hour. This way, you’re able to give a more competitive per hour rate  , while still making the money you want for the job.

Conclusion:

At the end of the day, the bait and switch tactic I teach, is not about ripping off your clients – you MUST provide good value. Instead it just about framing your pitch.

In the business of web design, keeping the client happy is the most important thing you can do. Reducing expectations is an old marketing trick that helps us with this goal.

THE 3 STRATEGIES OF REDUCED EXPECTATIONS 

1. THE BONUS FEATURES

If your project consisted of say a 10 page website with minimal static graphics; maybe adding a tasteful Flash animation in place of a static image might put a smile on your client’s face. Whatever you provide, it is important that you bring it into the mix after you’ve settled on a price and features – the key is creating that perception of a free bonus.

I used to say something like:

"I was finishing up the site, and I thought that a nice Flash animation would be really effective for your website, so I created something for you. Don’t worry though, I was able to fit it in budget."

The trick is that from the beginning, I already accounted for this extra feature, but just didn’t mention it to my client! So in essence, I created a lowered expectation from the start so that I could ‘in the last minute’, come up with something extra.

2. THE UNEXPECTED SAVINGS

You can apply this same principle with billing: quote higher than what you need and when the project is done, come back with an ‘unexpected discount’.

3. THE QUICK TURNAROUND

Another way to use this principle is with delivery dates. Tell your client it will take three weeks, when you actually know it will take two. Doing this will give you a buffer, just in case something goes wrong or (hopefully,) you can deliver the website that much quicker, impressing your clients.

CONCLUSION

How you use this strategy depends on the project, client and your experience. With time, you will see the pattern where you will lower expectations in the beginning, so you can impress them at some future point. Doing this will help insure a long term relationship with your clients.

This list summarizes my often time controversial positions for everyone to see and attack!

Attacks aside, I felt it was time to come out with a new list of best practices in web design with the aim of making web designers lives a little easier.

THE DO’S AND DON’TS OF PROFESSIONAL WEB DESIGN

1. Don’t use CSS hacks – they will break in IE7.
2. Do use IE conditional comments to write CSS code that only IE will see*.
3. Don’t use XHTML in your web pages because:
• XHTML is not properly supported in IE6, IE7 and some other browser – this makes up about 80-90% of the browsers being used today.
• XHTML is restrictive in terms of:
  1. the tag attributes you can use.
  2. it makes DOM / AJAX scripting that much more trouble.
• Even in a perfect world, XHTML does not provide a significant advantage over HTML 4
4. Do use HTML 4.01 doctype.
5. Do use CMS’, Blogs and web templates as much as possible – saves time and money.
6. Do make your websites accessible.
7. Do use CSS for page layouts if CSS based layouts are NOT a big headache; otherwise use HTML tables.
8. Don’t get fooled into believing that Web Standards based websites will have any practical impact on how well your websites and web design will do in the market place. 99% of the world doesn’t care and even worse – most don’t even know what the Web Standards are.
9. Do break out of the Web Standards if they get in the way of getting the job done – Web Standards are NOT holy scripture.
10. Don’t nest tags too deeply – nested div’s are just as bad as nested table’s.

Notes:

CSS hacks are often used to hide CSS code from IE so that you can manage the inconsistencies between IE’s broken DOM and better browsers like FireFox.

Hacks in a nutshell: you have one set of CSS rules that work for IE and another (hidden by way of CSS hacks,) for FireFox and other more compliant browsers. Using CSS hacks is a bad idea (that should have never been suggested) because they depend on something that is ‘broken’.

As an alternative, IE conditional comments make sense because they serve the same purpose as the hacks: to allow us to serve IE only code to IE, and not any other browsers. In addition, IE conditional comments are a feature of IE and not something that is broken.

ON DOCTYPES:

People have written long blathering articles on doctypes and on which ones to use. Being a practically minded person (who keeps reminding my long-winded father to ‘get to the point’,) I wanted to give people the quick- skinny on doctypes:

What are doctypes?

The doctype is a little bit of code that tells the browser how to read your web pages – it tells the browser which (of its many) ‘engines’ to use. As you may have guessed, we have several options.

What doctype should we use in our pages? Your Options:

• HTML 4.01 Strict
• HTML 4.01 Loose
• HTML 4.01 Frameset

You can cut-and-paste any one of these:

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">

-

Just in case it is not clear, you insert only one (of the doctypes) at the top of your web page. So which one should you use? Use the first one: HTML 4.01 Strict

Final comments:

There are other doctypes but they relate to XHTML … and we know that you shouldn’t use XHTML.

Bye for now.

Stefan Mischook (The Web Heretic)

More and more there are grumblings in the Java community – the language is showing its age and Java nerds are starting to look elsewhere … slowly.

In their search though, I have found that Java nerds tend to ignore or dismiss PHP … instead they look to Python and marginal languages like Ruby as the potential alternative.

WHAT’S THE DEAL?

I have to ask myself, why are Java nerds ignoring one of the most popular languages in the world? Why are they ignoring a technology endorsed by IBM, Oracle and used by Yahoo?

I think much of it comes down to Java elitism and false perceptions about PHP, it comes down to these points:

• PHP is a scripting language that is easy to learn – Java elitism has a natural dislike for anything easy.
• PHP has a procedural history that makes Java users snicker – despite PHP5’s full blown OO feature set.
• PHP syntax can be a little inconsistent at times – this is true.

On the flip side, Java users seem to ignore some very important facts about PHP:

• PHP is ubiquitous. It’s hard to NOT find a host that supports PHP.
• PHP is fast and scalable – Yahoo proves that.
• PHP easy learn, easy to write and is fairly concise.
• PHP has a huge community where there are plenty of open source tools available.
• PHP can be maintainable: there are database abstraction frameworks (PEAR DB), there are templating frameworks, MVC and other frameworks so that you can build maintainable scalable applications in PHP.

One argument you hear from the Java camp is that PHP is a web application only language … pratically speaking. This is indeed the case but what about Java? Most Java projects are web applications, Java on the desktop is but a small fraction of the Java work being done.

Ok, you have cell phone and other small device work, but the fact of that matter is that most Java projects are web applications.

Beyond Java

Bruce Tate wrote an excellent book (’Beyond Java’) criticising Java and speculating on what the next big language will be. Not surprisingly, he spent little time on PHP.

Not to take anything away from the book, it’s really good. Nonetheless, from the perspective of someone who wants to make a living, it only makes sense to strongly consider a language that is so well established and easy to work with.

WHAT AM I DOING?

I think for the time being, when it comes to small and medium sized web applications, PHP can’t be beat. I have hung up my Java-shoes and now look to PHP for any new projects.

Stefan Mischook