To the main heading-
Headshot of Patanjali Sokaris

Pondering the universe

Science & technology

Divitis – its overlooked cause

!

Much has been made of the very-unsemantic div HTML tag being overused on the web. Well, it is because of a simple inconsistent choice made very early on.

The block div element, along with the inline span element, was meant to only be used when any of the normal elements were not suitable. So why has it become so ubiquitous to the point of some frameworks having a dozen of more of them nested?

The div is a block element, meaning that it will tend to fill the width of its container. Some other block elements are p, form, li, td and dd, respectively being for a paragraph, form, list item, table cell and definition description. What all except for a p have in common is that they can all contain another block element, and in particular a form. All good so far.

The web is built upon hyperlinks using the a element, and being inline, that can be included in almost any element. Links can include extra data by including query variables in the URL in their href attribute. The limitation is that such variables, while not visible when sent along SSL encrypted channels, can still appear in browser histories and server log files. This can create privacy problems when personal or proprietary information is transmitted. The solution to this is to use a form with input or textarea elements, which are never seen in histories or logs. Again, all good so far.

While encryption was not as extensive as it is now, using forms allowed for more complex data or even files, so forms were required for more than just text.

So it would seem to send information that is meant to be private or non-text, all that is needed is to replace links with inline forms. Now, the most popular element for text is the paragraph p element, so we should be able include those forms in them where we previously had links. Unfortunately, an early decision was to prevent forms being included in paragraphs, even though it was valid within all those other similar text containers. This meant that where text needed to include forms but present as paragraphs, some other element was required, and that ended up being the div element.

So a simple inconsistent choice led to the p element being sidelined in any situation requiring privacy or other complex data transmissions. Bad decision there!

While that decision may have started the ball rolling for the extensive use of divs, there were other influences favouring them. Websites were becoming more complex, and to tame the complex structures involved, the characteristics of elements had to be nailed down precisely, and trying to work that out for all the possible elements, while catering for their inbuilt idiosyncrasies required a lot of experimentation. divs are general purpose elements, so they did not come with any inbuilt functionality, making them a simple building block that once tamed could be used anywhere.

It became the universal building block of the web, and was embedded multiple levels deep in almost every framework and application on the web. They were modified for any use by using CSS or JavaScript. Even though HTML5 brought on board a whole lot of semantic elements, like the article, section, header, footer and aside, few were willing to go about the complete revamp of their frameworks to incorporate them. HTML5 has been around for over 10 years, but while the major frameworks and sites incorporate some of it, there are still copious amounts of divs.

Much of this is due to the complex structures of most sites, as very few are just using the basic semantic structures that HTML5 is designed for. Many sites are a hybrid of information display and interactivity, with many requiring logging in to use them in any meaningful way. This predisposes them to continue to be largely based around divs, with the likes of LinkedIn using them as 11 out of 15 levels of embedding on a normal page. Wix and WordPress sites have divs for the majority of their levels.

What has been available for several years is the ability to just make up new HTML tags, and as long as their names are lowercase and have at least one -, they function just like a span. To make them act like blocks, just requires a CSS display:block rule applied. Many sites are taking this route as if offers the opportunity to name them as semantic elements. Any existing site could replace their divs with them while keeping their current CSS, as long as it doesn't refer to the div tag name.

In designing Smallsite Design, with its public pages being mainly text based, I was determined that the HTML5 semantic elements formed the backbone of the framework. There were divs for everything else for quite a while, but have now been replaced with custom tag names. I still left in the many classes, so that they describe the visuals while allowing the underlying HTML custom tags to substituted with possible newly created semantic tags without requiring changing the CSS.

Until the WHATWG (Web Hypertext Application Technology Working Group) really tries to tackle making high-level semantic elements suitable for framework functionality, we will continue to see most pages built out of several levels of divs. And then there has to be the will on the part of the framework makers to spend their time rebuilding them. Most frameworks are so complex that such work is likely to lead to too many bugs. I think the thinking will be that if they aren't broken, there is no need to do such work just to be using using the newer HTML5 semantic elements.

Links   △Latest articles&β–³
  • β€’What is it about records?
  • β€’Modern technology is fragile
  • β€’Best energy sources
  • Subsite linksβ–³
  • β€’
  • β€’Contact   Policies
  • β€’Categories   Feed   Site map
  • Searchβ–³

    This site does not store cookies or other files on your device when visiting public pages.
    External sites: Open in a separate page, and might not respect your privacy or security. Visit them at your own risk.
    Powered by: Smallsite Design  ©Patanjali Sokaris   Manage\