13

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!

Improve this question
1
  • There are actually two non semantic container: div and span
    – Lie Ryan
    May 28, 2019 at 11:31

8 Answers 8

Reset to default
7

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

Improve this answer
4
  • 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, 2015 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, 2015 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, 2015 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, 2015 at 19:51
5

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.

Improve this answer
3
  • 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, 2014 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, 2014 at 14:49
  • "makes processing and rendering by the browser easier to accomplish." This isn't really true. Browser are required to parse unrecognised tags, and all the DOM methods and CSS selectors still have to work on them as you expected them and browsers will still apply CSS to unrecognised elements. The only thing that the browser don't do with unrecognised tags is apply the default styles (user agent styles) and behaviours.
    – Lie Ryan
    May 28, 2019 at 11:52
3

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.

Improve this answer
2

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

Improve this answer
2

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

In some tag a namespace attribute with your own (dummy) URL:

xmlns:q="http://..."
Improve this answer
3
  • 1
    +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, 2014 at 12:57
  • 1
    XML namespace isn't defined by the prefix, but by the value of the xmlns declaration of that prefix. q here is an entirely meaningless prefix (and is invalid XML) unless you have declared the the xmlns somewhere in the document. You can also redeclare the same namespace with different prefixes or set the default namespace for a certain section of the document, and as long as the xmlns values are equal, those differing prefixes are going to be treated equally when applying CSS or in the DOM.
    – Lie Ryan
    May 28, 2019 at 12:35
  • @LieRyan a good point. I should have mentioned it. Assumed the fact was known. Added
    – Joop Eggen
    May 28, 2019 at 13:02
0

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.

Improve this answer
1
  • 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, 2014 at 14:43
0

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.

Improve this answer
0

Generally, div tags are useful for applying division or section in a web page. You can use a div tag as a container in which other elements can be applied. It will also help in applying CSS and some scripts on a particular element.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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