Web Standards are for web browsers and not web designers.
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:
- CSS for layout is not intuitive at all. Since when is: ‘margin:0px auto’ intuitive for creating center aligned layout.
- CSS is buggy and inconsistent between browsers.
- 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)
December 30th, 2005 at 10:02 am
As a web designer seeking to expand the use of standards-compliant code, I must say that I respectfully disagree with you opinion. When I write CSS driven layouts, and compare them to similar layouts that were done with tables, I find that my source code is quite a bit more readable. Also, if you work with CSS all the time, the ways to get your elements to do what you want becomes intuitive.
To address another of your points, it does take longer to get layouts looking the same in IE and Firefox with CSS, but I don’t think that you should sacrifice quality in order to achieve speed.
Finally, I believe that by having web designers write standards-compliant pages, it will force the browser programmers to actually live up to the standards that are set forth.
December 30th, 2005 at 10:19 am
[...] Web Standards are for web browsers and not web designers [...]
December 30th, 2005 at 1:13 pm
Hi Nick,
I appreciate your comments. That said, I think it comes down to perspective to a certain degree:
I am a real-world oriented person who feels that you should be responsible to the client and so time should not be spent on evangelical/grass roots pursuits, in this case, trying to convince browser makers to finally adopt the web standards.
About layouts:
I can write easy to read code that uses tables … table based design becomes cluttered when you start nesting tables. But the same could be said for div tags.
That said, I will concede that table based layouts are a touch more verbose than using div’s for page structure. But that does not make tables wrong; the W3C is on my side on this one because they have an official CSS tables specification that looks a lot like HTML tables - so verbosity of code is not the concern.
Check out my article on CSS tables:
http://www.killersites.com/blog/2005/what-are-css-tables/
Interesting point: many times, I find that CSS based layouts pull the complexity out of the HTML and simply places it in the CSS file. Some style sheets are pretty hairy …
-
I don’t buy the code is heavy argument; images make web pages heavy, not code. Being concerned about the weight of your code is like being concerned about the table-spoon of sugar in your coffee when you go to McDonald’s and order a super-sized Big Mac Trio.
The examples used to show how code bloat will cost you bandwidth is not honest … the examples are of worst-case-scenario websites that have massive traffic.
99.999% of websites would not be subject to code-bloat issues simply because they don’t get 10 million visits a month and because hosting/bandwidth is so cheap these days - it is rare that websites come even close to their allotted limits.
January 13th, 2006 at 8:41 am
[...] E com isso, sinto-me na obrigação de concordar com esse cidadão: web standards são para browsers, não para designers. Enquanto 90% do mundo ainda usar o IE6 como browser padrão, não há razão alguma para querer forçar o uso de designs sem tabelas só porque o pessoal da W3C assim determinou. Esperem os browsers serem compatíveis com Web 2.0, e aí sim comecem a desenvolver sites dentro dos padrões. Economizar-se-á tempo e dinheiro de todos os envolvidos. [...]
January 13th, 2006 at 9:01 am
Nick writes:
“Finally, I believe that by having web designers write standards-compliant pages, it will force the browser programmers to actually live up to the standards that are set forth.”
This kind of thinking is great for the “purists” that build personal homepages, but my client is paying me to create a website that his clients can read and navigate through and ultimately buy something. If my client is using a browser that does not properly display the “standards-compliant” website that I just built, do you think I will still get my final payment when I tell him that I am trying to “force the browser programmers to actually live up to the standards that are set forth.”
Trying explain to a client that knows nothing about creating websites why a site needs to be created for different browser resolutions is hard enough.
The client is thinking about his or her bottom line and certainly not about whether or not browsers are standards compliant.
January 13th, 2006 at 11:45 am
Thank you!
CSS is merely a tool to use in conjunction with reliable, predictable, intuitive HTML!
I have been building websites for over 10 years now (big sites I’m sure you’ve been to) and when you’re given a design for a site, and your finished product needs to be pixel-perfect to that design… CSS is not going to give you the flexibility to do that!
Sacrifices will have to be made to meet your precious “standards” and these sacrifices are what drive decent designers away from designing for the web.
If new web designers took a little time to learn the traditional method of building sites, they’d be amazed at how everything JUST WORKS!
January 13th, 2006 at 1:32 pm
I have designed sites both ways, and I personally prefer CSS, despite the weaknesses you have mentioned (some of which aren’t really weaknesses). This said, I’m not going to rip on tables-based design. Rather, I’d like to defend CSS against some of the misconceptions that it suffers from.
Table-based sites will continue to be supported because they’re based on a stable, mature set of html tags. Many people have learned how to build sites using tables and are comfortable with that. Unfortunately, the code (and the numerous image slices and the blank spacer divs that go with them) IS heavier. More image slices = same file size but WAY more separate requests to the server. This doesn’t mean that tables are a bad solution. If you can meet client expectations using tables, then they are the right solution for you and your client.
CSS- and web standards-based sites are a very, very powerful way to build sites, as well. I will concede that they aren’t always ultra-intuitive, and there are certain things that are hard do do with standards-based sites, but that doesn’t mean they’re any worse than tables. What’s intuitive about blank cells and spacer divs? How easy is it to sort through the code, or make site wide changes? Both methods have their problems–web design is a complex thing.
Nested divs ARE better than tables (where it takes a table, tr, and td tag to get a single cell and where tables inevitably get nested).
The separation of content from structure is the major benefit of CSS, and it’s not just a browser compatibility issue. It’s way, way better to use a single style sheet to change all headers of the class “highlight” than it is to hunt through every file to change color=”#fa34b2.” You can make two columns switch places with an edit to one file and without having to edit a single source code page. Moving the complexity to a SINGLE file is much better than having EVERY page be complex. Especially since the coder will be using the CSS and the client will be editing the source (if anything), by and large. You want the client’s job to be simpler.
Accessability, especially for the 8 to 10% of the population that counts in some way as disabled, is even required by law in some countries. Putting the content in the code in a comprehensible order is a major contributor to this, and tables just can’t do it as well.
Pixel-precise layouts are possible, and just as easy, with CSS. I do it for a living.
Even though some hacks have been used, when a browser correction comes along, it takes an adjustment to a SINGLE FILE to fix. Search and replace on the hack, and tada, you’re done! And there is PLENTY of CSS (the vast majority) that is already supported by every browser after NN and IE v4 (which came out nearly a decade ago!). The conditional comments fix is promoted by the web standards camp, too, so it’s not like the tables-based people have some knowledge that they don’t. It’s also possible to build sites without any hacks. I build CSS-based sites for commercial clients without any hacks.
So, there you have it–there are ways that each system is superior, and all these rabid opinions are usually based simply on which system a person learned first. That’s why there’s this big debate going on–people aren’t stepping outside of their own boxes to understand their peers in the other box. Now go and design GOOD sites, however you do it.
January 18th, 2006 at 9:00 am
Great article, I agree with the title completely.
Debating to use Tables or CSS is like deciding between PHP or ASP, they both have their place in design. CSS purists should put tabular data in tables, and all tabular designs probably have external stylesheets. Our clients are happy as long as the content gets to the user. And as long as I can go to sleep proud of how my site looks after thoroughly testing it in different browsers I am happy too. Don’t sweat the details, just make cool sites.
January 20th, 2006 at 1:50 am
hey guys,
i’ve been listening to all these sorts of comments you put across but somehow let’s face it, there is a problem! Like some have said, the fact remains: the client wants a job done irrespective of the constraints we, web designers, face. Like this issue of managing slices, esp in the instance you are dealing with many of them, so that they remain in the place i.e. as you want the design to look.
css comes in handy(well at least for those who needed to achieve the desired look) when you want to keep the fomat of the design, color, etc. for ex.,when designing using fireworks and export to dreamweaver, and keeping the chosen color in mind(e.g black), you likely to use textboxes. the easiest way to have a good look of the page is by applying css style to make the page look good and make some color changes as inside textboxes we see a white color. Now what do you think if you use more than 5 textboxes?
as for tables, using the same programs mentioned above(firewoks and dreamweaver as an example), to manage the slices is a real task(i dont know if you too have had a same problem). Now i think a fireworks-made table when exporting can resolve the problem though the next challenging thing has been editing in dreamweaver esp. adding content like text and at the same time not extorting the design. It’s hell for a 1 year old designer compared for those who span 10 years. so, what would be your advice? I’d appreciate if anybody who knows better could tell the solution. Thank you.
February 25th, 2006 at 6:44 am
As a designer currently trying to update a working website that I have inherited, I have been looking to move from the html table layout to using css to make it forward compatible, but as the comments say at the end of the day what I need to produce NOW is a working cross browser compatible website and of course the client wants it yesterday….hmm well for the time being I will update the html I have and wait for everyone else to get their act together and I mean together
As for css being intuitive, sorry who was it that said that?
Thanks to Steve Putala for his advie I am now going to stop stressing about it, make it work and look good and sleep at night.
January 11th, 2007 at 2:01 pm
First of all I’m a CSS designer so I’ll be defending my tool.
I agree to the point that CSS is not intuitive and sucks for layout. But Tables are much more worse and between the 2 I’ve choosen CSS.
Tables are for Tabular data and CSS-P gives you freedom to explore and change layouts more easily and if you look to a HTML page with CSS-P design you will see a very and understandable basic code an not TR and TD across everything.
CSS-P allows a perfect (99%) cross-browser solutions with small not hacks but redundant code. This is bad, yes but it’s needed to adjust between browsers (with IE7 will be less needed). But I consider that using Tables inside Tables and spacer as hacks and much more troublesome to use.
But for sure that CSS-P needs to improve a lot (CSS 3 is still in definition)
August 26th, 2007 at 9:08 am
[...] I guess browser wars would never end, as long as new web technologies are introduced. Agree or not, browser makers aren’t caring about standards, they just keep on modding their toys with some new gadget to bloat they are the king. This one of the reasons, why Web Standards Suck(this guy expresses this better than me, but on an XHTML page?? ). “There is no true standard for anything on the web. It’s not possible to write a ‘valid’ XHTML document. Whining about invalid markup is whining. All extensions are valid. Microsoft wins. We all lose.” -Jodawi [...]
September 29th, 2007 at 2:59 pm
“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.”
you right!