Chapter 1. The Web Platform
If you’re keen to get on with the learning you’re probably considering skipping straight to Chapter 2, but I urge you not to as Chapter 1 contains some quite interesting and useful background information, and the less technical subject matter allows me to show off the best examples of my wonderful sense of humor.
A Quick Note About Terminology
Throughout the book, I refer quite often to building websites or sites, but this terminology is just convenient shorthand to avoid repetition. The features you’ll learn from this book are relevant to websites, web applications, packaged HTML hybrid applications—in short, anything that can use HTML, CSS, and JavaScript. But that’s a mouthful, so I mostly just say “websites,” except when I need to be more specific.
console.log('Hello World');And the result will be shown in the console; Figure 1-1 shows how this is displayed in Firebug. As I said, I won’t use the console or developer tools much, but if you don’t know how to use them, you should really take the time to learn now.
If you’re still reading this, either you have all the knowledge required to proceed, or you’re getting ready to try to bluff your way through. Regardless, let’s move on to talk about technology.
The web platform is vast. To see how vast, take a look at http://platform.html5.org/, which lists all of the technologies that are considered part of the platform; the list is really quite impressively long and contains far more than I could ever hope to cover in one book.
Instead, I’ll concentrate on the core, the technologies I feel are sufficient and useful for authoring websites that work across multiple devices: HTML5, CSS3, SVG, Canvas, and some device APIs. I’ll explain each of these as I get to them throughout the course of the book, but first I want to clarify in more detail what is meant by HTML5 and CSS3.
The Real HTML5
HTML5 is an iteration of HTML4.01 with some new features, a few deprecated or removed features, and some modified behaviors of existing features. Its aim is to standardize the many common hacks and design patterns that developers have used throughout the years and to expand in order to meet the demands of the modern Web, which is as much (if not more) about applications as it is about documents; indeed, the original proposal for what became HTML5 was called Web Applications 1.0.
New features in HTML5 include ways to structure documents for providing meaning and accessibility; I cover this in Chapter 2. HTML5 also has a whole range of new form functionality and UI controls that make it easier to build applications, which we’ll look at in Chapter 8. And HTML5 includes what many people still associate with it—native (without plug-ins) video, which is covered in Chapter 9.
Two main groups are working on HTML5, and their roles and responsibilities are broadly this: The WHATWG (you don’t need to know what that acronym means), a consortium of browser makers and “interested parties,” through the main spec editor Ian Hickson, creates a “living spec” of HTML—basically a versionless specification that constantly incorporates new features and updates existing ones; and the W3C (World Wide Web Consortium), the Web’s standards body, takes snapshots of this spec to create numbered versions, ensuring compatibility of implementation by the browser vendors.
The situation is, in fact, a bit more complex than that and plenty of political wrangling is going on, but that’s of interest only to standards wonks and shouldn’t make any practical difference to you.
The W3C has proposed, although not confirmed as I write this, that HTML5 (the W3C snapshot) be brought to Recommendation status—that is, “done”—by 2014, with HTML5.1 to follow in 2016. HTML5 would also be broken into separate modules rather than a single monolithic spec, so work can progress on different aspects without delaying the whole. These dates don’t really matter to you, however; all you need to know is when HTML5 is in browsers and ready to use.
The HTML5 Template
As someone with basic working knowledge of HTML, you’re familiar with fundamental page markup. But things have changed a little bit in HTML5—not much, but enough to mention. The following code block shows the basic template that I’ll use for all of the examples in this book (you can also see this in the example file template.html):
<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title></title> </head> <body></body> </html>
Most of it should be familiar to you, but I will discuss two points of interest. First is the Doctype. This is a remnant from the days when you had to tell the browser which type of document you were writing: strict HTML, transitional HTML, XHTML1.1, and so on. In HTML5, that’s no longer necessary—there is only one flavor of HTML—so the Doctype declaration really isn’t needed any more. In theory, that is.
Modern browsers tend to have three rendering modes: quirks mode emulates the nonstandard rendering of Internet Explorer 5, which is required for compatibility with legacy pages on the Web; standards mode is for modern, standards-compliant behavior; and almost standards mode is standards mode with a few quirks.
To know which mode to use, the browser looks to the Doctype. You always want to use standards mode, so the Doctype in HTML5 is the shortest possible that triggers standards mode:
<!DOCTYPE html>
The second point of interest, and the only other change to the standard HTML5 template, is the meta tag, which declares the range of Unicode characters used to render the text on the page—UTF-8 is the default used across the Web, so this is what you’ll use in most cases. The meta tag uses the charset attribute:
<meta charset="utf-8">
That’s really it. If a client ever asks you to “make their website HTML5,” you can update those two tags and charge them a fortune for it. (Please don’t; that was just a joke.)
I could have included plenty of other options, which I’ve left out for the sake of clarity and simplicity. The popular HTML5 Boilerplate website provides a comprehensive template, so look through the documentation to see what the template does—but please keep in mind it should be a starting point, not used verbatim.
<link href="foo.css" rel="stylesheet" type="text/css"> <script src="foo.js" type="text/javascript"></script>
But when working on the Web, CSS and JavaScript are the de facto default resource types used with these tags, so writing them out every time is a little redundant. Therefore, you can now drop them, making your code a little cleaner while still being understood perfectly well by the browser:
<link href="foo.css" rel="stylesheet"> <script src="foo.js"></script>
The only time you need to use the tags is when you’re not using default CSS or JavaScript; for example, some releases of Firefox have experimental implementations of recent versions of JavaScript, and for safety’s sake they require that you include a flag on the type attribute if you want to use it:
<script src="foo.js" type="application/javascript;version=1.8"></script>
HTML5 is also very forgiving of syntax. Whether your preference is to use all lowercase characters, quote your attribute values, or close empty elements, HTML5 is happy to parse and understand them. That being the case, all of these are equal:
<img src=foo.png> <img src=foo.png /> <IMG SRC="foo.png"/>
<input type="checkbox" checked> <input type="checkbox" checked="checked">
My own preference is to use all lowercase, all quoted, but not to close empty elements:
<img src="foo.png">
This is the style I use throughout the book, as I find it neater and easier to work with, and the text editor I use has syntax highlighting, which makes looking through the code nice and clear. You can use whichever system you want, but be consistent to help with maintainability.
But beyond the many glittery visual effects, the real revolution of CSS3 has come through media queries, a syntax that allows you to provide styles to browsers based on their dimensions and capabilities, the first step toward true multi-device styling. I cover media queries in Chapter 3, along with a range of other CSS properties that are useful for building responsive and adaptive websites.
The next big challenge for CSS to solve is the issue of layout—that is, to enable layouts that are truly sympathetic to the capabilities of the user agent viewing them. These include properties for dynamic user interfaces and CSS-controlled grid systems, which you’ll read more about in Chapter 4.
CSS3 is not a single spec as CSS2.1 was, where everything is described in the same document; it’s far too big and complex for that. Instead CSS3 is modular—a series of shorter, more specific specs that can be implemented by browsers in a modular way. As with HTML5, the idea of waiting until CSS3 is “ready” before using it is pretty foolish, as some modules will be ready and implemented long before others.
CSS modules are given level numbers to show how many iterations they’ve been through; some are already at level 4, and they could well be implemented before others that are at level 3. This doesn’t mean, however, that one day we’ll have a CSS4; there won’t be. CSS3 is a shorthand term for “everything more recent than CSS2.1,” and one day that distinction will be dropped and everything will be just CSS.
Vendor-Specific Prefixes
When browsers implement features in an experimental or prestandard way, they try to make them safe by using vendor-specific prefixes to avoid compatibility problems with standardized property names. Consider, for example, that a CSS Apes module proposes a new property called gorilla, and both Firefox and WebKit implement it experimentally but slightly differently. If both used the same property name, the effect would be different in each browser; instead, they avoid those potential conflicts by using a vendor prefix:
-moz-gorilla: foo; -webkit-gorilla: foo;
In principle, the system is great, but in reality, things have gotten somewhat confused. Among other problems, some prefixed properties became so widely used by developers that other browser makers felt the need to implement their rivals’ vendor prefixes too, which is justifiable but kind of makes the whole thing nonsensical.
Browser makers are trying to bring this system under control, but on occasion using vendor-prefixed properties will be close to unavoidable. In most cases, I use only unprefixed properties in my code examples and make a note in Appendix M of where vendor prefixes need to be used.
Rather than covering the levels of implementation in the text, I treat every new feature as if it’s fully implemented and make a note of real-world implementation oddities and curiosities in Appendix M.
Also, cutting-edge standard proposals are subject to change, even when experimental implementations have already shipped in some browsers (the Grid Layout module featured in Chapter 4 was updated while I wrote this book), so by the time you read this, some of the syntax in the book may already be out-of-date. This is an unfortunate risk when working with evolving standards in dead tree publishing, but I try to mitigate it by noting features that may be at risk of changing and by keeping a list of errata and updates on the companion website, http://modernwebbook.com/.
You’ll probably want to follow a few online resources to learn about levels of implementation, although most tend to be focused on desktop and mobile browsers. Can I Use… shows levels of support for a wide range of technologies in recent past, current, and future versions of popular browsers, whereas HTML5 Please shows how safe it is in general to use cutting-edge features, mostly CSS3 and JavaScript (which is why the name annoys me a little).
The HTML5 Test is a site that tells you how many features from the HTML5 spec your browser supports, but also very usefully keeps records of implementation levels across many different browsers and devices, including TV and games console browsers, and also allows you to do side-by-side comparisons of up to three different browsers. The site is limited to only HTML5 support, however.
This chapter provided you with all the information you need to get started in modern web development. I disambiguated the common meaning of HTML5 and introduced you to the web platform. You learned what HTML5 is useful for and how to start writing it, and you also had a brief introduction to CSS3.
With all of that explained, let’s roll our sleeves up and get to work.