Question

So we are having a discussion on the merits of the default generated views in MVC3. It wraps model fields like this;

    <div class="editor-label">
        @Html.LabelFor(model => model.SenderMessage)
    </div>
    <div class="editor-field">
        @Html.EditorFor(model => model.SenderMessage)
        @Html.ValidationMessageFor(model => model.SenderMessage)
    </div>

A coworker says the editor-label div shouldn’t be there. The label element has sufficient semantic meaning. He wants to see it like this:

  <p>
        @Html.LabelFor(model => model.SenderMessage)
        @Html.EditorFor(model => model.SenderMessage)
        @Html.ValidationMessageFor(model => model.SenderMessage)
  </p>

If it were up to me, I’d probably lean toward something like this. (Yes, I know I can customize it with t4.)

<div class="model-field">
   <div class="editor-label">
       @Html.LabelFor(model => model.SenderMessage)
   </div>
   <div class="editor-field">
       @Html.EditorFor(model => model.SenderMessage)
       @Html.ValidationMessageFor(model => model.SenderMessage)
   </div>  
</div>  

Why is the first way better than the second two ways?

Answer 1

Frameworks such as MVC3 try to be everything to everyone. As a result the code they generate often ends up being somewhat over-engineered.

This applies to virtually every framework, CMS and site designer application out there; if you look at the generated code for the vast majority of sites on the web, you’ll see over-structured HTML because it’s been created by a code generator rather than being hand-written.

In many cases it is possible to change the templates or the engines to generate cleaner code, but there are usually good reasons why the generators default to creating the code they do.

For example, consider a site that performs some clever jQuery effects on the labels and fields. Some effects might be a lot easier to achieve with the wrapping <div> elements in place.

The framework designers have taken the cautious approach and over-structured it, because this gives the most flexibility for their end users (ie developers) to work with it in different ways. Cleaner HTML might be nicer from a purists point of view but impact of the additional markup is low, and the added flexibility is a clear win.