OffTopic: Would you consider HTML + CSS + Webserver to be MVC?

Question

Hi all, these are just my wonderings and I thought I'd share them...

Simply put, MVC is the pattern for separating contents (model) from presentation (view), and having a mechanism in place (controller) defining how to gather both.

If you already see where I am going at, I am very interested to hear your opinion on the matter. Of course, MVC applies to serverside mechanics and all, but think out of the box here with me for a second.

"Visitors" of the web, both human and robot/Google will be likely to see HTML and what comes with it. Writing structured and meaningful HTML, together with separating it from presentation using CSS has become more important over the years, and future technology such as HTML5 only contributes to this separation by offering a more content-focused set of elements, and mechanisms for working with the pure visual representation.

Considering all this, I was wondering if it would be correct in some way to say that the MVC paradigm applies to the front-end as well, where:

• The model would be HTML, as in the pure httpwise contents that it has become
• The view being CSS; it makes your content be presented a certain way
• The controller being the webserver and all that lies underneath, it is what gathers and separates the model and view, and does all the decision making

Makes sense? Not?

Thanks,

Martin

Update: VonC pointed me to an article that definitely changed my thoughts on the controller part. The browser takes up a major part of the controller too, as it handles a great deal of user interaction and how the model and view work together.

Answer 1

I would agree, although one can argue about the controller.

Jeff illustrates that point in his post, with ZenGarden

With:

• Model = HTML
• View = CSS
• Controller = Browser (which is more 'front-end' than the web-server)

Actually, this is a valid perspective from the client-side.

From the server side (a server more complex than a simple html-page server), MVC would be different.

With ASP.Net for instance;

• Model = all of your application logic that is not contained in a view or a controller. The model should contain all of your application business logic and database access logic. For example, if you are using LINQ to SQL to access your database, then you would create your LINQ to SQL classes (your dbml file) in the Models folder
• View = HTML markup and content that is sent to the browser, plus scripts
• Controller = responsible for controlling the way that a user interacts with an MVC application. A controller determines what response to send back to a user when a user makes a browser request.A controller is just a class (for example, a Visual Basic or C# class).

That is a services-ide perspective of MVC

Answer 2

CSS is definietely not the view. Rather the rendering by the browser (which combines HTML/DOM and CSS input into a 2d layout) is the view. The HTML/DOM is the model. The controller is halfway built into the browser UI, but can be extended with javascript.

It is true that CSS is considered the presentation layer when talking about the content/presentation seperation - however that is a different (orthogonal) model.

In MVC, CSS is part of the model along with HTML/DOM because it is the underlying data which can be rendered in different views. For example, a print layout is a seperate view based on the same model.

Answer 3

No, sort of...

Your HTML is also at your presentation layer (View), although your CSS should contain the presentational specifics like fonts, colors etc.

Your Model must contain your data + business logic, and I really don't hope that you'll want to store these in HTML - that's for real programming languages, stored procedures and a DBMS to handle. And these should be at server side.

But to follow your line of thinking, I would suggest:

• Model: Server side programs + DBMS
• View: HTML+CSS
• Controller: Webserver

Answer 4

I can see your point, but I think I would describe HTML-CSS-Server/Browser more as Document-Viewer rather than MVC. If all of the content is static then it is an expression of the model, true, but the model is embedded in mark up. Even though I can override it with CSS, CSS is really just a filter on the underlying presentation described in HTML. The HTML describes a view of the data as well as the data itself. To wit, I can turn off CSS and I still have a view of the data. In MVC, this is not possible.

There is also a close coupling between your HTML and your CSS -- both need to be very aware of the other. This violates a key paradigm of MVC where the components are loosely coupled. In particular the view enforces no constraints on the model (other than the restriction that the data be viewable). HTML designers are constrained to operate within the domain of the CSS or to modify the CSS to make it applicable to the domain of the HTML.

Further, HTML has no way of operating on the data to make persistent changes. A key aspect of the model is the ability to enforce business rules. HTML does not do this with static content -- the web designer does by the choice of the HTML encoding.

This doesn't make it bad, or not useful. Not everything has to be MVC. MVC simply describes one particular way of organizing your data and code. It has some particular advantages with respect to decoupled architecture and testability, but that doesn't mean that it is the only valid architectural pattern available.

Static HTML content, in my opinion, isn't MVC and doesn't need to be.

[EDIT] I am not arguing that you can't use MVC in the design of a browser, or that MVC isn't applicable to the the display of static content in a browser. I'm really looking at this from the perspective of the content provider, not the browser programmer. MVC could be a perfectly logical choice for browser design.

Answer 5

You can generally find MVC in anything if you look hard enough.