Visual HTML elements are categorized into one of two groups:
Consider the following HTML content:
<body> <p>The <em>cow</em> jumped over the <b>moon</b>.</p> </body>
Here we have a
<p> paragraph element. Because it is a block-level element, this paragraph will
fill its container (in this case the
<body> element). It will also have empty space added above and below it.
Within this block, we also encounter a number of other inline elements. First, we have simple text.
However, we also see the
<b> elements being used. These will affect their content, but not
create a new block; rather, they will continue to flow inline in their container (the
Many of the elements we’ve seen so far begin with an opening tag, and end with a closing tag:
However, not all elements need to be closed. Some elements have no content, and therefore don’t need
to have a closing tag. We call these empty elements.
An example is the
<br> line break element.
We use a
<br> when we want to tell the browser to insert a newline (similar to using
\n in C):
<p>Knock, Knock<br>Who's there?</p>
Other examples of empty elements include
<hr> (for a horizontal line),
<meta> for including metadata
<head>, and a dozen others.
Often we need to group elements in our page together. We have a number of pre-defined element container options for how to achieve this, depending on what kind of content we are creating, and where it is in the document.
Using this so-called semantic markup helps the browser and other tools (e.g., accessibility) determine important structural information about the document (see this post for a great discussion):
<header>- introductory material at the top of a
<nav>- content related to navigation (a menu, index, links, etc)
<main>- the main content of the document.
<article>- a self-contained composition, such as a blog post, article, etc.
<section>- a group of related elements in a document representing one section of a whole
<footer>- end material (author, copyright, links)
Sometimes there is no appropriate semantic container element for our content, and we need something more generic. In such cases we have two options:
Sometimes our data is tabular in nature, and we need to present it in a grid. A number of elements are used to create them:
<table>- the root of a table in HTML
<caption>- the optional title (or caption) of the table
<thead>- row(s) at the top of the table (header row or rows)
<tbody>- rows that form the main body of the table (the table’s content rows)
<tfoot>- row(s) at the bottom of the table (footer row or rows)
We define rows and columns of data within the above using the following:
<tr>- a single row in a table
<td>- a single cell (row/column intersection) that contains table data
<th>- a header (e.g., a title for a column)
We can use the
colspan attributes to extend table elements beyond their usual bounds,
for example: have an element span two columns (
colspan="2") or have a heading span 3 rows (
<table> <caption>Order Information</caption> <thead> <tr> <th>Quantity</th> <th>Colour</th> <th>Price (CAD)</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Red</td> <td>$5.60</td> </tr> <tr> <td>3</td> <td>Blue</td> <td>$3.00</td> </tr> <tr> <td>8</td> <td>Blue</td> <td>$1.50</td> </tr> </tbody> <tfoot> <tr> <th colspan="2">Total</th> <th>$26.60</th> </tr> </tfoot> </table>
HTML5 has built in support for including images, videos, and audio along with text. We specify the media source we want to use, and also how to present it to the user via different elements and attributes
<!-- External image URL, use full width of browser window --> <img src="https://images.unsplash.com/photo-1502720433255-614171a1835e?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=344dfca9dc8cb137a4b1c2c711752bc5"> <!-- Local file cat.jpg, limit to 400 pixels wide --> <img src="cat.jpg" alt="Picture of a cat" width="400">
HTML5 has also recently added the
, to allow for an optimal image type to be chosen from amongst a list of several options.
We can also include sounds, music, or other audio:
<!-- No controls, music will just auto-play in the background. Only MP3 source provided --> <audio src="https://ia800607.us.archive.org/15/items/music_for_programming/music_for_programming_1-datassette.mp3" autoplay></audio> <!-- Audio with controls showing, multiple formats available --> <audio controls> <source src="song.mp3" type="audio/mp3"> <source src="song.ogg" type="audio/ogg"> <p>Sorry, your browser doesn't support HTML5 audio. Here is a <a href="song.mp3">link to the audio</a> instead</p>. </audio>
Including video is very similar to audio:
<!-- External Video File, MP4 file format, show controls --> <video src="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4" controls></video> <!-- Local video file in various formats, show with controls --> <video width="320" height="240" controls> <source src="video.mp4" type="video/mp4"> <source src="video.ogg" type="video/ogg"> <source src="video.webm" type="video/webm"> <p>Sorry, your browser doesn't support HTML5 video</p> </video>
<video> elements must use source URLs that point to actual audio or video files
and not to a YouTube URL or some other source that is actually an HTML page.
such an element in the form of the
We can use
<script> in one of two ways.
<!doctype html> <html> <head> <meta charset="utf-8"> <title>Web Page with Script</title> </head> <body> <script> console.log('Hello World!'); </script> </body> </html>
<script> elements can occur anywhere in your HTML, though it is common to put them at the end of the
We can also include more than one, and each shares a common global environment, which is useful for combining
<script> // Define a global variable `msg` with a String var msg = "Hello World!"; </script> <script> // Access the global variable `msg`, defined in another <script>, but within the same JS environment console.log(msg); </script>
starts to become unwieldy. For very small scripts, and debugging or experimentation, inline scripts are fine.
a number of reasons.
Second, your HTML becomes harder to read. Instead of looking at semantic content about the structure of your page, now you have script mixed in too. This can make it harder to understand what you’re looking at while debugging.
.js file extension.
We then tell the browser to load and run these files as needed via our
<script> tag like so:
<!doctype html> <html> <head> <meta charset="utf-8"> <title>Web Page with Script</title> </head> <body> <script src="script.js"></script> </body> </html>
In this case, we have no content within our
<script> element, and instead include a
attribute. Much like the
<img> element, a
<script> can include a
src URL to load at runtime.
The browser will begin by loading your
.html file, and when it encounters the
<script src="script.js"> element,
it will begin to download
script.js from the web server, and then run the program it contains.
We can combine both of these methods, and include as many scripts as we need. The scripts we include can be:
<!doctype html> <html> <head> <meta charset="utf-8"> <title>Web Page with Scripts</title> </head> <body> <script src="https://scripts.com/some/other/external/script/file.js"></script> <script src="local-script.js"></script> <script> // Use functions and Objects defined in the previous two files doSomethingAmazing(); </script> </body> </html>
It’s clear that learning to write proper and correct HTML is going to take practice. There are lots of elements to get used to, and learn to use in conjunction. Also each has various attributes that have to be taken into account.
Browsers are fairly liberal in what they will accept in the way of HTML. Even if an HTML file isn’t 100% perfect, a browser can often still render something. That said, it’s best if we do our best to provide valid HTML.
In order to make sure that your HTML is valid, you can use an HTML Validator. There are a few available online:
Both allow you to enter a URL to an existing web page, or enter HTML directly in a text field. They will then attempt to parse your HTML and report back on any errors or warnings, for example: an element missing a closing tag.