For example, you shouldn’t use IMG tags but instead replaceable DIVs…
No! Not always - images can be part of the content.
For navigation links and such, yes, use the div background-image property but for a photo (for example), you should defiantly use img tags…
Your web-page should be completely readable with CSS disabled - if you display images via div tags, you cannot see them…
(I’m sure you already know that, I was just clarifying…)
I have to admit, as someone with more philosophical inclinations, I wonder whether the stated goal of totally separating content from representation is even a good idea. Certainly no graphic designer would sign on to that theory of the world, much less a philosophically inclined graphic designer. The world is not actually made up, ontologically, of objects whose logical value and whose representational value is totally separate—they are deeply intertwined.
I understand, of course, the practical benefits from doing such splitting. But I find it quite odd that computer people on the whole seem to think that this approach is a really elegant one. It’s an idea which anyone in the humanities would find amusingly bad, one whose limitations are going to be on display constantly (as an example, witness how much hacky-looking CSS one generally needs to use in order to take a given HTML structure that was set up for a given page appearance to actually make it look totally different).
I’m a big fan of design patterns applied correctly. My framework of choice lately has been CakePHP and I’ve been surprised at the number of places that MVC /is/ a good fit. I’ve found that MVC is a great and widely applicable pattern but it still isn’t a one-size-fits-all. For example, you’re not going to get a lot out of MVC if your application is a virus scanner, a screensaver, a CPU-heavy command-line utility, etc. There may be small ways to apply MVC in those places but you’ll find that you’re twisting the pattern and becoming very fat in one of area - models, views or controllers - while the other areas are basically empty.
MVC doesn’t just have to be forms and responses though, there are a lot of cases where an interactive web application fits very nicely into the Model-View-Controller pattern and the overhead is well worth the cost. If the application scales up a lot then you might need to tweak things and rearrange your framework, but MVC and a good framework are what get you 80% of the way there.
Unfortunately, my only real exposure to MVC so far was via Ruby on Rails… Combine the 2 and you have a real mess on your hands. Sure, the separation of task is great for not breaking functionality, however debugging becomes exponentially harder as projects increase in size. Mostly due to the way Ruby on Rails works (great for quick dirty small projects, but doesn’t scale gracefully), but the MVC model does have some small part in helping to magnify that particular issue…
Is this just another flavor of 3 tier architechtre(interface,business logic,data)?
I’m not sure I understand the overhead argument. How does MVC introduce overhead, even in a small app? Seriously, your data is likely in some kind of structure already so views should be a no brainer. What usually happens from my experience is controller logic gets mixed in with the views.
I tend to find that any application of a sufficient size which is continually evolved in a logical direction will eventually end up following the MVC pattern, or some variant of it.
@Shmork: The total separation of content from presentation as it exists in the Web world isn’t ideal, but that’s largely because neither CSS nor HTML are perfect—CSS didn’t exist for a long time, which meant things got all screwed up. It is, however, considerably preferable to the alternative, as anybody who actively used the web in 1998 will likely testify. HTML was invented to convey information in an agnostic fashion, and styling “layers”of some kind are a perfect fit for that—the issue is the implementation, not the theory behind it.
I applied MVC in my final year project and it helped us to decrease some development time.
My favorite thing about CSS is that you can turn it off. All those news sites with tiny text and layouts that break when you size it up? Boom, disable CSS. All those sites locked to 700 pixels wide on my 1920 pixel width monitor? Again, no way I’m using that CSS.
There are many 3-tiered architectures, but MVC is not [HTML, CSS, browser] nor [interface, business logic, data].
MVC = [model/business logic, view/representation, control/interaction logic]. The design pattern is typically used in rich client applications, not in web sites.
A typical website has the model shared between the server and the client-side scripting, has the representation shared between the HTML, CSS and the UI of the browser itself, and has the control shared between the Javascript in the HTML and the logic of the browser.
This does not mean that the separation of concern as seen in [HTML, CSS, browser] is pointless, far from that. It is just something different.
Proper MVC makes it trivial to have multiple views of the same model, for example two photoshop windows of the same bitmap at different zoom levels.
While this can be done without MVC, putting all your view state in the view code is the straightforward (and correct) solution.
I’m a big fan of MVC, but what I’m having trouble understanding is when to use it and when not to. Rob, I agree with you that its not a one-size-fits-all solution. So when does it make sense to use it?
Ah, the joys of using XAML for markup. This sort of thing is easy then.
Skinnable apps are awful though and should never be encouraged.
To me the key idea of “MVC” frameworks for the web is to separate the code that processes form input from the next page that gets displayed: the form processor gets to decide what template is used for the next page and passes variables to it to fill in various slots.
I’ve been working with ASP.NET lately, and in a lot of ways it’s a really great system. Yet, the Web Controls have a poorly conceived “viewstate” mechanism that’s incompatible with the ability to display different forms depending on the results of the processing the first form. (Not to mention incompatible with the back button, etc…)
Java Server Faces have a similar problem. There’s a strong need for a web widget set that makes it itrivial/i to implement data validation, multi-part forms and other things that are tedious in conventional web apps.
m = xml,
c = xsl,
v = html+css+js, html, wml, audio, etc. 
Mike
Before everyone starts commenting on writing hacky CSS and having to bend the HTML ‘model’ to suit the CSS ‘view’:
Yes that happens, but it is a failing of CSS (and particularly in poor browser support for CSS features) rather than a general failing of the Model/View/Controller pattern.
A litmus test I keep in mind while designing is if I can substitute something other than a standard web page for the view; like a mobile browser view, or even a desktop app gui or command line.
The power of the pattern is apparant to anyone who has needed to write an app that works on the browser and desktop!
For niyaz pk and others who think MVC must be large and cumbersome, I’ve implemented the smallest useful subset of the MVC model as a “framework” in a single PHP file of 30 effective codelines. 
And I have actually used it for several procjects, some larger than others.
This comment is little off to the tangent but I hope you have IE6 available on your machine because you want to test websites. And you don’t use it for everyday browsing. (else my respect for you as a cutting edge geek will drop 10 folds…)
This is a very good method of design, but for some programs it just won’t work without making everything a bit harder than it needs to be. Consider a simple task oriented web service. There’s no real front end, besides a SOAP of XML transaction acceptor, so abstracting out the “front end” would be utterly pointless, unless you just want to have your program structured that way.
All in all though, it is a very good design theory.