Tag is not an Element. Or is it?
It’s interesting how widely some misconceptions spread around. The one I noticed recently is the “issue” of elements vs. tags. The problem is that people say tags when they mean elements, and do it so often that it’s not clear if the distinction is still relevant.
Or if anyone even cares anymore.
Elements vs. tags
If you look at section 3 of HTML 4.01 — “on SGML and HTML”, there’s an explicit note about elements not being tags. In HTML 4.01, <p>foo bar</p> is an element, not a tag. An element consists of a start tag, content, and an end tag. In case of <p>foo bar</p>, <p> is a start tag, foo bar is content, and </p> is an end tag.
In other words, elements consist of tags.
Optional tags
The distinction between tags and elements becomes slightly less clear once we start dealing with elements that have optional tags, as defined by HTML 4.01. For example, <p> or <td> elements don’t have to have end tags. They could very well exist without them. When parser finds <p>foo bar in markup, it still creates an element. There’s no end </p> tag, but parser doesn't really need it; start <p> tag already denotes what kind of element it is.
<p>foo bar
<tr>
<td>baz
<td>qux
</tr>
But that’s not all.
Some elements, besides having optional end tags, have empty content model, which means that they can’t have any content at all. And when an element is not allowed to have any content and has an optional tag, it’s called an empty element. Not only are end tags optional in such elements, but they must be completely omitted. These, unfortunately, are not some obscure elements, but are very much useful ones like <br>, <link>, <img>, <input>, <meta> and few others.
What’s interesting is that <br> is still an element, only an element that consists of start tag only. It’s just that its content and end tag must never be present. The fact that <br>, <img> or other empty elements consist of start tags only, makes things rather confusing.
And we’re not even talking about elements with both tags optional — <html>, <head>, <body>. Those could exist without any visible traces at all, and are only created based on the context.
<html>
<body>
...
</body>
</html>
Which confusion?
So which practical implications does this confusion actually have?
For one, saying something like “insert an image after a <p> tag” is ranging from “wrong” to “ambiguous”, since we can’t insert anything but a chunk of text after a <p> tag, and <p> tag can be either a start one (<p>) or an end one (</p>). In this case, a better way would be to say — “insert an <img> tag after a start <p> tag”:
<p>
<img ...>
...
</p>
in which case <img> element would become a child of <p> element. Or we could say — “insert an <img> tag after an end <p> tag”:
<p>
...
</p>
<img ...>
in which case <img> element would be a sibling following <p> one.
Of course, most of the time, what people really mean by “insert an image after a <P> tag” is a second version. It’s just that “element” is accidentally replaced with a “tag”. An even better way — and the one that avoids mention of tags in the first place — is to say “insert an <IMG> element after a <P> element”. This version leaves no room for incorrect interpretation.
Global confusion
What’s interesting about all this is not so much the finer points of difference between tags and elements, but just how widely this misconception prevails. Google search returns 480,000 results for “div tag”, but only 137,000 for “div element”. For an empty element, such as img, the difference is even scarier — "img tag" returns 959,000 results, while "img element" only 48,200. An element is confused for a tag everywhere, from blogs, articles, and mailing lists to books, references, and frameworks.
- Ruby on Rails uses “tag” in all of its helpers — tag, image_tag, stylesheet_link_tag, etc. — where each of those methods actually insert an element into a document.
- w3schools uses “tag” throughout its entire reference — “<div> tag”, “<abrr> tag”, etc. — to refer to elements.
- hacks.mozilla.org uses tag when talking about HTML5 video element.
- Ajaxian mentions it here and there.
- Books like “High Performance Javascript” explain things in terms of tags, rather than elements.
- and many, many others…
Pedantry or important distinction?
Once you start thinking about the distinction, edges become somewhat blurry. Are all of the examples above really wrong?
When describing “image_tag”, Ruby on Rails documentation says “Returns an html image tag …”. The returned string — “<img ...>” — can actually very well be considered an image (start) tag. Yes, the string represents an element, but since an element is empty, it’s also a string that consists of <img> tag only, and so can probably be called an “image” tag.
At the same time, “javascript_include_tag” already crosses the line of correctness. It still uses “Returns an html script tag”, but already returns a string that can only be considered an element — “<script type="text/javascript" src="..."></script>”, since there’s now a start tag, content (empty), and an end tag.
w3schools is just plain wrong [1], saying things like “The <div> tag defines a division or a section in an HTML document.” or “The <div> tag is often used to group block-elements to format them with styles.”. Tags do not define division, they represent elements, and it is elements that have certain semantic meaning; in this case — division.
In some of the popular articles, we can find phrases like “… the nearer ancestor of our <footer> tag is the <body> tag …”, in which case it’s pretty clear that “tag” is not the right word at all; Tags can not be ancestors, but elements can.
However, saying that “browser supports <video> tag” is technically not wrong, since browsers supporting <video> element, most definitely can parse and understand <video> tags as well (it is by recognizing video tags that they are able to create video elements in DOM).
Speaking of DOM…
What about DOM?
Before I knew the difference between tags and elements, I would always think in terms of tags when talking about HTML, and in terms of elements when talking about DOM. It just made sense that HTML, being markup language, consists of tags, while HTML DOM — or rather, the document available for scripting — is a tree-like structure consisting of elements, and other kinds of nodes. I knew that browser parses HTML markup (and so tags), and then creates a tree-like structure to represent a document, in which case tags essentially become elements. The fact that elements are not just kinds of nodes, but are also chunks of text in markup seemed very strange when I first found out about it.
It seems that this is exactly how most of the people think about tags vs. elements. Tags exist in HTML (text), and elements - in document (DOM). This would explain why tags prevail in discussions about HTML, or markup in general; and why elements are mostly mentioned in context of scripting, rendering, etc.
Nevertheless, I believe that keeping terminology straight is important. Things should be called as they really are, to avoid the ambiguity that we've seen in the previous example. A method named something like forEachTag should not iterate over each element, and vice-versa; technical discussions, articles, and documentation should really strive to use proper terms.
What now?
The attempts at demystification were already made in the past, yet the effect is barely visible. So I wonder — why? Is it too unintuitive to speak in terms of elements in context of HTML, or is this a lack of explanation and exposure of the subject? Does the distinction even matter? Or does it matter in technical discussions only? Does it make sense to distinguish these two entities, or should we just try to infer the exact meaning based on the context, as it seems to be done right now? Are we all simply used to the word “tag”, and don’t care about the difference most of the time?
What do you think?
[1] ...which is not surprising, considering the amount of other misconceptions on that site, such as classifying HTML comments as tags.
Did you like this? Donations are welcome
comments powered by Disqus