DEV Community: Serhii Babich

Mythbusting DOM: Is DOM the same as HTML?

Serhii Babich — Fri, 05 Jul 2024 15:21:03 +0000

One of the misconceptions circulating among the young generation of web developers, and not only them, is the belief that the DOM is actually the same HTML, just in the browser. This misconception is further fueled by the fact that the browser's DOM inspector displays everything within the webpage as the good old hypertext markup, adding more confusion to the understanding of these things.

So, as I loudly declare today: "DOM is not HTML.", the question arises, "What is it, then?" Let's try to figure it out together.

First, let's look at the dry academic definition. DOM (Document Object Model) is a programming interface that allows programs to dynamically access and update a document's content, structure, and styles. The DOM represents the document as a data structure, such as a tree, where each node is an object representing a part of the document, such as an element, attribute, or text content. Does this make a bit more sense? If you answered "yes," then I have every reason to suspect you have a bit of a pedant in you who loved "Legends and Myths of Ancient Greece" as a favourite book in kindergarten. Wait, that's about me... Oh, never mind, let's try to explain it more simply.

Let's imagine that HTML tags are images of LEGO blocks, and HTML attributes in this example are different characteristics of these images: colour, orientation in space, etc. Then our HTML documents are those instruction booklets from which you can assemble what's illustrated, like the Millennium Falcon, and then, if desired and inspired, a deep-sea pterodactyl with a pedal drive and a nuclear warhead in its butt.

And the DOM is what you've assembled from the real blocks, which you can touch with your hands. As in a construction set, each part, a DOM node, is a piece of a complex hierarchy, simultaneously having conventionally parental and child structures. You can imagine this hierarchy in various ways, so for simplification, let's imagine that our LEGO is at least four-dimensional and can simultaneously have both flat and spatial relationships.

Just as you can find the necessary part in the already assembled constructor (well, when you were assembling and realized three packets ago that you missed inserting the green block), you can also find the required element in the DOM. Moreover, you can find many different elements simultaneously based on various attributes, usually id, tag name, class, attribute value, and others.

Moreover, you can not only find these elements but also perform various useful actions with them! For instance, you can replace some blocks with others, add new ones, remove unnecessary ones, and even change the properties of these blocks. In a real constructor, this wouldn't work, but if it did, then you could. After all, we have an imaginary, four-dimensional LEGO, so let it be.

And just like a real LEGO constructor, the DOM can be genuinely interactive, i.e., it can respond to user actions. Just like in those expensive sets where you can assemble a working Lamborghini model at a 1:24 scale, with a beeping horn, a buzzing engine, opening-closing doors, and imaginary cocaine spilt on the passenger seat. I'm talking about DOM events here, not cocaine, but the fact that the DOM can handle events. For example, you press a hypothetical door, and it opens. So it is in the DOM — you press a button, an event is triggered, and you can subscribe to it, opening hypothetical doors. There are many events in the DOM, and all of them are very interesting, and now you can even create your custom events, not limited to standard ones.

So what am I saying? The DOM is not HTML but a completely separate thing that has a whole range of properties unique to it, and thanks to them, we can create attractive, interesting, and diverse web applications.

Mythbusting DOM: Was DOM Invented Alongside HTML?

Serhii Babich — Wed, 03 Jul 2024 07:15:24 +0000

There is a common belief that the DOM emerged simultaneously with HTML and has always been an integral part of web development, with developers having tools for dynamic manipulation of HTML elements from the very beginning. However, this is far from the truth. In reality, nearly a decade passed between the emergence of HTML and the creation of the DOM! How did this come about?

It's undeniable that the web's development in the mid-90s progressed at an explosive rate. Just imagine — only four years passed from the creation of the first web page by Tim Berners-Lee to the launch of amazon.com. By 1996, the internet had become so widespread that the first promotional website for a movie, Space Jam, was launched.

However, web development itself was still quite primitive, with a very limited set of tools that couldn't keep up with the rapid industry growth. Consider this — the second numbered version of HTML appeared in 1995 (there wasn't officially a first version), JavaScript's first version was developed in the same year, and CSS1 was released in December 1996. Amidst all this, the DOM was still a distant prospect.

So what prompted the community to create a unified standard? In the mid-90s, the so-called First Browser War was in full swing, with two giants of the time, Netscape Navigator and Internet Explorer, battling it out. In the fight for market share, developers came up with new tricks and features, exacerbating the biggest problem of the time — the lack of a unified approach to implementing standards. Yes, I'm looking at you, Internet Explorer, and your ActiveX.

As a result, each browser had its own tools for working with HTML, meaning simple scripts for animating snowflakes might not work in a competitor's browser if you only tested your code in Internet Explorer or vice versa, in Netscape Navigator. This could and did lead to unpredictable behaviour, bloated code, and logical errors.

In 1994, the World Wide Web Consortium (W3C) was established to standardize web technologies and make life easier for web developers. One of the key initiatives of this organization was the creation of the DOM, or Document Object Model, to standardize interactions with web documents.

The first version of the DOM documentation was published in 1998, marking a significant milestone in web development history. Finally, a standardized way of representing and interacting with HTML documents was introduced, allowing developers to hope their snowflakes would fall the same way in all relevant browsers. The first DOM became the foundation for modern web applications.

However, this didn't mean all web development problems were solved that year. Rather, they reached a new level. Now, besides incompatibility with competitors, most browsers became incompatible with the standard. Some tried to fix this, some ignored it, and some pretended that the most standard standards were only what they did, while other standards were not so standard. The fact that the famous jQuery emerged only in 2006 vividly indicates that the cross-browser compatibility issue not only didn't disappear but flourished eight years after the DOM standard appeared.

But that's a story for another time.

What is, in fact, HTML and do we still need it in 2024?

Serhii Babich — Fri, 10 May 2024 05:39:16 +0000

The year 1989 was an interesting time. While the Berlin Wall was being dismantled in Germany and Nintendo Game Boy started conquering the world, my beloved Ukraine experienced the first truly Ukrainian music festival "Chervona Ruta", and the "Braty Hadyukiny" released their debut album "Vs'o Chotko", forever changing the songs Ukrainian youth would sing around campfires in the mid-2000s.

Around the same time, a CERN employee named Tim Berners-Lee proposed the idea of a system of interconnected hypertext documents, laying the foundation for what would later become the World Wide Web, giving us all jobs and the ability to access all of humanity's knowledge, as well as pictures of naked bottoms, within a moment's reach.

Mr. Berners-Lee looks at you when you say you don't want to learn HTML
because you know React

To bring this idea to life, Mr. Berners-Lee began working on a revolutionary language - HTML, or Hypertext Markup Language. In 1991, he published a publicly accessible document that described this language, which included all 18 HTML tags that existed at the time, many of which are still part of the HTML specification today.

By the way, did you know that the world's first web page still exists and can be visited at this link? Actually, it's a copy, because the original page was hosted on Tim's own NeXT computer, and to keep access uninterrupted, there was a note on the system unit that said DO NOT TURN OFF.

So what exactly is HTML? It's a markup language. But what do we mark up? And what is markup in principle? The answer, though obvious, is not too simple, so let's try to figure it out.

It is important to remember that HTML was primarily developed for marking up documents. A document differs from simple text in that it serves, so to speak, as a structured container for various information, including text, images, tables, lists, and other types of data compilation. The main purpose of documents is to organize all this data in such a way that it all makes some sense.

And thus, to be able to create documents, there exists markup, which allows separating certain parts of the document from each other and indicating the specific role and meaning of these parts. We can explicitly indicate that this is a headline, this is a section, here's a table, there's a link, and this is a picture of a cat. And in order for the system that processes the document to have some idea of what we want from it, we must have at least two things: a clear set of instructions that we use for such markup, and a dictionary of these instructions, so that the system understands the meanings of these instructions just as we do.

And HTML is exactly that set of instructions (for those who might be interested, this language is based on SGML). And the specification is that dictionary. We can explicitly tell the browser which version of the specification to use for a particular document, and depending on that, the display result can vary significantly.

In general, document markup can perform a lot of tasks. We've already learned a bit earlier about dividing content by role and meaning, but there are other tasks that the same HTML tags can perform. For example, formatting. That is, we can specify not only what to display, but also how, relying either on built-in styles or on our own.

Also, for example, you can store and transmit certain data. This is more related to XML, but in HTML you can do this using attributes. In this way, you can even store some initial or intermediate state that can affect the display of an element.

Also, proper markup is an important part of accessibility — a set of web content development practices that allow users with disabilities to use the web conveniently and effectively. This includes not only visual impairments but also mobility and even cognitive disorders.

And, of course, it allows for an absolute separation of content from presentation. For example, using HTML together with CSS, we can completely change the appearance of the entire document or its parts, without changing the structure of the document itself.

The best illustration of this is CSS ZEN GARDEN — a site that has thousands of faces. Its HTML has not changed since 2003, but during this time it has changed many styles, becoming a kind of challenge for developers who create new, completely different designs using the same markup.

Few or the thousand faces of CSS ZEN GARDEN

Well, well, you might say, we understand what it is, and even what it's for. But where can it be used, this HTML? The first thing that comes to mind, of course, is for developing web pages. But it would be very wrong to assume that its practical application ends there. On the contrary, it's just beginning.

After all, remember that HTML is a hypertext markup language, that is, designed for marking up hypertext documents. It doesn't say it has to be only web documents. Well, not just web documents.

One such case is email. Usually, we use very simple means to format our text, but most email clients understand more complex markup, although if you want to create all sorts of sophisticated layouts, I have bad news for you — you'll have to forget about the benefits of modern CSS and turn to the forbidden dark arts of table formatting.

You can say, of course, that HTML can also be used for desktop development, but this is very, very relative, because, in fact, it's the same browser with certain perks and custom icons.

If we talk about really non-web use, then we can mention the EPUB format for electronic books, and indeed many different formats rely on HTML.

In principle, HTML can also be used in printing, especially if you skillfully use CSS media queries, in particular @media print. This, of course, requires some effort, but I assure you that you can definitely prepare a small book for printing.

Let's turn away from the traditional perception of the HTML document as a document to the current state of affairs. We can see an incredibly diverse and vast realm of user interfaces, with the help of which we can do a lot of different things — click, drag, push, input, open, close, and generally interact in all sorts of ways.

User interfaces can be anywhere, and the ease of launching a web browser on any kind of device contributes to the fact that HTML is spreading to an increasing number of devices. If I were to list everything into which you can fit a screen and a trimmed browser, I would probably run out of character limit for this article.

So let's imagine the most obvious examples where you can meet our favourite language: smart and not-so-smart TVs, car onboard computers, interactive kiosks, self-service terminals, and other devices.

And also... video games. Yup. For example, for Unreal Engine there is a Web Browser Widget plugin that allows you to create a game interface using HTML, CSS, and JS. In general, the soulless machine named ChatGPT tries to convince me that at least EVE Online, Battlefield, and Destiny 2 use HTML to display certain parts of the interface. I haven't found 100% confirmation of this information, but various hints scattered across the internet also indicate that web technologies find their place even in the development of AAA games.

evevision — UI extension for EVE online built with HTML, CSS and JS

In general, HTML remains a constantly evolving living language, not only gaining new capabilities but also getting rid of frankly outdated and unnecessary tags. For example, center and font have sunk into oblivion thanks to CSS, menu and dir have been replaced by the more general ul, and tags like nextid would have made rise a brow even at their time.

On the other hand, modern HTML is enriched not only with new semantic elements but also quite functional ones, for example, dialog for displaying dialog windows. Or finally, support for elements that have been in the standard since 2014 but have just now been implemented by browsers. Well, you know, like finally cleaning up your shed.

Today, there is no way around web development without HTML, and tomorrow — who knows where else this language will become the standard. To some, it seems overly simple, to others — clunky, to some primitive, to others — too complicated. But that does not negate the fact that HTML is the foundation of web development, and without it, we would have nothing to decorate with CSS or animate with JS.

Can you not learn HTML in today's world full of frameworks? You definitely can. Should you learn HTML in today's world full of frameworks?

You definitely should.

Please, strike a comment, either you liked or disliked this article and let me know if you'd like to read such texts on other topics. I would greatly appreciate your feedback!

Thank you and have a nice day!

Accordion Tabs with pure CSS

Serhii Babich — Wed, 23 Jun 2021 14:31:52 +0000

Yep, this is yet another “article” about how amazing pure CSS is, and how you can do something cool without a single line of JavaScript. Why do I bother to write it? Because I am still fascinated by how amazing pure CSS is, and how you can do something cool without a single line of JavaScript.

Before we start — you can find demo of this code hosted here and the code itself hosted here. Feel free to explore and play around!

The final tiny disclaimer: all this is just for fun and to show you how amazing CSS is.

HTML structure

We will use very simple HTML markup to define our accordion tabs:

.tabs-container — wrapper element to host all tab related elements;
input.tab-actor — hidden radio-button to control tab content visibility;
label.tab-button — label linked to input, serving as tab button;
.tab-content — wrapper for any content you’ll feel worth putting into;

The tiniest example ever will look like this:

<div class="tab-container">
  <input type="radio" id="tab-1" name="tabs" class="tab-actor" checked />
  <label for="tab-1" class="tab-button">Lorem ipsum</label>
  <section class="tab-content">
    <div class="content">…</div>
  </section>
</div>

How this works

The main idea is to use a very simple yet powerful ability of HTML form controls to have a state and the ability to access this state with CSS pseudo-classes. Namely, I use :checked pseudo-class here. This means I style adjacent siblings of the checked input using + combinator.

To emulate tabs behaviour, I need to display only active tab content. By active I mean the closest adjacent to the checked radio.

The radio-button also should be hidden, leaving only the linked label visible and interactive.

Long story short, this is how these tabs are intended to work. Let’s write some basic CSS code for the tabs.

Some basic code

:root {
  --tab-button-order: 1;
  --tab-content-order: 10;
}

.tab-container {
  display: flex;
  flex-wrap: wrap;
}

.tab-actor {
  display: none;
}

.tab-button {
  order: var(--tab-button-order);
}

.tab-content {
  order: var(--tab-content-order);
  display: none;
}

.tab-actor:checked + .tab-button + .tab-content {
  display: block;
}

Let’s go through each rule to understand what happens.

First, I create some CSS variables for an order property, and this is what the inside :root rule is. We’ll get back to this a bit later.

.tab-container {
  display: flex;
  flex-wrap: wrap;
}

We employ flex layout. It allows us to use an unknown number of tabs because it automatically distributes its children. Otherwise, we need to put the fixed-width values manually.

By default, all flex items are cramped in one line, but we need the tab buttons placed at the top and content at the bottom. Using flex-wrap: wrap allows flex layout to put large elements to the next row.

<input type="radio" id="tab-1" name="tabs" class="tab-actor" checked />
<label for="tab-1" class="tab-button">Lorem ipsum</label>

We link label to input using id attribute for the input and for attribute for the label. When the input-label pair has the same values of the attributes, clicking the label activates the input as we click directly on the input.

This allows us to hide input:

.tab-actor {
  display: none;
}

Next, we add some black flex magic to get the layout we want.

HTML we have already written results in this:

[tab]
[content]
[tab]

But what we need is the following:

[tab][tab]
[content]

To achieve our goal we should use an order CSS property that orders (no pun intended) elements inside flex layout despite the actual position in the DOM-tree. The following code sets the order for .tab-button elements to be at the start of layout and .tab-content to be at:

.tab-button {
  order: var(--tab-button-order);
}

.tab-content {
  order: var(--tab-content-order);
  display: none;
}

.tab-content is hidden by default. We unhide active tab content using the code:

.tab-actor:checked + .tab-button + .tab-content {
  display: block;
}

It’s a big selector, for sure, but it does all the magic. All content is hidden, and we want to display only the content corresponding to the activated tab button. This selector literally says the following:

Display the content after the button that follows the checked input

+ combinator selects immediately adjacent elements, that’s why the HTML code should follow this exact order.

Another approach is to use ~ combinator. It is also adjacent but not strict and selects all matching adjacent elements. Using ~ shortens the selector to:

.tab-actor:checked ~ .tab-content {
  display: block;
}

Though in this case, the first tab activates all adjacent content. To avoid this, we need to specify which tab displays which content:

/* Don't write code like this. Please. */
.tab-actor.tab-1:checked ~ .tab-content.tab-1,
.tab-actor.tab-2:checked ~ .tab-content.tab-2,
.tab-actor.tab-3:checked ~ .tab-content.tab-3,
.tab-actor.tab-4:checked ~ .tab-content.tab-4 {
  display: block;
}

Not that much optimization, to be honest.

Ok, now we have not that pretty but working tabs made with pure CSS and HTML.

Music time!

Or, to be precise, it’s time to convert tabs into the accordion.
Why?

On small screens, tabs aren’t the best option to display content, and the very layout we tried to avoid at the beginning comes in handy here:

Desktop:
[tab][tab]
[content]

Mobile:
[tab]
[tab]
[content]

All we need is just to revert flex order and adjust the button width to small screens:

@media screen and (max-width: 480px) {
  .tab-button,
  .tab-content {
    order: initial;
  }

  .tab-button {
    width: 100%;
  }
}

That’s it. It works.

Wait! There is more!

It’s all cool and great, but these tabs are so booooring. Let’s glam them up!

* {
  margin: 0;
  padding: 0;
}

body {
  font-family: Arial, "Helvetica Neue", Helvetica, sans-serif;
  max-width: 1280px;
  margin-inline: auto;
}

.tab-container {
  box-shadow: rgba(0, 0, 0, 0.5) 0 1px 2px;
  justify-content: center;
}

.tab-button {
  padding: 8px 16px;
  border-bottom: transparent 4px solid;
  transition: border-bottom-color 0.4s;
}

.content {
  padding: 16px;
}

.tab-actor:checked + .tab-button {
  border-bottom-color: rgb(82, 2, 136);
}

We add some paddings, colours and a bit of animation. Looks great now! Though, as you can notice, content in the “mobile” mode switches dully, without a single spark of joy. Let’s add some sparks then:

@media screen and (max-width: 480px) {
  .tab-button {
    border-bottom: 1px solid #ccc;
    transition: none;
  }

  .tab-content {
    background-color: ivory;
  }

  .tab-container.full-height {
    height: 100vh;
    flex-direction: column;
  }

  .tab-container.full-height .tab-content {
    display: block;
    height: auto;
    flex: 0;
    overflow: hidden;

    transition: 300ms flex;
  }

  .tab-container.full-height .tab-actor:checked + .tab-button + .tab-content {
    flex: 1;
  }
}

What happens here? We add a .full-height class to our .tab-container and sprinkled some fun CSS over it.

.tab-container.full-height {
  height: 100vh;
  flex-direction: column;
}

Right here we tell our accordion to occupy exactly the full-screen height and order all children in column flex layout.

.tab-container.full-height .tab-content {
  display: block;
  height: auto;
  flex: 0;
  overflow: hidden;

  transition: 300ms flex;
}

.tab-container.full-height .tab-actor:checked + .tab-button + .tab-content {
  flex: 1;
}

Now we cast some magic on .tab-content, allowing it to expand and collapse with a neat animation.

Epilogue

That’s, my friends, is how I met… Ah, sorry, it is how we can make responsive tabs that switch to the accordion layout on the fly without a single line of JS.

Edited by @Ulyanka_A