Web Design Vocabulary Refresh Part 1: HTML

by on 5th March 2012 with 13 Comments

screenshot

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.

HTML & HTML5

HTML

HTML stands for HyperText Markup Language. To better understand this term, let’s slice it up piece by piece.

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

Markup Language
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

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:

On Semantics

Semantic HTML

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 inteded 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 <table> tag in use, you should immediately be able to say that what is inside is tabular data. However, when an entire site is contained in a table, this element loses all of its semantic meaning.

One of the great things about HTML5 is that it brings us several new clearly semantic elements to work with. A basic page outline might look something like the following. Even if you’re not familiar with HTML, there’s so much inherent meaning here that you can largely understand the flow of the document.

div

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.


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.

some content

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.

I bade them all adieu and left as quickly as possible.

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.

I already told you that didn't I?

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.

John: "Come on, Yoko isn't that bad."

Alternatively, you should should use strong to convey “strong importance.” For example, warning messages often utilize this convention.

Danger: If there are rocks ahead, we'll all be dead!

With strong, you can even use nesting to convey more levels of importance.

Danger: If there are rocks ahead, we'll all be dead!

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.

Attributes

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.

Other Jargon

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.

  • Some content
  • 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.

    Update!
    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!

    DOM

    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.

    screenshot

    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.

    This structure and verbiage gives us an interface for interacting with specific elements throughut a web page. For instance, in JavaScript or even HTML, you might utilize your knowledge of the DOM to target the first-child of an unordered list, meaning the first li element inside of the ul element.

    Going Deeper
    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.

    a {
    	display: block;
    	background: #eee;
    	height: 50px;
    	width: 200px;
    }
    

    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!

    Comments & Discussion

    13 Comments

    Comments & Discussion

    13 Comments

    1. kohgpat says:

      Thank you!

    2. Gareth says:

      Brilliant article, whilst many seasoned designers may not think so. I’ve just shared this with a newbie and it’s just what they needed! Great stuff!

    3. Andrew says:

      Thanks, some useful information there. The DOM has always confused me.

      What is an IDE and whats the difference between an IDE and a text editor?

    4. Marina says:

      Andrew,
      An IDE is an integrated development environment which contains the editor, linker, compiler and all the tools you need to write, execute and debug code.
      On the other hand, text editor is just the “editor” part of an IDE. It has no functionality to compile/run code.
      As for me, I’m using Notepad++ editor to write html & css, but it’s better to write javascript in Aptana IDE so I can debug.

    5. Andrew says:

      Thanks Marina!

    6. Ryan says:

      Great article. Nothing wrong with a little refresher!

    7. Virginia says:

      Thank you! This is a very helpful article

    8. Paul Irish says:

      Hi hi!

      The tags v elements distinction isn’t exactly correct. I tried to settle the debate here:
      http://www.youtube.com/watch?v=WxmcDoAxdoY#t=1513s

    9. Joshua Johnson says:

      I appreciate you calling me out on that Paul! I’ve updated the article and pointed to your definition. It’s obviously way more advanced than my own :)

    10. Louis says:

      Good summary, Josh.

      The only thing I’d like to point out is regarding this statement you made:

      “Some have gone so far as to say that you shouldn’t ever use IDs…”

      This statement has been made specifically in the context of promoting Object-oriented CSS (OOCSS). But you’ve taken it a little out of context. The full, more accurate statement, is:

      “Some have gone so far as to say that you shouldn’t ever use IDs for styling hooks.”

      You should definitely use IDs, because they come in handy for fragment identifiers (i.e. in-page links) and for scripting hooks. And all OOCSS proponents will say the same thing, so technically they never say “don’t use IDs”. In my opinion (and in the opinion of others who promote OOCSS), you *never* need an ID selector in your CSS (assuming, of course, that you have control over the markup too).

      Anything that an ID can do, a class can do too. There’s no reason to use an ID as a CSS hook, because #element has the exact same effect as .element, all things being equal.

    11. Joshua Johnson says:

      Good point Louis, thanks for adding a little context to my sidenote. OOCSS is really solid, as is SMACSS.

    12. rory says:

      I build the front end of web sites. I do not design websites. I am a front end developer, not a front end web designer. Please understand the difference.

    13. Dave says:

      spelling mistake? – Class vs. ID

      “…front end web designer is the difference between a clasa and an ID.”

    Leave a Comment

    Subscribe
    Membership
    About the Author