HTML Syntax, Lazy or Long

In the book, we showed two different versions of a basic HTML file containing an <svg> element. What is the difference, and why would you want to use the longer version?

We mentioned one reason: the more formal syntax is XML compatible. When you’re working with SVG, keeping your inline SVG code XML-compatible means being able to copy and paste code into standalone SVG files. But even for the HTML itself, there are some benefits to the more formal code.

So let’s start with the bare minimum inline SVG HTML file:

<svg>

The HTML parser will see that “ooops, you forgot to mention that you were using modern HTML” and will turn on quirks mode to ensure it is compatibile with 1990s-era code. Quirks mode changes a variety of little details about how CSS works. You probably don’t want that, so a good HTML file will start with the modern HTML DOCTYPE declaration.

The HTML parser will also see that “ooops, you forgot to create an <html> element, or an HTML <head> element, or an HTML <body> element”, so it will create all of those for you. Then the HTML parser will create an <svg> element—because you did remember to include that—but it will see that “ooops, you forgot to mark the end of the element before the end of the file.” So it will also do that for you.

Compare with the code for Example 1-1, here reproduced as Example 1-X1. Many of the extra elements and attributes add important information, to be sure our web page is correctly interpreted.

Example 1-X1. Defining a (complete) HTML file for inline SVG

<!DOCTYPE html>     
<html lang="en">    
    <head>          
        <meta charset="utf-8" />   
        <title>HTML file with Inline SVG</title>    
        <style>
        </style>    
    </head>
    <body>          
        <svg width="400px" height="400px">
        </svg>      
    </body>
</html>

: The file starts with the modern HTML document type declaration. Older HTML DOCTYPE tags were long and convoluted, requiring copying and pasting every time. Modern HTML uses <!DOCTYPE html>. It’s short and simple, so you have no excuse for leaving it out. Without it, the layout might get a little quirky.
: After the declaration, the HTML document itself starts with the opening tag of the <html> element. The element has one attribute, lang which defines the language of all human-readable text in the file. In this case, that’s en for English.
: A <head> element is the first child of <html>. It contains metadata that won’t be drawn to the screen, but which the browser should know before it parses the rest of the file.
: The most important metadata: the character encoding declaration. A character encoding is the system by which the computer converts binary data (bits and bytes) in a file into letters, numbers, and < signs. The web browser would have needed to make a good guess at the character encoding to get this far, but lots of encodings are similar. The utf-8 value says that we saved the file using UTF-8. PS: make sure you save your file using UTF-8. Most modern code editors do it automatically, but older software might not.
: The <meta> tag doesn’t (and can’t) have any children. To make the file XML-compatible, we mark the tag as self-closing tag with a / before the final >.
: The next most important metadata is the <title> element, which declares a human-readable name for the file. This time, the value isn’t an attribute, but the text content contained between the opening <title> tag and the closing </title> tag.
: A <style> tag (with its matching </style> closing tag) is also included in the <head>, as a placeholder. If we had any CSS code for the document, we could put it here.
: After closing off the <head> element with a </head> tag, the actual content of the HTML file is included in a <body> element.
: The only content in this page is our one inline SVG element. The opening <svg> tag now has two attributes, width and height. And we now have a matching </svg> closing tag to mark the end of the SVG code.
: Finally, we close off the <body> and then <html> elements, with </body> and </html>.

Although some of the extra tags don’t change the final results, they help keep our code clear and consistent. By opening and closing all our tags, we help ourselves keep track of the final DOM structure that will be created in the browser, which will be used by our CSS styles and JavaScript code. It also works better with most code editors’ syntax highlighters and auto-complete tools.