Remember, the idea behind a pattern like MVC is to make your life easier. If you start ajaxing in static content to ram client side squares into MVC triangles you're not really doing that. We've already got the basics on the front end, like the DOM API that already manages the DOM tree, covered. Use MVC as a higher level layer of abstraction to make code more legible as well as easier to modify and implement. If it's already covered by the DOM API or even JQuery core, you're wanting to implement at too low of a level for it to be more help than hindrance, IMO.
I think on the front end it makes more sense to think in terms of how MVC can be used to apply to types of UI widgets rather than a way to deliver and handle all HTML content.
So imagine a combo box that lazy loads content when you click on it.
So you have a model with methods for communicating with the server to get the data and process it into something that's easy for the view to render. I would stop short of actually converting an array of items into LIs at the model and let the view handle that. The model triggers events when it is finished prepping/updating/processing data.
You have a view that handles rendering/re-rendering of list items inside your combo boxes and it also handles user interface stuff like auto-complete/match in the text box, and triggering app-level (not DOM - it translates those) events when new items are selected or an unloaded box is clicked on indicating a need for new data. The view also establishes context (which combo box is being acted on by a user).
The controller makes the app-wide/relevant decisions. So when a new combo is clicked on, the controller is what tells all the other combos to close. I think there is variation on this but it makes the most sense to me when model and views have to go through the controller rather than listen to or call each other directly.
So a view detects that a new combo has been clicked on and triggers an event the controller listens for. The controller determines that data is needed and triggers an event the model listens for. The model loads in and processes the needed data and when finished, triggers a completed event the controller listens for. Then the controller hands that data off to the view so the view can convert to LIs and drop them into the appropriate combo box.
Now, I don't love this as a triad of objects. It makes more sense to me for there to be a parent combo box object that essentially acts as a controller with aggregate model (if needed) and view/UI objects on the interior. That parent combo box object also manages state and maintains inventory of all the various combo boxes it's responsible for, which was more of a view responsibility in the triad model. What I like about this is that it's easier to make sense out of interaction with other objects and the combo box object itself gets all events pinged off of it, making them accessible to outside interests like a debug logger or other UI widget that needs to react to a combo box selection.
