Heh. I actually thought tyop's post largely missed the point.
I'll apologize up front for what actually turned into a bit of a long post, and a bit of a rant in places. Despite what it's about to sound like, I actually agree with a lot of the stuff tyop had to say. The overriding point of this post is that it's dangerous to get locked into "standards" tunnel vision without taking the chance to think critically about what decisions that road requires taking why we're making these decisions.
It takes just as much time to spit out a grossly non-standard site as it does to generate beautifully valid code. Actually, valid code tends to have more overhead, not less.
This depends, somewhat. If the goal is to reduce load time, you actually don't want to do this at all.
The MVC design pattern exists primarily to solve the problem of writing maintainable code. It allows you to easily swap out your data store, your application logic, and your user interface independently of each other, and to guarantee that a change to one will never break the others. But the isolation isn't free; it comes at a cost of speed and memory because you need to do a lot of data passing to make it work.
Computers are powerful enough these days and have enough memory that the decision to make the trade-off should normally be obvious, but you have to make it nevertheless. There may be situations where another design patten is vastly preferable.
As I load his site now, the thing that takes a long time to load are the images. He has a very graphics intensive site, after all. Improving code quality is likely to do precisely nothing to address this issue.
Well, no matter how the code is written, the images won't be loaded before the HTML that calls for them gets sent to the user, and the HTML won't be sent to the user until the database queries needed to generate that code are executed. Invalid code may be annoying, but it can't break the basic workflow necessary to render a page.
I think what you're really saying is that as programmers we should design all of our database queries to happen before we start generating any HTML. But what if our database work is non-trivial and the feeling of responsiveness to the user is important? In that case, we should probably spit out some HTML up front so that they can see the site do something.
The ancient days of the 1990s, when nobody had even heard of the W3C, and when Geocities and Angelfire wrote the most grotesquely invalid pages ever? Or maybe of the 1980s, when we didn't know what graphics were, and the only "semantics" we ever needed was
? Possibly the 1970s, where we were just thrilled that we could send web pages back and forth at each other at all?
As far as the evolution of the web goes, semantic and design principles are relatively new. Semantics didn't really become a big deal until after 2000. Design patterns didn't mean too much until people started writing web applications rather than merely web pages.
Regardless, I have no idea about the internals of DZOIC, and am not about to presume to based on the DOCTYPE that it happens to spit out (which the w3 validator actually accepts as ok). I doubt the thread starter is really interested in reprogramming this commercial software package anyway.