Web Design Vocabulary Refresh Part 1: HTML
What’s the difference between an element and a tag? When should I use strong and when should I use bold? What the heck is the DOM? When you’re new to web design, one of the biggest hurdles to overcome is always the jargon. So many technical terms are thrown around flippantly and rarely explained outright that it’s easy to get lost.
This series will serve as a basic introduction to some terms that every new web designer should be sure to add to his or her vocabulary. This won’t be an exhaustive vocabulary list but rather a primer on a few terms that I found difficult to wrap my head around when I was a beginner. We’ll start with HTML today and move on to CSS in the near future.
Envato Elements gives you unlimited access to 1 million+ pro design resources, themes, templates, photos, graphics and more. Everything you'll ever need in your design resource toolkit.
Themes & Plugins
PowerPoint & Keynote
Landing Pages & Email
HTML & HTML5
HTML stands for HyperText Markup Language. To better understand this term, let’s slice it up piece by piece.
Hypertext is simply text displayed on a digital device that uses active links to make navigation easier. For instance, to get to this page you likely clicked on a piece of text that redirected your browser to the correct location.
A markup language is a way to annotate documents. With a markup language, we can turn plain text into richly formatted documents through the use of special syntax that tells the parser how to display the information and elements passed to it.
Put It Together…
With this in mind, HTML is a way to annotate and subsequently format documents for display that is dependent largely upon a system that enables text-based links. This is the very foundation of how the web works.
HTML5 is exactly what it sounds like, the fifth major iteration of HTML. HTML5 serves as a replacement for both HMTL 4.01 and XHTML 1.1, so any time you see references to these languages just know that HTML5 is the newer syntax.
HTML5 brings a ton of new features, elements and syntax changes to HTML, too many to list exhaustively here. Some that you might see mentioned regularly are a canvas element for rendering graphics, a new simplified doctype, the ability to embed video without custom plugins like Flash and new APIs for web application developers.
To learn all about HTML5, browse take a look at the following extensive resources:
When I first started in web design, I heard this phrase daily and it drove me nuts. Everyone always seemed to be up in arms about what was semantic and what wasn’t. It turns out, the reason for this is simple: a semantic web is a better one.
Basically, the core concept here is that your markup should convey as much meaning as possible. To accomplish this, you should use elements as they were intended to be used and in a way that clearly communicates to anyone or anything that is looking at your code.
For instance, it used to be commonly the case that developers would structure entire web pages using HTML tables. The problem with this is that the table element has a very specific purpose: to display a table of information (think of a pricing table or feature comparison chart). When you see the
While we’re on the topic of semantic web design, we might as well discuss the most argued about element since table: div. If you’ve ever taken a look at the source of an HTML page, odds are you saw divs everywhere. So what the heck is a div?
The term “div” is short for “division.” If you think that’s a little vague, you’re right. In fact, the entire purpose of the div element is to be vague. Divs are basically a generic container for blocks of content that can’t otherwise be described on a semantic level.
This of course leads to the idea that divs are non-semantic creatures, meaning that a div in and of itself doesn’t really convey meaning. Consequently, given the principles that we outlined in the previous definitions, divs should be used as sparsely as possible, at least in theory. In practice, many developers are fairly generous with them.
Since they’re so versatile and useful for creating structures that are easily targetable with CSS, we instinctively use tons of divs. However, where possible, you should always reach for something more semantic. For instance, consider the following block of code that was quite popular before HTML5.
<div id="header">some content</div>
With the ID, we’ve sort of infused some meaning but the div itself is still a generic, undesirable item. With HTML5, we can ditch the div and use the much more semantic header element.
em vs. italic and strong vs. bold
This one can really get tricky, especially because HTML5 offers up some slightly modified semantic meaning for these terms. Let’s start with em vs. italic.
The spec for using the italic element states that it is now used for text that is “offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is italic text.”
The key here is that the italic element does not convey any extra emphasis, whereas obviously the em tag does. Think of it simply as a different mood or voice.
Examples include a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.
<p>I bade them all <i>adieu</i> and left as quickly as possible.</p>
Contrast this with the em element, which is used for emphatic stress. Here we are actually attempting to communicate that you would speak the contents of the element differently than the rest of the sentence.
<p>I <em>already</em> told you that didn't I?</p>
Moving on, the bold element has been changed to have a meaning almost identical to that of the italic element: ““offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is bold text.”
Once again, we see that the key here is that we’re not really adding emphasis, merely following typographical convention. For instance, a script might bolden the character names.
<p><b>John</b>: "Come on, Yoko isn't that bad."</b>
Alternatively, you should should use strong to convey “strong importance.” For example, warning messages often utilize this convention.
<p><strong>Danger:</strong> If there are rocks ahead, we'll all be dead!</p>
With strong, you can even use nesting to convey more levels of importance.
<p><strong><strong>Danger:</strong> If there are rocks ahead, we'll all be dead!</strong></p>
To learn more about these four elements, check out HTML5 Doctor, which has a pretty extensive explanation of the changes implemented in HTML5 and how you should use each.
Class vs. ID
One of the most critical differences that you need to understand as a front end web designer is the difference between a clasa and an ID. Consider the following two snippets, do you understand how they’re different?
Fortunately, the difference is actually really simple to understand: IDs are unique and classes are resuable. For instance, the following is not a valid use of HTML because I’ve used the same ID on two different elements.
The fix here is to change those IDs to classes. The same class can be applied to as many elements as you want. Targeting that one class in your CSS will allow you to style a bunch of elements in one go.
Some have gone so far as to say that you shouldn’t ever use IDs and instead always look to classes because they’re more versatile. The argument makes sense but to be honest I don’t really buy into it and still find valid uses for IDs all the time.
Elements vs. Tags
On one hand, this distinction doesn’t seem like the most critical thing in the world. After all, many developers use these terms interchangeably. However, a correct understanding of the basic structure of HTML is the foundation of a solid web development education. It might seem nitpicky, but these two terms do in fact mean different things.
To illustrate, let’s start on the most basic level. The following is a “start tag” for a list item.
Similarly, here is the “end tag” for a list item.
Each of these is a tag all on its own. However, they are not elements. Here is what the list item element looks like.
To put this concisely, HTML is comprised of elements and elements are comprised of tags and content. Generally, an element includes a start tag, content and an end tag, but some tags are self-closing so this terminology can get a little tricky.
When Paul Irish says you’re wrong, let’s face it, you probably are. I can’t pretend to know a tenth of the stuff that this guy can recite about web development in his sleep and I really appreciate him taking the time to point us in the right direction on this in the comments.
I checked a bunch of difference sources for these definitions and ultimately cobbled my own together based on where there seemed to be agreement. In this video though, Paul outlines what an element truly is, which is much more than you think. Ultimately, he concludes that it’s not the biggest deal in the world but while we’re on the topic, we might as well make sure we get it right!
This is another thing that confused me a lot when I first started writing HTML. I constantly heard people refer to “the DOM” but thought it sounded like something overly technical that I probably woulnd’t understand. I knew that there was a DOM and maybe that people were all about traversing it, but I had no clue what any of that meant. The obvious response, “it’s the Document Object Model” got me no where.
It turns out, the DOM is actually pretty easy to understand. At its most basic level, it simply refers to the structure of a web page and gives us a clear convention for visualizing and referring to each piece.
Put a different way, the DOM is the family tree of a webpage. At the top you have the document, which extends down to the root or html element and subsequently the head and body elements. If we take a look at the body element below, we can see that it branches off into other elements, each of which can have its own content and sub-elements.
We refer to the relationships in the DOM tree just like those in a family tree. If one element is inside another, it is a child of a parent. If two elements directly share a parent, they are siblings.
The above definition is really a simplified version of what the DOM is. Once you have a strong understanding of how the DOM defines the structure of HTML documents, you can then move on to the more complicated definitions, which will hopefully now make a little more sense. Check out the W3C definition for a much more in-depth discussion.
Here you’ll see the DOM referred to as a programming API for documents that defines an object structure. You’ll also see that this API contains various modules, such as CSS and MouseEvents, which can be implemented in various ways.
Block vs. Inline Elements
As you create elements in HTML and define their style in CSS, you’ll see that the browser interprets different elements in different ways from a layout perspective.
When you create a block-level element, such as a paragraph or a div, it appears on a new line or row in the flow of the document. So if you create three paragraphs, they will appear vertically stacked in the live preview rather than horizontally as columns. Another important distinction here is that block-level elements can be given a specific width and height.
An inline element on the other hand is rendered “in line” with the content before and after it. For instance, if you insert a strong element within a paragraph, it will not create a new line but will instead maintain the flow of the paragraph. Inline elements have a height and width automatically set by their contents, these values can not specifically be expressed.
Changing the Behavior
Using the CSS “display” property, we can change the behavior of certain items. For instance, here I take an anchor, which is by default an inline element, and tell the browser to render it as if it were a block-level element. This will now be given its own line set to a specific height and width.
We actually just went over this topic in our article on using “display: inline-block” as an alternative to floats. Check this out here.
What Terms Do You Struggle With?
I hope this brief glossary of HTML terms has shed a little light onto some potentially confusing topics. Each of these has tripped me up at one time or another so don’t feel bad at all if there’s anything that you never quite understood before now.
While we’re on the subject, are there are other HTML terms that either currently confuse you or have confused you in the past? Let us know in the comments and be sure to check back soon for our CSS vocab refresh!