The web and the internet are two completely different things
It is important to define our terms, most especially for words that everyone thinks they understand. The terms web and Internet are not synonyms: they refer to completely different things.
The internet is “the network of networks”. It is the physical hardware: the servers, cabling, routers, modems, switches and clients (computers) that combine to form the massive network we call the internet. To use an analogy, the internet is plumbing: it is the physical infrastructure that allows information to flow. Furthering the analogy, that information – the data – is the fluid that is pumped through the plumbing. In reality, plumbing line could be used to transfer any kind of fluid or gas: in your house you are likely to have plumbing lines for hot water, cold water, and natural gas. Similarly, the internet can “pump” any kind of digital information. In our analogy, the data that makes up the “World Wide Web” would be hot, fluoridated water: it is simply one kind of information that can be transferred through the network. While the web remains the medium by which most people experience data on the Internet, it is by no means the only one. eMail, for example, can be transferred without using the web. (Yes, you need the web for gMail and Hotmail, but Outlook doesn't need the web in order to send eMail). Similarly, you can play a networked FPS game via the Internet without using the web. It is entirely possible to have a working internet connection but not be able to access the web. The reverse can never be true.
Tags are nested. Certain tags can only happen inside other tags: that is, between certain opening and closing tags. The order in which tags are opened and closed is vitally important, since using them in the wrong sequence will result in a page in disarray. Tags are closed in the reverse order to which they are opened. The rule is: “First in, last out”. That is, the tag that contains a nested series of tags is the last one to be closed. Another way of thinking about this is a series of matryoshka dolls, the Russian figurines which contain other figures inside themselves.
If the <html> tag starts our page immediately after the optional xml prolog and the doctype (which it does), it must therefore be the last one to be closed:
(Note that for the purposes of simple illustration the html tag is simplified: in a real page, it would have at least one attribute.)
Essentially, the <html> tag indicates that everything that follows it is, unsurprisingly, HTML. The opening <html> tag says “HTML starts here”. The closing </html> tag says “this is where the HTML code ends”.
The rest of our code must be written between these opening and closing tags. There are two major sub-sections: the <head> and <body>.
The body section contains what is going to appear on our page. The head section contains everything else: essentially, a description of our page, like the card catalog entry of a book. All of our page must be written within these two sections.
It's 20 degrees outside and study is probably the last thing on your mind. However: the brain atrophies if left unexercised.
As I write this, students in my full-time and night courses are winding up their classes in the final two weeks of the winter semester, working to complete their assignments. The temperature in the sunshine is 20°C, and everyone is eager to be outside.
I do not teach over summer: I need to retain (or recover) what sanity I have left. Instead, I travel, work in my shop, take in conferences, seminars and courses; and study. I will continue to update this site, not only with the best of these experiences, but with content that was either covered in class and did not have a matching article, or new content that will get the blog ahead of the demands of the fall semester. I also hope to add a few new features to the site, and (with luck and perseverance) a design refresh.
This means that there is a break of four months between courses for students. For those who are new to web development, that discontinuity creates a gap in which the skills and knowledge you have developed may become creaky, rusty and forgotten with disuse.
To counter this, I would encourage students, both full and part-time, to make three resolutions for the summer:
Check back often here for new articles, or information that you might have missed in class.
Work on something web-related over the summer. This does not have to be anything serious – I don’t expect you to sit inside for eight hours a day while the weather in Calgary is warm, the sun is out, and flowers bloom – but something you can come back to for a few hours a week, just to keep your skills sharp. A personal blog is a good project; a portfolio site is another popular suggestion. I’d love to have a “what I created over summer vacation” showing on the first day of class next semester.
Make a habit of reading a few articles a week on web development and/or design – not just here, but from other sites. A few suggestions:
Validation, Accessibility & Testing
Tools & Toys
Sticking to these resolutions will make your life far easier in the fall semester – not only will our review period be shorter and less demanding when classes restart, but we’ll also get to new, exciting material faster.
If you discover new resources that you’d like to share with other students over the summer, feel free to contact me so I may add them to this list. Most of all, have a good, safe vacation, and I look forward to seeing you in September.
The variety of browsers available can make testing your pages difficult, but solutions are possible.
IE has another issue, that of testing. A Windows machine will only ever want to have one version of IE installed at a time. If you’ve updated to IE9, you can’t keep a copy of IE6 on your system. By contrast, installing multiple versions of Firefox or Safari is a relatively straightforward process. (Not that doing so is usually necessary: the upgrade rate for non-IE browsers is fast, largely relieving you from the necessity of supporting old versions.)
The situation for IE is not quite as bad as it sounds, as IE8 has an “IE7 emulation mode” added to try to avoid breaking sites that were crafted to earlier versions of the browser that did not follow standards.
The ideal solution is to have several different computers running different versions of Internet Explorer: IE8 (with the option to emulate IE7) on one computer, and IE6 running under Windows XP on another machine, both looking at the same page. Alternatively, you could have browsers running on different virtual machines.
Increasingly the favoured solution is to use an online emulator, such as Adobe’s BrowserLab, browsershots.org or browserstack. Generally speaking these emulators are easier to use than installing a suite of browsers on your own machine; they can also be used from any computer with an internet connection, and provide a wide coverage of different browsers and platforms. However, being internet services, rather than local programs, they are also somewhat slower in providing feedback. As a result, anticipating and fixing as many problems as you can in advance becomes important (as opposed to working on problems line-by-line and waiting for the online emulator to respond in order to check each one).
HTML5 - what it is, what it isn't, and what it will become
Welcome to the second decade of the 21st century. As we usher in a new year, it feels appropriate to discuss new and exciting technologies, so we shall turn our sober attention to HTML5.
While we’re on the subject, let’s dispatch a few other myths and misunderstandings regarding HTML5:
As of this writing, HTML5 is probably not quite ready for implementation on most mainstream websites. The primary reason for this is that there is no version of Internet Explorer that natively supports HTML5. (There are, of course, ways around this, which we will discuss shortly). In addition, some aspects of HTML5 – perhaps most importantly, codec support for the <video> element – are still under development, and inconsistent between browsers.
HTML5 is not a done deal: while most of the specification is nailed down, there are aspects that are still open to interpretation. This makes some HTML5 modules a moving target, just as CSS3 is. This may mean more revisions for a site coded in HTML5 as the specification changes.
HTML5 does not replace XHTML, or make it obsolete. The two languages will be used alternatively (and in some cases, side-by-side) for at least the next five years. The lessons and habits you learned in XHTML are still entirely applicable to HTML5. HTML5 expands and improves upon XHTML; it does not kill it.
If this is the current state of play, why are we going to learn HTML5?
Employers will be looking for knowledge and skills in the language (even if they are not yet clear on how it may be applicable to their business).
Adoption and support of HTML5 is certain to rise in the near future, especially if IE9 supports the technology to the depth that Microsoft is assuring us that it will. (Update: it kind of did, although there are still areas that are lacking).
If you are making a website that will primarily be interacted with on smart mobile devices, such as iPhones, Android, Palm Pre and recent Blackberries, HTML5 may be a very good strategic decision: the browsers on those devices (mobile Safari and Opera) have strong support for HTML5. (Naturally, Windows Mobile does not do so natively).
If you need a rough guide as to when I personally believe that HTML5 will be ready for prime time, my intention is to recode this site to pure HTML5 in early 2012. (Update: which you are reading now!) This is partly a concession to time and scheduling, but also an estimate as to when a significant portion of visitors to my site using IE (currently around 8% of all unique visits) will have transitioned to IE9. (Update, early 2012: IE is now around 1% of all visits).
For the last decade I have been saying that XHTML is a bridge, a conduit to a glorious future of pure XML. While that is still true, things have been complicated somewhat by the introduction of HTML5.
After XHTML was finalized in 1999, the W3C started in on XHTML 1.1. In some ways this small, bureaucratic revision of the language, but one change was very significant: rather than merely being cross-compatible with XML, XHTML 1.1 was XML, and had to be served in as XML to the browser. To the W3C, this was the next logical step.
At the time, the browser with preeminent market dominance (Internet Explorer) barely understood XHTML, let alone XML served directly. While not the W3C’s fault or responsibility, this “reality gap” created the impression that the organization was increasingly out of step with the day-to-day reality of creating content for the web, preferring to immerse itself in pure theoretical work that had little application to real-world issues.
XHTML 1.1 was never really taken on by web developers. Tensions only grew with the XHTML 2 initiative. As proposed by the W3C, XHTML 2 would be completely new, dropping any relationship to, and compatibility with, HTML. It was bold and promising – but progress, developed by international committee and consensus, was achingly slow. Demands from the web development community for features they wanted now, such as more intelligent web forms and the ability to create applications, were rejected by the W3C. Even the inventor of HTML weighed in, stating that the effort to move the web to XML was not working.
What happened next was a schism.
Opera, Apple, Google, Mozilla and other major players moved to put their weight behind a splinter group: the Web Hypertext Application Technology Working Group, or WHATWG.
Rather than the large, UN-like organization of the W3C, in which no one person has preeminent authority and decisions are made formally and very slowly, WHATWG is more like a benign dictatorship: small, streamlined, and headed by just one person, editor Ian Hickson. WHATWG focused on a pragmatic evolution of what browsers supported, and what developers wanted to achieve. Well-funded and with powerful companies evangelizing its work, the organization’s HTML5 proposal quickly gained steam. At the same time, the W3C continued to try to roll XHML2 forward.
To its credit, in 2009 the W3C recognized that its own efforts were not producing the value that it expected, and were in fact threatening to balkanize the web. It dropped development of XHTML 2, transferred its developers to HTML5, and formally adopted the work of WHATWG, moving into the role of senior advisor, reviewing and formalizing the HTML5 proposal. WHATWG is still at the coalface, interacting with designers and developers while putting the final touches on HTML5; the W3C is refining the result, preparing it for “final candidate recommendation” in 2012, its seal of approval, meaning that the language is “done and dusted”.
HTML5 has quickly gained browser support, and should see us through the majority of the second decade of the 21st century. The future is still XML: the potential of a true “roll your own” markup language is too powerful to resist, but its adoption in the browser has probably been delayed a dozen years. And that is okay: HTML5 is meant to fulfill our needs now.
Contains introductory and / or navigational content. <header> may be used multiple times on a page, and have multiple contexts: for example, <header> may be used immediately after the opening <body> tag to contain the main banner and navigation of the site, and could be used again inside a <section> or <article> to introduce new content.
A <header> will usually appear at the top of the page, but it doesn’t have to: its position and appearance are determined by CSS.
Important note: <header> should not be confused with <head>. Nor is <header> a heading element, like <h1> - <h6>. It is most akin to a masthead.
Contains closing, summary information about its parent element. Again, we should have multiple footers in the page, inside both <section> and <article> tags. They do not have to appear at the bottom of the page. A <footer> inside the body might contain copyright information, but a footer inside a blog post <article> tag would typically contain an author byline or related information.
Probably the most poorly named of the new tags (an aside is a stage direction or a type of dialogue), <aside> is meant to contain tangentially related information about the document. Asides could be pull quotes, a colophon, or other information. Asides are most akin to a sidebar, but they are not restricted to any particular position on the page.
A container for a group of related content. A successor to the generic <div> tag, although <div> still exists in HTML5.
A grouping of self-contained content, such as a blog post. New developers tend to get confused between <section> and <article>: the difference is the emphasis on self-containment. If content could be understood by itself, with no external context required – if it could be taken out an published in an RSS feed, for example – it is an article. Otherwise, <section> or another container element is more appropriate.
Adding to the confusion is the fact that articles could also be widgets, or web applications, such as calculators, weather reports, etc. Again, the emphasis is on self-containment: an <article> containing a weather report for Auckland, New Zealand could be moved from one site to another without requiring any additional content or explanation of context.
Also note that an <article> nested inside another <article> is, by definition, assumed to be a comment on the parent <article>.
Marks up a known time, date, or period. Should include more precise time information as a datetime attribute value. May use the pubdate attribute to clarify that the date is the publication date/time for an article or page.
Perhaps best thought of as an in-body meta tag for individual pieces of content. Like meta tags, <details> is not immediately visible to the user by default; unlike meta tags, <detail> is written inside the <body> of the document, not the <head>.
A typical use for <detail> might be inside an article, as the default content for an RSS feed or a way for search engines to summarize what each article about. A Dublin Core description meta tag summarizes the entire document; individual <details> tags (containing <summary> elements) may help summarize each piece of content.
The summary for a particular piece of content. Must be the first child immediately inside a <details> element.