HTML stands for HyperText Markup Language
HTML is the standard markup language/format for creating web pages, containing the content and structure of a page as a series of tags/elements.
In our ongoing analogy, HTML is the skeleton of the web. At its most basic it is a text file, in a folder on a computer, with a
As we heard in our first class, this format was codified by our pal Tim Berners-Lee in 1991, evolving from his earlier SGML, a similar/proto language. There have been five major revisions to the spec since then, which added (and sometimes deprecated, or removed) tags and syntax:
- HTML 1, 1991
- HTML 2, 1995
- HTML 3, 1997
- HTML 4, 1997 (busy year)
- HTML 5, 2014
The basic document
HTML consists of a range of elements, nested inside one another, like a matryoshka doll of text.
As a visual:
<!DOCTYPE html> <html> <head> <title>Page title</title> </head> <body> <h1>This is a heading</h1> <p>This is a paragraph.</p> <p>This is another paragraph.</p> </body> </html>
<html> element contains all elements of the page, the
<head> element contains the title, and the body contains
We call these semantic elements—which is saying that they give their contents a meaning or a role. (Remember Tim’s diagram.) These roles are then interpreted by your browser (Chrome, Safari, Firefox, etc.) when it loads the file, to ultimately display the page. We call this parsing the document.
The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation.
In our example, here is what we’ve told the computer:
What kind of file this is, so it knows how to parse it.
The root element of an HTML page, containing all the content.
Specifies a title for the page—which is shown in the browser’s tab, and when it is shared.
Defines the document’s body—the container for all the visible contents, such as headings, paragraphs, images, hyperlinks, tables, lists, etc.
Defines a primary/first-level heading.
Defines a paragraph.
We use semantic elements to help structure and describe our content—but also for accessibility (screen readers)—where the tag type helps indicate what things are.
What are elements?
Elements are composed of tags (opening, closing) and their content:
Some elements do not have any content or children, like
<img>. These are called empty elements and do not have a closing tag.
<h1>There should only be one first-level heading!</h1>
<p>You should always wrap your text in a paragraph!</p>
href(Hypertext REFerence) specifies a URL that the link points to, and the tag wraps the visible link text. The
hrefcan point to another, local HTML file (living in the same directory structure) or an external page. They can also point to specific parts of a page.
<a href="https://www.example.com">Links need attributes!</a>
srclikewise can point to a local image file or an external URL!
altprovides a description for accessibility/screen readers.
<img src="example.jpg" alt="Images should have descriptions!">
These are the structural containers of a website. The names don’t imbue meaning or function directly, but help us organize and think about our content structure. (And again, are helpful for accessibility.)
<body> <header> <!-- A header. --> </header> <main> <!-- Your main content. --> </main> <footer> <!-- The footer. --> </footer> </body>
<em>wrap around bits of text
<p>You may have noticed I like using <em>emphasis</em>.</p>
<ul> <li><!-- A list item. --></li> <li><!-- Another. --></li> <li><!-- A third. --></li> </ul>
There are many, many HTML elements, all with particular uses. (We’ll unpack some more, below.)
All HTML elements can have attributes, which provide more information about the element:
langattribute of the
<html>tag declares the language of the Web page.
<a>specifies the URL of the page the link goes to.
<a href="https://www.example.com">Goes to example.com</a>
_blankcan tell a
<a>to open in a new window/tab.
<a href="https://www.example.com" target="_blank">New tab!</a>
This can be annoying, so use it judiciously!
styleattribute is used to add styles to an element, such as color, font, size, etc.
<p style="color: blue;">This is blue text.</p>
We’ll use CSS for this kind of thing, but know this is how it used to be done and it was brittle and terrible.
<img>specifies the path to the image to be displayed, as above.
<img>provide size information for images. Not required, but helps prevent layout “sloshing” as images load.
<img src="example.jpg" width="200px" height="200px">
<img>provides an alternate text for an image, used by screen readers.
<img src="example.jpg" alt="A description of the image.">
idspecifies a singular, unique element on a page—for CSS targeting and anchor (scroll, “jump”) links, prepended with
<h2 id="a-heading-element">A heading element</h2> <a href="#a-heading-element">Goes to “a heading element”</a>
classattribute provides a selector took hook on with CSS.
<p class="warning">We’ll get into this soon.</p>
Case, whitespace, tabs, line breaks
HTML doesn’t care about capitalization, extra white space, or line breaks. The browser will just read everything from left to right, as if it is one long, running sentence. So the shouty
<HTML> and quieter
<html> are interpreted the same.
The browser parses both of these in the exact same way:
<body> <h1>Dog Breeds</h1> <p>There are many kind of dog breeds</p> <ul> <li>German Shepherd</li> <li>Bulldog</li> <li>Poodle</li> </ul> </body>
<body><h1>Dog Breeds</h1><p>There are many kind of dog breeds</p><ul><li>German Shepherd</li> <li>Bulldog</li><li>Poodle</li></ul></body>
But obviously, the first one is much more readable to us humans. We can use whitespace, tabs/indenting, and line breaks to make it easier for us to read the code. There are a lot of common patterns used—like indenting to indicate hierarchy/nesting. But there are also no wrong ways to do it! In HTML, spaces are code ergonomics for you—just like a good chair or desk, that allow you to work more comfortably.
Code is read more often than it is written. Code should always be written in a way that promotes readability.
Guido van Rossum
Block-level elements always start on a new line, and take up the full width available—stretching out to the left and right of their parent/container. They stack on top of each other. Importantly, block elements can have a top and bottom margin, unlike inline elements:
Inline elements do not start on a new line, and only take up as much width as necessary. I like to think of these as the little metal slugs from printing. Other text and inline elements will continue to flow around them, and they can wrap to new lines:
So many elements!
You can comment part of the code and the browser won’t show it. Comments are often used to explain your thinking, organize your code, “turn off” a bit of code, or hide whatever you’d like.
I highly recommend getting into a habit of commenting your code, especially when starting out. If you figure something tricky out, write down why and how you solved it to help you understand and remember. And you’ll often come back to things. Commenting your code is a gift to your future self!
Tables aren’t used as often anymore, in favor of
<div> and other layout elements. You used to have to use them to get any kind of multi-column, grid layouts. But those need even more CSS!
Any time you have more than two of something, you probably have a list. These are commonly used for semantic navigation elements, as well, think “here’s a list of links in this site.”
There are specific lists for defining things.
Again, there are many, many, many, many HTML elements. Try and find the one that best fits your usage, wherever possible using a semantic element that fits your content.
We haven’t applied any styles/CSS here yet, so everything we see in these examples is based on user-agent stylesheets—that is, each browser’s own default display (and behavior) for an element type. This is what the web was, before CSS! But as a designer, rarely what you want. We’ll get into writing our own styles in the coming weeks.
3.2. Priority of Constituencies
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.
W3C, HTML Design Principles