debuggable

"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?

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.

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

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).

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.

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."

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 :)

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
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).

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.

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.

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

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)

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

Thanks to Oprah, Obama camp claims biggest crowd yet

find useful best handheld gps information...

umm it really depends....

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.