HTML – Why Use Divs?

htmlhtml5

This morning, as I was writing some html and haml, it occurred to me that the way divs are used is ridiculous.
Why are divs not implied? Imagine if this:

<div class="hero-img">
   <img src="http://whatever.com/this.jpg">
</div>

was this:

<hero-img>
   <img src="http://whatever.com/this.jpg">
</hero-img>

If the "div class" portion of the element was assumed, HTML would be more semantic, and infinitely more readable with the matching closing tags!

This is similar to HAML, where we have:

.content Hello, World!

Which becomes:

<div class='content'>Hello, World!</div>

It seems to me the only thing that would have to happen for this to work in browsers is that the browsers could start interpreting every element without an existing html element definition as implying <div class="<element name>">.

This could be completely backward compatible; for CSS and jQuery selectors etc, "div.hero-img" could still work, and be the required syntax to select the elements.

I know about the new web components specification, but that is significantly more complicated than what is suggested here. Can you imagine how pleasant it would be to look at a website's source and see html that looked like that?!

So why do we have to use divs?

If you look at Mozilla's html5 element list, every element has a semantic meaning, and then we get to <div> and it says:

"Represents a generic container with no special meaning."

..and then they list the arbitrary elements they are adding to html5 like <details>.

Of course, if this concept of implied divs was added to the html spec, it would take ten years to become standard, which is a million years in web time.

So I figure there must be a good reason this hasn't happened yet. Please, explain it to me!

Best Answer

Problem 1: White-spaces

I believe that this hasn't come up in general. Although, one good reason that this hasn't and probably shouldn't happen is because white-spaces in CSS classes define multiple classes for the element, while in HTML they define attributes.

Explain (or ask a browser to parse) the following code:

<pet family style=" ... ">
  <img src="my-pets-family.jpg"/>
</pet family>

Is family the definition of a second class or an attribute to the HTML element? As you probably see from this site's parser, it thinks it's an attribute.

So, if I want <div class="pet family">, there is no way to actually define two classes, which is one of the two main reasons that I would use a class instead of an id, anyway.

Problem 2: Forward compatibility!

Using <div>s at the moment, forces us (at least some of us) to properly indent and comment around our code, which is a good practice for all programming languages.

Instead, turning HTML blocks into variables would cause big confusion to new programmers as to what is and what isn't doing something specific in HTML.

Also, it will cause the funny side-effect that you should start comparing your old code against new HTML5 tags, just to make sure that they didn't come up with the same name you did for your div's classes...

Same problem applies to variables using reserved words in some languages. PHP solved it with a dollar-sign, so a similar approach in HTML would result into something not much better than the current usage of <div class="something">.

Related Solutions

Javascript – The Box Model: Internet Explorer vs. W3C

The choice whether to include padding and border into the width or not was arbitrary. The only thing where it mattered was building multi-column layouts. However, you should pay into account the fact that people used tables for layouts at that time anyway. So to them that concern didn't seem important enough and they considered that being able to specify the exact width that the content itself would occupy in CSS seemed a lot more valuable.

For today's developers the situation seem totally different as they use CSS for layouts and they have to deal with CSS boxing model. Thankfully we've got an ability to override boxing rules so in most cases simple rule at the top of your stylesheet works fabulously:

* {
    -mox-box-sizing: border-box;
    box-sizing: border-box;
}

To quote Jeff Kaufman on the subject:

Given that the spec defined it the other way, though, the signal it would have sent to Microsoft to adopt their misinterpretation would have been bad for the web. Microsoft was already using an embrace, extend, and extinguish approach, where they intentionally made products that acted differently from competitors' in order to lock users into the Microsoft versions. They came very close to succeeding with the web: from approximately 2000 to 2005 IE was so popular that many sites designed just for it. Adopting IE's approach here then might have told Microsoft "you can do whatever you want with IE and we'll adjust the standards to make it legal".

So box model fell the victim of power-struggling between W3C and Microsoft.

CSS – Using Context-Based CSS Class Names

Yes. Definitely valid advice. CSS classes, for the most part, should not be tied directly to what they look like. Tie them, instead, to what they mean.

If you're using .blue to provide emphasis, and your site design changes so that you no longer want your emphasis to be blue, then you have a disconnect between the display of the element, and the class name.

If, instead, you used .emphasize, you could change the color in the CSS, and the HTML attribute would still be meaningful. You get the change without having to touch the HTML (or, in this case, you could style the em tag, and get even better semantics in the HTML).

In addition, it makes your CSS more readable. When you're changing .blue, it's not obvious what elements on your page you're changing. But if you're changing .emphasize or .pull-quote, you can immediately tell.

There are instances when non-semantic class names are unavoidable, but this is mostly when creating generic layout. Things like column or column-left or half or third are necessary in grid-based layouts.

So, my opinion is that layout doesn't need to be semantic, and usually won't be. But content should definitely be semantic. Ask yourself what your content is, and make the class name represent that, so it can be used in a meaningful way.