Allow me to ask you a few questions then. Are you still coding the same way now that you were when you first started? Or are you continuing to push the boundaries of what you believe is possible with Web standards based technologies such as HTML, CSS, and JavaScript?

Are you willing to embrace new ideas and ways of doing things, or are your coding practices so set in stone that you're unwilling (or able) to adapt?

The reason I ask is because if you're still coding today the way you did in 1999, then you should expect to have to check and recheck, plus hack for Browsers X Y and Z (and versions a, b and c of each). Learning how to write standards-compliant semantic code that separates the structure, appearance and interaction as much as possible, while still ensuring accessibility and ease of use, not to mention maximum code optimization for the search engines (you know, "search engine friendly design") will mean you no longer have to check over your shoulder every six to twelve months when a new browser (version) is released.

I'll grant you - it's not easy, and there is a steep learning curve involved. But the rewards far outweigh the risks, especially when money is involved (I've seen sites that were built the way I described far outperform comparable sites that used outdated techniques). As for moving targets, HTML 4.01 has been around for about a decade, same with CSS 2.1 - HTML 5 and CSS 3 are still about a decade away from being capable of real world deployment. And you know what else? At least with HTML/CSS/JS, I don't have to worry about browser plugins determinig whether I can even access the site or not - the content is always available to me. Can't say the same with Flash/Silverlight and other technologies that require plugins (and still depend on HTML for delivery).

Sure, /if/ your content is the type that can be presented in a text-oriented, page-by-page manner, then creating simple, barebones HTML pages is smart coding.

Actually, that's not the case. It's just a matter of using markup to structure your documents, and then letting CSS handle the display. That doesn't mean you can't use sticky footer techniques (like the one Paul O'Brien uses on SitePoint), Gilder/Levin image substitution techniques, or even advanced floating methods that literally rearrange the content so that you have floats on one part of the page floating underneath content on another part of the page even though there's another content block (or three) in between them.

And yes, I am aware of issues that plague even the most advanced designs; and how sometimes you have to use hacks to compensate for the failures of a browser (not just IE, but Firefox, Opera, and Safari/Chrome as well) to render things properly. (Don't believe me about Firefox? Look up Bugzilla 915 one of these days.)

But every design has its limits. Try pushing at the edges of HTML, and it gets painful, fast. On one project I audited, we were spending 75% of our coding time on browser workarounds.

Given that I've been doing this since 2002, I should know that every design has its limits; it's a limitation of the medium, not the languages used. As I tell everyone, HTML is for structure, CSS is for presentation, and client-side scripting is for behavior. While there is overlap between the three (as there should be with any healthy symbiotic relationship), they do have their own jobs and when used properly, they can achieve results that would otherwise be impossible with HTML/CSS/JavaScript.

But I'm one of those people who debugs as he goes along in all browsers - first with the HTML to ensure that the markup is structurally sound, then the CSS to ensure that the appearance is practically the same in all browsers made in this century (I'm a user-centric developer who prefers to put the people who will use the Web site first, rather than a designer's ego - but that doesn't mean designs can't look great while working well), and finally the scripting (script by script) to make sure that nothing's broken there either. Taking that kind of approach allows me to reduce the time spent debugging by nearly 95%. I've also found that most of the problems I have (and this isn't true for everyone) will be in the HTML itself, and that by modifying the markup slightly I can get it to work in all browsers, rather than piling on hack after hack after hack that I have to check again and again whenever a new browser, browser version or layout engine is released.

Oh, as for pushing at the limits of HTML? There really aren't any limits if you use it as a structural markup language because of the rules in place. The real limits to be pushed are with CSS and JavaScript - that's where the real magic is.

Switching to a RIA was a huge time-saver. At the edges of user interface design, HTML compatibility is thoroughly broken.

At which point I would dare say you're not creating a Web site, but an application. Two completely different environments (with their own sets of rules) co-existing in the same medium. (As someone who once had to make a Web site look 100% identical to a Flex app in all browsers, I should know.)

However, your instinct that the simplest designs are usually the best is spot-on. This is exactly kind of back-to-the-basics thinking that is behind REST, Atom, JSON, and other web-centric techniques.

As I've said before, even rich graphics intensive designs can be done using POSH (Plain Old Semantic HTML). Yeah, you may need a few container hooks, but given that multiple backgrounds and other CSS3 properties aren't properly implemented in all browsers yet, I can live with it for now. (Though I don't know how much more I can take - I want my CSS3 fix now, damnit!)

Saying that a student's odds of being elected President are so astronomically high that he might as well invest his or her time in something less harmful (like banking, or becoming an attorney) is one thing. Saying you're not even fit for janitorial work or flipping burgers is another thing entirely. The simple fact that I get to choose my own hours, decide whom I want to work with (even though they by default become my bosses for an agreed-upon amount of time), and set my own rates without much difficulty or fear of a prospective client saying "No, I'll go to the 'guru' who can do the same job at 1/1,000th of the quality for only a dollar a day*" strongly indicates that the counselors, like many other people in my life, were in fact wrong . (* Especially when they realize it's far cheaper to hire me at the start rather than once their "guru" has screwed everything up so badly that I have to come in and fix everything.)

Welcome to the painful reality of SGML being so lax in its rules enforcement. If only SGML would stop invalid code dead in its tracks rather than allowing the browsers to not only parse but render invalid code as Web pages, then we'd be able to get somewhere. Of course, that would make HTML so "complex" and "difficult" that only those with computer science degrees (or the patience of Mother Teresa) would be able to actually author pages in HTML to begin with.

It's in all browsers, and for Ghu's sake, we shouldn't have to switch to the new (and painfully slow) comments system to "fix" the problem.

Fair shot. I'm self employed, and I spend my time helping other Web professionals and enthusiasts on forums such as SitePoint (where I volunteer as a community Advisor), SEO.com (as an administrator), and newer communities such as LovingTech.net (yep, I'm a moderator there, too). What sucks for me though at the moment is that I've spent the past six months watching my mom waste away due to the lack of proper health care from one doctor after another (and that's despite having health insurance). Right now I've got three really wonderful clients that I'm working with, and am about to pick up two more (I'm very picky about the clients I take on - I prefer to work with those who are willing to work with me, rather than those who kick the tires and want to buy oceanfront property in Arizona for a nickel once global warming has had its way and finished redrawing the map). Not bad for someone who does all the work himself (and spends his time helping others with their own sites instead of working on his own). Of course, I could be doing something more productive, like cutting up a fish to illustrate how Congress wastes our taxpayer money.

In this day and age, you don't need to know good html in order to make a webpage. We have WYSIWYG editors. So I don't see why we couldn't have an editor for the canvas tag, that would provide artists with a point and click interface like flash does.

And yet those tools produce more crap code than Microsoft had market share for its Windows operating system and Internet Explorer browser in the first few years of this decade.

Seriously - there's a huge problem when someone can create a Web page with a WISIWYG editor that breaks when a new browser, browser version or rendering engine comes out and is generally inaccessible to people with disabilities while leaving search engines guessing which content is the most important; yet I can create the exact same page by hand using nothing more than a plain text editor and a decent graphics program (like Paint Shop Pro or Photoshop Elements) that works just as well in Internet Explorer 5, IE6, IE7, IE8, Firefox 2, Firefox 3, Opera, Safari, Chrome and other browsers without having to update them whenever a new browser, browser version or layout engine is released - without hacks about 90% of the time for any browser. And that's just for GUI capable desktop clients.

While using only 25% of the code the WYSIWYG editor barfs up, making the site accessible to everyone (not just the disabled), search engine friendly, and able to support up to three times as many people due to lower code weights, fewer HTTP requests needed with every page view, and optimized images (CSS sprites anyone?) - and that's just off the top of my head.

If I can learn how to do that, anybody can. And my high school counselors (not to mention my family and their friends) thought I would never amount to anything.

If that's the case then they should lose their jobs. Putting personal politics above the law is not and should not be a part of a law enforcement official's job description. Especially when it can cost the city/state hundreds of thousands or even millions of taxpayer dollars on unlawful arrest lawsuits that could have easily been prevented had the officers in question shown some self restraint and done their jobs in the first place - and left their politics at the door .