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">

was this:

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

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!

  • 2
    Downvoted here, but the tech lead at Spotify and the creator of Modernizr were able to give this question a more reasoned response over on Quora...hmm – Jordan Davis Apr 24 '14 at 17:22
  • 2
    Unfortunately there's a tendency to rate how good of an idea it is to follow the suggestions in a question rather than rating the question itself. I think it's a bad idea for reasons already stated, but I found it to be a well-posed question. If the questioner were supposed to know up front whether something is a good idea or not there'd be no questions on the site. – Doval May 13 '14 at 11:59
  • Thanks, great comment. I agree now that this was not the greatest idea, but I still think it was a reasonable thing to ask. – Jordan Davis Jan 31 '15 at 20:19

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">.

  • Would there have been any problem with the guy who invented "class" specifying that <z:name1 attr1=foo attr2=bar> ... <z/name2 attr3=boz ... </z> would be semantically equivalent to <div class="name1" attr1="foo" attr2="bar">...</div><div class="name2" attr1="boz"> ... </div> but take a lot less time to send over a 14.4K modem? – supercat Sep 10 '15 at 23:11
  • I guess not. But this would just be a different syntax for writing the exact same thing, not improving the concept of <div class=""> by any means. Then again, why define that z:name1 or z/name2 is the HTML tag's class and not its id? And the white-space problem pops up again here. So it would have to be z:"name1 name2" to declare two classes, which pretty much becomes the same thing again. – mavrosxristoforos Sep 11 '15 at 6:05
  • There are lots of syntax possibilities. My point was that in an era where many people were using 14.4K or slower modems, there should have been a form which gave at least some consideration to bandwidth issues. – supercat Sep 11 '15 at 15:34
  • I definitely understand that. As a web developer, I still try to minimize anything to produce faster websites and more. I do believe it is a good approach in many aspects, as it is, though. – mavrosxristoforos Sep 11 '15 at 19:51

We use <div> instead of whatever tickles your fancy because it makes processing and rendering by the browser easier to accomplish.

As a counter-example, XML allows the creation of any tag-name that you want. The ability to create arbitrary tag-names comes with a processing cost. XML parsers have to build a dictionary of the tags used within a document as part of / while it is parsing the document.

By using <div> browsers know that there is a container there and that it can ignore the container or pass it along to some other tool in the chain that may do something with the container.

  • I'm pretty sure that if browsers just used the implied div method mentioned, processing cost would be vanishingly small. And the benefits to read and writability would be huge. – Jordan Davis Apr 24 '14 at 14:28
  • 3
    <div> means less complexity, which is always a good thing. HTML at its core is constructed of two types of constructs: block level and inline markup. Having more ways of expressing the same thing only adds to the mess that is HTML. – user22815 Apr 24 '14 at 14:49

It is a matter of definedness. If using XHTML, which is pure XML, hence fully defined, then you could use your own namespace, here for instance via a prefix q::

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

If you would use XML to convert to (X)HTML you would be entirely free to generate from your free-tag "HTML" real HTML with <div class="hero-img">.

  • +1 for the simple solution. He doesn't even have to include a namespace prefix, and can just declare a default NS for the overall doc and provide an XSLT to transform it to (X)HTML. – DougM May 13 '14 at 12:57

You are suggesting allowing web authors to add arbitrary element names to HTML for private (non-standardized) purposes. This has a big problem: It will make it dangerous to add new elements to the HTML standard, because various authors might already be using the the same element name for private purposes - thereby retroactively changing the semantics of the page. People don't get happy when new versions of browsers break existing web pages, so this is a no-go.

The same problem is with using arbitrary attribute names for private purposes. This is why HTML5 mandates the prefix "data-" for private use attributes, so they wont collide with new attributes in the standard.

Div and span are defined as semantically neutral elements, which means you can use them for private purposes without fear that the semantics will change in future browsers. Sure, it requires a few more characters to add a class name, but forward compatibility makes it worth it.


One of the key elements of HTML is actualy having predefined tag-elements. That's why.

The div class= is a way to get around this "limitation".

And that's why you don't see those "implied" constructions.

  • Tell that to all those Google engineeers defining the new web-components spec... I see what you mean, but ultimately it the next few years there is going to be an explosion of developer generated elements regardless. My idea is just more user-friendly. Point taken though. – Jordan Davis Apr 24 '14 at 14:43

Your own example displays one property why divs are not that ridiculous.

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

You have, correctly, not closed the img tag. Some tags, such as img, br, hr, and others do not have any content, and are therefore not to be closed. The parser knows this.

The div tag, on the other hand, is supposed to be closed, as it contains content. If you just whipped up you own tag, the parser would have no idea if it should expect the tag to be closed or not.

The reason why some elements are to be closed and others are not comes from the SGML heritage, which this blog post describes nicely: http://www.colorglare.com/2014/02/03/to-close-or-not-to-close.html


The purpose of a div element is structure alone. It lets you group elements together under one common element. It has nothing to do with white space, speed, rendering, semantics or anything else. It helps you with CSS in terms of styling and javascript in terms of selectors. If you change it to any other element then you change the purpose.

To create your own named element, as you show, has a problem in that search engines and other tools would not know what your elements meaning had. What is a "hero-img" and how is it different from my "hero-image" and how should my API handle that when I visit your page? How should a browser handle that element? Is it block level or inline? Too many questions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.