Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!

share|improve this question
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 –  jorjordandan Apr 24 at 17:22
    
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 at 11:59

6 Answers 6

up vote 3 down vote accepted

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

share|improve this answer

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.

share|improve this answer
    
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. –  jorjordandan Apr 24 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. –  Snowman Apr 24 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::

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

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

share|improve this answer
    
+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 at 12:57

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.

share|improve this answer
    
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. –  jorjordandan Apr 24 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">
</div>

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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