debuggable

 
Contact Us
 

Question: Why should you stick to Web Standards?

Posted on 8/6/06 by Felix Geisendörfer

Note: This is not directly CakePHP / PHP related, but I'd appreciate your comments anyway ; ).

Well, you probably all know a couple of reasons why layouts shouldn't be done with tables, why websites should pass the validator, and why html should be semantic in general.

But be honest to yourself, which one of them would impress a potential client? Very few of them. Most clients won't care how your HTML (CSS, JS, PHP, MYSQL, ...) looks like, as long as the website does what he or she wants.

So my question is: what would you tell a client (i.e. a non web-technology-savy person) to make him pay you additional money to pay attention to web standards?

One thing up front, I saw people / companies advertise web standards work with the argument that it's cheaper, but my personal experience has been, that making a difficult layout work in IE 5.5+, Firefox 1.x+, Opera, Safari (and maybe more) can be really time consuming compared to an table version of it. But now, I have to agree, that once it's done, working with it is easier and faster. But would you really use it as a reason?

 
&nsbp;

You can skip to the end and add a comment.

Felix Geisendörfer said on Jun 08, 2006:

A couple reasons I came up with so far:
- Better for search engines (-> more vistors)

- Faster to load (-> better for people with low bandwidth, like me : /)

- Better compatibility with mobile devices (turn css off, and people can read your page on almost any screen)

- It's like environment protection for the web - don't pollute the world with unessary html

I'm looking foreward to other people ideas ;)

Lucian Lature  said on Jun 08, 2006:

"Beautiful code and design lasts like great pieces of art" ... Because good design means right practices.
I think that the reasons you've came up are enough for a client who wants an online presence.

Oh, the client want for his project to have an ugly code and a bad design?...No problem, you can solve that, but in the end, that app will refflect your work and his image.

For that and for the vanity, most of your clients will choose the right and hard right.

P.S. : any news about that uploader you promised?

Daniel Hofstetter said on Jun 08, 2006:

As you already said: clients are usually not interested in technical details. So don't mention them. Just offer the solution you think is a) good for the client, and b) suits your (development) philosophy.

Felix Geisendörfer said on Jun 08, 2006:

Lucian / dhofstet: thx for your comments ; ).

Lucian: I feel *really* sorry I haven't finished it yet. The perl script keeps driving me nuts, but I really want to use my own perl script this time, because I want clean IP for the project. But I also have to admit that I didn't devote enough time to it, which I'll try to do more in the next couple of days. Sorry my initial time guesses where that far off : /.

sosa said on Jun 08, 2006:

Whith some experience, there's really nothing like "difficult layouts" nearly every site design I have done has the same basic structure and I can reuse my styles every time.

Also, you can offer faster development and very rapid prototyping using your own personal CSS/XHTML "framework". Bakingday, for example, has taken me no much more than an hour and is pretty lightweight :D

spark said on Jun 09, 2006:

i use more than one :
- it's cheaper and easier to maintain,

- it's faster, since the code usually is much smaller (and css is cached),

- it uses less bandwidth , and dependending on the website, cutting hosting costs,

- the website will be viewable in more browsers, gaining visitors for your client's website,

- the search engines get and index better the website, because the semantics are well done, and it's easier to the search engine algorithm find what's the title, the subtitile, what's importan, what's not.

- it's more 'futureproof', since browser upgrades wont break your layout, since you're using a DOCTYPE statement, telling the reader to interpret it on a very well defined way (theoretically, of course).

Olivvv  said on Jun 11, 2006:

Its ready for the very soon future of the web out-of-the-desktop-box. Cell phones, PDA, GPS, Ipod, etc
What If you have to adapt in interface on screens of 200px as well as 1900px ?

Clearly even a good table liquid layout will reach its limits there, while the div-CSS will be adaptable by getting the screensize on the server-side and serving the right css or even with javascript.

Also Accessibility Accessibility Accessibility. It will come some days in the law and then any legit organisation will have to garantee that she is not discriminating disabled persons.

So you can ask your client if he wants a quick website to be used just during a few month and be proud of "having a website", or if he wants to build something durable.

Olle Jonsson said on Jun 11, 2006:

I believe the "cost of change" factor is the simplest and best customer-facing argument. "When we redesign, it'll be cheaper. Even if it is not me who'll do the redesigning. You can pick any web designer to do it: it'll be simpler to adapt when it's based on standards."

Felix Geisendörfer said on Jun 11, 2006:

Olle Jonsson: Yes, that's really a good one, I agree. Redesigning old table websites is a major pain so this should be a good argument ; ):

Olivvv: Good point too. Even so I struggle with with the entire anti-discrimination stuff for blind people. I mean of course you want them to be able to view your site, but why is it discrimination if your site happens to not work with their screen readers? I mean you'd need to suit anybody who's doing fotography, television or other graphic media? But, maybe I'm just missing something ...

spark: Well I'm courious about IE 7 when it comes to future proofness. I could imagine a good amount of sites not to render correctly in it (but in ie 6). We'll see ... ; ).

spark said on Jun 12, 2006:

by testing the beta version of IE7, i didn't had any problem for my websites (few hacks, no use of :after and :before , which, unfortunately, as usual, IE7 will not support)... but, as happened before with IE, a lot of websites will break, for sure... but it's not fault of the standards or yours , or ours fault. it's microsoft's, exclusively.
(blame canada :)

Felix Geisendörfer said on Jun 12, 2006:

spark: All I say that theory and reality often don't match that well, especially if microsoft is involved : p. Otherwise I completly agree ; ).

Tom said on Jun 13, 2006:

Disability != blind.

Proper CSS-based design supports low-vision (magnifiers, not readers; possible high-contrast color schemes), color blindness (the most common "disability"), those with languge/learning/reading difficulty (line length, leading, font spacing, font size). Motor disabilties must be considered when interaction is required; the same with hearing disabilities if audio is a core piece of the site's functionality.

A good design considers these things from the start, and using a standards-based approach is the easiest way to get there.

I'm not saying compliance must be strict adherance to standards, but they do provide a good base.

Also, if one is desiging for any project that receives federal money (in the U.S.), accessible design is not only a good selling point, it's required by law.

Felix Geisendörfer said on Jun 13, 2006:

Hey Tom, thanks for your insightful comment. Yeah I definitly over-generalized things, when I said blind people -, may my ignorance be excused ; ). I will definitly try to pay a little more attention to those things from now ; ). Thanks.

Olivvv  said on Jun 14, 2006:

@Felix
I was making 2 different points.

1. Like Tom's idea, the (obvious) need for accessibility for disabled peoples, which will more and more be requiered by law in western countries.

2. The Design/Semantics separation which makes that a website can be easily redesign. And that's important because in the next years the Web gonna to land on tons of different devices (my claim).

Murfy  said on Jun 15, 2006:

Well, if you start using standards from the beginning, you will get used to it, you won't have to think about it and you won't have to fix anything because everything will be XHTML etc from the beginning. That way it's no effort to use standards, and this way the web isn't filled with crap.

Nate K said on Jun 22, 2006:

Some of what I could say would be echoing what you have already stated in your first post. Another reason is portability. I see a 'trinity' on both the client side and server side.

Client:
1. HTML

2. CSS

3. JS/DOM Scripting

Separation of these three are key if you want to expand/change down the road. Need to make the page look the same on a tiny screen or on a TV? You dont have to spend hours fixing or changing things to see that happen? The three are the same, yet separate. The page needs to work with the semantic/structure HTML - then elements of style are applied to that, and any interaction (unobtrusive) can happen with DOM scripting. Now, explaining this to a client is a little more difficult which is why I often times try to come up with an analogy for understanding.

The benefit of doing those things? Well - most have been listed already

1. Speed. You are using less bandwith by using CSS and not using (hacking) tables for your layout. Less requests are sent to the server. Want a rollover image? Use the 'blinds' with css and you have eliminated the need for 2 images to achieve the effect (And its usable and accessible to all). Cutting down on HTTP requests and unneccessary code helps lean things out.
2. Scalability. If built with separation listed above, its much easier to re-design a site or add functionality. Instead of changing a .psd file everytime something needs to happen, you can update it with CSS and tidy HTML. As things get larger and expand - you wont have to worry about REBUILDING each and every time, you can just grow.

3. Accessibility. As stated above, this does NOT mean blind people. There are many other disorders that require your site to handle them appropriately. Also, it doesn't even have to deal with disorders - it could deal with HOW they are accessing the website. PDA or handheld? 40 inch TV screen? Projector? Screen reader? Audio assisted device? All of these things play great importance on your potential audience. Building WITHOUT this in mind is just plain stupid.

4. Compatibility. Know your medium. This is NOT print design, you cant just design something then spit out the html images in a tabled layout. Thats not a website. Standards are being reached for everyday. Making sure you use a proper doctype and keep your code neat and tidy will help as browsers and standards advance.

5. Exposure. SEO is a big factor here. Especially for smaller sites (maybe e-commerce related). If they need to be found, then their site needs to be built very carefully. SEO is not keyword stuffing, its not creating link farms, it is consciously building your website properly so it CAN be found. Search engine friendly links. Strong content. Using semantic markup (h1-h6, ul, ol, dl, etc). These things will help you rise in your organic rankings.

6. Price. This is probably the biggest selling point. Need an update to your site? Some developers will charge by the hour and take forever to re-output their .psd (or the like) file, and then edit 10 pages to fit it into the existing scheme. Not so with standards based sites. It is much easier to fit everything together and scale - and therefore the price of maintenance costs goes down extremely. So, not only are they saving on bandwith costs - but they are saving on maintenance costs as well.

Nate K said on Jun 22, 2006:

As a follow up example. I have a friend who built http://www.atwoodlakeresort.com. One year later they have changed their menus and information. Now he has to spend countless hours going back into photoshop, re-exporting the menus/rollovers/associated javascsript, then add into EACH page with requested changes. All of this time is being billed to the client.

Now, not only does it take days to get something completed (and the high cost), but the site is table based and literally unusable/accessible to others. The client does not know this, and they are being led down a path by a blind developer. So - they lose all of the above points.

1. Speed. Their website will not load quickly. It is table based and uses images/spacers to achieve the look (which even breaks in some browsers/layouts). The bandwith usage will be high, regardless of traffic, due to all of the separate HTTP requests for everything (including the bloated JS file sent with adobe golive - while only 3 functions are required for rollovers). The code is horrendous and will never validate. Improper markup, invalid markup, additional tags to control spacing. Improper use of CSS - Divitis and Spanitis created from the CSS output from the WYSIWYG.
2. Scalability. With each page change or content addition - every element must be changed at the design level. Back to stage 1. Each update requires a rebuild/compile to get things to work. Content gets longer and the design now stretches - throwing off the navigation and other elements? Back to stage 1 (or use 2 separate pages ?).

3. Accessiblity. Try and view this site without images. Try and view this site in a screen reader. Try viewing this site on a handheld device. How much of your audience are you losing because your website was built improperly? Does the client know and does the developer know/care?

4. Compatibility. This site looks like it was a previous brochure and stamped to a URL as a website. No time or consideration was put into usability or color scheme. The doctype is thrown in by the WYSIWYG, but will not even come close to validating.

5. Exposure. Its tough to find content or keywords when everything is embedded into images. Main navigation and menus - images. Content on the main page - a large image. Rotating text/images - flash. The site is not semantically structured by any means. No lists, no headers, just everything thrown into a table and maybe a span or div here and there.

6. Price. Throw all of the above reasons together, and the client loses - period. They dont know their traffic, they dont know HOW people are using their site. They dont know the potential audience that may have left after not being able to get the content they were looking for. They have to pay a ridiculous amount for the design and update. Scaling the site will cost them much more than if they had built with standards in mind. Bandwith will be a resource hog with all of the requests and large files being requested by the server. No matter how you look at it, the client loses.

* designer source www.celuch.net

Simon said on Sep 25, 2006:

As a graphic designer (who does occasional websites) and not a web designer I see pixel perfect & scalable fluid tables as very useful. I design the occasional websites for smaller companies. Most of these people want basic brochure type sites and as such tables are effective. I realise the code may be slightly bloated, but i make up for this with correct optimising of jpeg or gif images, and that some people may have trouble accessing the site HOWEVER design you site with your specific client in mind either way.

if they are a small company (and DO expect to re-asses their whole web presence in a year from now) and this is their first site then I see no problems with using tables. provided they are clean and well though out to start with.

I am slowly learning CSS but am happy with tables when you can get away with it. (for example) if I’m designing a site for "decorative mirrors" then I’m not going to worry about accessibility for blind people, if I’m designing a site for an "elderly medical based gym" i will not bother with flash or anything that may require the user to install anything (i will make sure that all "alt" tags / page titles etc... are correct and important information is not hidden in an image file.)

My point is that your site design should reflect your target audience, perhaps over and above what web standards suggest. This is a grey issue and i believe it comes down to the particular job at hand.

At the same time i do believe that the web standards are there for good reason and should be adhered to when possible (if you don’t speak css then its not possible is it, if the client is on a budget then I’m happy to give them a cheaper table based website for the interim.) and if they want to cheap out then I’m happy to charge them again next year to redo their website

Think car manufactures, if we could easily redo the appearance/engine of our car cheaply whenever we want, we would never buy another one again, good for the consumer but not for business/industry. You point of view will depend on what side of the fence you are on.

Back to my point. CSS is good but tables are a viable alternative if you know that the site does not require upgrading or being fully accessible and100% compliant. You can get top search rating without using css. you can have accessible pages without CSS.

A bank or search engine or ecommerce or ANY large scale website are all examples where site wide changes and therefore css would be useful and factored into initial cost.

I make all my changes using sitewide using "find and replace" in the code, this works for everything from changing table widths, alignment, font colours, images etc...
I prefer the manual approach as it suits my mind set. too much automation leads to complacency. (use it or loose it....)

Am i a geriatric who should be under a table? maybe, but at least no one will ever be able to hack my webserver, change one css file and destroy the appearance of my whole site. That’s gotta be easier than destroying the layout page by page?!? (yes I’m joking, its not a real concern of mine... but could be for some)

Felix Geisendörfer said on Sep 25, 2006:

Simon, I agree as far as your choosing the right tool / technology for the job argumentation goes. However, this is only saving costs (of education measured in time) by using lower quality (i.e. tables). You come from the print business, and probably make most of your money there. But the only way to make good money from web development as a freelancer is to develop more and more skills in what you do and building business relationships with people who appriciate them. You local mum & pap store might not be the one you always want to target, so if you want to evolve: Don't use table layouts. Otherwise, what the heck to I care ; ).

Simon said on Sep 26, 2006:

cheers Felix, point noted. And your right all im targeting are the little fishies because they like little hooks... I will certainly be learning more about the web industry over time.

Education is the path to enligtenment. While stagnation is a place where you are only affected by gravity. SB

xasoftdk said on Feb 05, 2008:

Thanks to Oprah, Obama camp claims biggest crowd yet

find useful best handheld gps information...

umm it really depends....

Gargantuan  said on Jun 30, 2008:

My biggest problem is trying to get a client to drop flash so that's usually the line of attack I take. I always sell them on deep linking. With link equity being worth more than gold on the internet, building a site in Flash is just throwing traffic down the drain. Then there's the SEO benefits and I use this to argue against using images for text. Plus, it's a boat load easier to build a CMS for a HTML/CSS site and you can offer more features (in less time).

Now there's the iPhone with Mobile Safari and that doesn't have a flash plugin which accounts for a lot of people. But in general, Flash rarely works well on a mobile device, and mobile devices really are the (not too far away) future for the web.

But, sometimes you just can't win. It's then that I have to decide wether or not this client is worth the trouble. And a lot of the time, they're not. My portfolio is worth more than one job. My reputation is important and I like to love my work. So I send them packing and wait a few months until they come back asking me for a site that works.

This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.