Sitepoint.com a basic-html5_template
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Sitepoint.com a basic-html5_template

on

  • 397 views

 

Statistics

Views

Total Views
397
Views on SlideShare
397
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Sitepoint.com a basic-html5_template Document Transcript

  • 1. sit epoint .com http://www.sitepoint.com/a-basic-html5-template/A Basic HTML5 TemplateThis article is an excerpt f rom HTML5 & CSS3 f or the Real World, by Alexis Goldstein, LouisLazaris & Estelle Weyl. See more details below.As you learn HTML5 and add new techniques to your toolbox, you’re likely going to want to buildyourself a blueprint, or boilerplate, f rom which you can begin all your HTML5-based projects. Inf act, you’ve probably already done something similar f or your existing XHTML or HTML 4.0 projects.We encourage this, and you may also consider using one of the many online sources that provide a basicHTML5 starting point f or you.[3]In this project, however, we want to build our code f rom scratch and explain each piece as we go along. Ofcourse, it would be impossible f or even the most f antastical and unwieldy sample site we could dream up toinclude every new element or technique, so we’ll also explain some new f eatures that don’t f it into theproject. This way, you’ll be f amiliar with a wide set of options when deciding how to build your HTML5 andCSS3 websites and web apps, so you’ll be able to use this book as a quick ref erence f or a number oftechniques.Let’s start simple, with a bare-bones HTML5 page:<!doctype html><html lang="en"><head><meta charset="utf-8"><title>The HTML5 Herald</title><meta name="description" content="The HTML5 Herald"><meta name="author" content="SitePoint"><link rel="stylesheet" href="css/styles.css?v=1.0"><!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]--></head><body><script src="js/scripts.js"></script></body></html>Look closely at the above markup. If you’re making the transition to HTML5 f rom XHTML or HTML 4, thenyou’ll immediately notice quite a f ew areas in which HTML5 dif f ers.The DoctypeFirst, we have the Document Type Declaration, or doctype. This is simply a way to tell the browser—or any
  • 2. other parsers—what type of document they’re looking at. In the case of HTML f iles, it means the specif icversion and f lavor of HTML. The doctype should always be the f irst item at the top of all your HTML f iles. Inthe past, the doctype declaration was an ugly and hard-to-remember mess. For XHTML 1.0 Strict:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">And f or HTML4 Transitional:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">Over the years, code editing sof tware began to provide HTML templates with the doctype already included,or else they of f ered a way to automatically insert one. And naturally, a quick web search will easily bring upthe code to insert whatever doctype you require.Although having that long string of text at the top of our documents hasn’t really hurt us (other than f orcingour sites’ viewers to download a f ew extra bytes), HTML5 has done away with that indecipherable eyesore.Now all you need is this:<!doctype html>Simple, and to the point. You’ll notice that the “5” is conspicuously missing f rom the declaration. Although thecurrent iteration of web markup is known as “HTML5,” it really is just an evolution of previous HTMLstandards—and f uture specif ications will simply be a development of what we have today. Becausebrowsers have to support all existing content on the Web, there’s no reliance on the doctype to tell themwhich f eatures should be supported in a given document.The html ElementNext up in any HTML document is the html element, which has not changed signif icantly with HTML5. In ourexample, we’ve included the lang attribute with a value of en, which specif ies that the document is in English.In XHTML-based syntax, you’d be required to include an xmlns attribute. In HTML5, this is no longer needed,and even the lang attribute is unnecessary f or the document to validate or f unction correctly.So here’s what we have so f ar, including the closing </html> tag:<!doctype html><html lang="en"></html>The head ElementThe next part of our page is the <head> section. The f irst line inside the head is the one that def ines thecharacter encoding f or the document. This is another element that’s been simplif ied. Here’s how you used todo this:<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  • 3. HTML5 improves on this by reducing the character encoding <meta> tag to the bare minimum:<meta charset="utf-8">In nearly all cases, utf-8 is the value you’ll be using in your documents. A f ull explanation of characterencoding is beyond the scope of this chapter, and it probably won’t be that interesting to you, either.Nonetheless, if you want to delve a little deeper, you can read up on the topic on the W3C’s site.note:Get In EarlyTo ensure that all browsers read the character encoding correctly, the entire character encoding declarationmust be included somewhere within the f irst 512 characters of your document. It should also appear bef oreany content-based elements (like the <title> element that f ollows it in our example site).There’s much more we could write about this subject, but we want to keep you awake—so we’ll spare youthose details! For now, we’re content to accept this simplif ied declaration and move on to the next part ofour document:<title>The HTML5 Herald</title><meta name="description" content="The HTML5 Herald"><meta name="author" content="SitePoint"><link rel="stylesheet" href="css/styles.css?v=1.0">In these lines, HTML5 barely dif f ers f rom previous syntaxes. The page title is declared the same as it alwayswas, and the <meta> tags we’ve included are merely optional examples to indicate where these would beplaced; you could put as many meta elements here as you like.The key part of this chunk of markup is the stylesheet, which is included using the customary link element. Atf irst glance, you probably didn’t notice anything dif f erent. But customarily, link elements would include a typeattribute with a value of text/css. Interestingly, this was never required in XHTML or HTML 4—even whenusing the Strict doctypes. HTML5-based syntax encourages you to drop the type attribute completely, sinceall browsers recognize the content type of linked stylesheets without requiring the extra attribute.Leveling the Playing FieldThe next element in our markup requires a bit of background inf ormation bef ore it can be introduced.HTML5 includes a number of new elements, such as article and section, which we’ll be covering later on.You might think this would be a major problem f or older browsers, but you’d be wrong. This is because themajority of browsers don’t actually care what tags you use. If you had an HTML document with a <recipe>tag (or even a <ziggy> tag) in it, and your CSS attached some styles to that element, nearly every browserwould proceed as if this were totally normal, applying your styling without complaint.Of course, this hypothetical document would f ail to validate, but it would render correctly in almost allbrowsers—the exception being Internet Explorer. Prior to version 9, IE prevented unrecognized elementsf rom receiving styling. These mystery elements were seen by the rendering engine as “unknown elements,”so you were unable to change the way they looked or behaved. This includes not only our imaginedelements, but also any elements which had yet to be def ined at the time those browser versions weredeveloped. That means (you guessed it) the new HTML5 elements.At the time of writing, Internet Explorer 9 has only just been released (and adoption will be slow), so this is abit of a problem. We want to start using the shiny new tags, but if we’re unable to attach any CSS rules tothem, our designs will f all apart.
  • 4. Fortunately, there’s a solution: a very simple piece of JavaScript, originally developed by John Resig, canmagically make the new HTML5 elements visible to older versions of IE.We’ve included this so-called “HTML5 shiv”[4] in our markup as a <script> tag surrounded by conditionalcomments. Conditional comments are a proprietary f eature implemented by Microsof t in Internet Explorer.They provide you with the ability to target specif ic versions of that browser with scripts or styles.[5] Thisconditional comment is telling the browser that the enclosed markup should only appear to users viewing thepage with Internet Explorer prior to version 9:<!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->It should be noted that if you’re using a JavaScript library that deals with HTML5 f eatures or the new APIs,it’s possible that it will already have the HTML5 enabling script present; in this case, you could removeref erence to Remy Sharp’s script. One example of this would be Modernizr, a JavaScript library that detectsmodern HTML and CSS f eatures—and which we cover in Appendix A, Modernizr. Modernizr includes code thatenables the HTML5 elements in older versions of IE, so Remy’s script would be redundant.note:What about users on IE 6-8 who have JavaScript disabled?Of course, there’s still a group of users who won’t benef it f rom Remy’s HTML5 shiv: those who have, f orone reason or another, disabled JavaScript. As web designers, we’re constantly told that the content of oursites should be f ully accessible to all users, even those without JavaScript. When between 40% and 75% ofyour audience uses Internet Explorer, this can seem like a serious concern.But it’s not as bad as it seems. A number of studies have shown that the number of users that haveJavaScript disabled is low enough to be of little concern.In one study conducted on the Yahoo network, published in October 2010, users with JavaScript disabledamounted to around 1% of total traf f ic worldwide. Another study indicated a similar number across a billionvisitors. In both studies, the US had the highest number of visitors with JavaScript disabled in comparison toother parts of the world.There are ways to use HTML5’s new elements without requiring JavaScript f or the elements to appear styledin nonsupporting browsers. Unf ortunately, those methods are rather impractical and have other drawbacks.If you’re still concerned about these users, it might be worth considering a hybrid approach; f or example, usethe new HTML5 elements where the lack of styles won’t be overly problematic, while relying on traditionalelements like divs f or key layout containers.The Rest is HistoryLooking at the rest of our starting template, we have the usual body element along with its closing tag andthe closing </html> tag. We also have a ref erence to a JavaScript f ile inside a script element.Much like the link element discussed earlier, the <script> tag does not require that you declare a typeattribute. In XHTML, to validate a page that contains external scripts, your <script> tag should look like this:<script src="js/scripts.js" type="text/javascript"></script>Since JavaScript is, f or all practical purposes, the only real scripting language used on the Web, and since all
  • 5. browsers will assume that you’re using JavaScript even when you don’t explicitly declare that f act, the typeattribute is unnecessary in HTML5 documents:<script src="js/scripts.js"></script>We’ve put the script element at the bottom of our page to conf orm to best practices f or embeddingJavaScript. This has to do with the page loading speed; when a browser encounters a script, it will pausedownloading and rendering the rest of the page while it parses the script. This results in the page appearingto load much more slowly when large scripts are included at the top of the page bef ore any content. This iswhy most scripts should be placed at the very bottom of the page, so that they’ll only be parsed af ter therest of the page has loaded.In some cases (like the HTML5 shiv) the script may need to be placed in the head of your document,because you want it to take ef f ect bef ore the browser starts rendering the page.[3] A f ew you might want to look into can be f ound at http://www.html5boilerplate.com/ andhttp://html5reset.org/.[4] You might be more f amiliar with its alternative name: the HTML5 shim. Whilst there are identical codesnippets out there that go by both names, we’ll be ref erring to all instances as the HTML5 shiv, its originalname.[5] For more inf ormation see http://ref erence.sitepoint.com/css/conditionalcommentsWant more? Check out the book and buy it online at HTML5 & CSS3 f or the Real World, by Alexis Goldstein,Louis Lazaris & Estelle Weyl. Download the f ree sample chapters, access the book’s code archive, check onupdates and errata or join the conversations on the SitePoint Forums.And if you enjoyed reading this post, you’ll love Learnable; the place to learn f resh skills and techniquesf rom the masters. Members get instant access to all of SitePoint’s ebooks and interactive online courses,like HTML5 & CSS3 For the Real World.Louis LazarisMore PostsRelated PostsA Minimal HTML Document (HTML5 Edition)A Minimal HTML DocumentW3C Markup Validation Service adds experimental HTML5 support5 Reasons Why You Can Use HTML5 TodayCross-Browser HTML5 Canvas with Fallback