Ian Devlin: What, in your opinion, are the best new features of HTML5?
Bruce Hyslop: There's a lot to like in HTML5. Of course, it's great to have a lot of new elements that fill the semantic holes of the past — figure and figcaption are helpful additions, for example — but I'll focus on some other areas:
Media, forms, and data-* attributes
I think HTML5's native media playback is an important step forward, even if it's currently missing some advanced features and the browsers didn't agree on the formats. So, although HTML5 audio and video aren't the solution for all media delivery scenarios currently, they represent progress, and more work is underway.
Speaking of native, I like HTML5's improvements to forms, such as the required attribute and the baked-in basic validation that comes both with it and new input types like email and url. I think they're good for both users and developers. They also can improve accessibility, and will do so even more once the implementations are solidified (see John Foliot's research at http://john.foliot.ca/required-inputs/).
Although they aren't features, per se, I find little things like HTML5's simplified DOCTYPE and character encoding meta notation to be refreshing. They're nice for all coders, but especially beginners because the code isn't convoluted like the old DOCTYPEs, and people don't have to go through the elaborate education of, "well, use this one and code this way for HTML 4.01 Transitional, use that one and code that way for XHTML 1.0 Strict," etc. Beginners have enough to learn as it is. So, you can add HTML5's looser syntax to my list, too, even if I personally prefer strict notation and hope I never see uppercase tags again! The only thing I'd encourage people to do is to be consistent in their syntax approach, whichever way they go.
The Web Storage API with localStorage and sessionStorage is a very welcome upgrade from cookies. localStorage data persists on your device even if you shut down your computer, while sessionStorage data is associated with a specific browser window/tab; when you close that, the data expires. Better still, when you couple Web Storage with Offline, a lot of possibilities open up. Not only can users work with a web app offline, but depending on how you develop it, they also can save data locally while they work offline, and sync it back to the server when they're connected again. This is the kind of thing people are referring to when they say HTML5 helps the web evolve as an application platform. There also are more robust data and even file manipulation APIs that work with HTML5, but aren't formal parts of it. The Geolocation API, though not related to data management, is another cool one that falls into this category. (Technically, depending on whom you ask, Web Storage is its own specification, too.)
So, HTML5 offers a little bit (actually a lot bit) of good stuff for everyone. You can see a list of the browser-based technologies (HTML5 and beyond) at platform.html5.org. It's pretty staggering when you see them all on a single page. It shows just how far we've come the past few years.
Ian: Similarly, what new features of CSS3 do you find most useful?
Bruce: Many of the new CSS3 features I find most useful are the same ones for which web designers and developers had been clamoring for years. They solve real problems, and address shortcomings of previous versions of CSS. Not surprisingly, it's common to see these new features on sites nowadays. Some of them include:
• border-radius (for rounded corners)
• rgba and hsla (for colors with alpha transparency)
• text-shadow (for applying shadows to text, big surprise!)
• @font-face (for embedding custom fonts).
(Historical side note for the curious: @font-face was first introduced in CSS2 and then dropped from CSS2.1 before coming back with a vengeance in CSS3.)
CSS3 Transitions are helpful for adding nice interactive touches to a page easily, like when a user engages a text input or hovers over a button. And with an eye to the future, I look forward to when we can safely use some of the new CSS3 layout solutions currently under development. They'll add more capabilities designers and developers have desired, not unlike the other features I mentioned.
Ian: Would you recommend that people start using HTML5 and/or CSS3 immediately in their websites, or are there occasions where it might not be appropriate?
Bruce: The quick answer is yes and yes. Before elaborating (quite a bit!), it's worth noting that the specs for HTML5 and CSS3 aren't finished. Web standards like these go through a lengthy process before they're rubber stamped, but that doesn't mean they're entirely in flux. Some new parts of HTML5 and CSS3 are essentially done and are very stable, while other parts continue to be updated regularly as they mature. This is normal.
Modern browsers have implemented a lot of these stable features, which means we can use them right now. I encourage people to do just that, provided they have a plan for browsers that don't support feature X or feature Y. That usually means IE8 and prior, although it sometimes includes IE9, too. There also are new parts of HTML5 that all browsers support—even old versions of IE—so you can use them now without a second thought. These include things like the HTML5 DOCTYPE, the simplified meta character encoding syntax, the script and style elements without the type attribute, data-* attributes, and the markup syntax style you prefer.
Let me go back to the issue of using features that modern browsers support and what to do about older browsers that don't. It's often OK if a page is different in an older browser. Other times, you may want to use a technique that approximates the HTML5 or CSS3 feature in question. Rounded corners are a common example. By all means, implement them with CSS3's border-radius property. All modern browsers support it. Meanwhile, IE8 and below will show square corners by default, which in many cases is absolutely fine. Those users probably won't even know the corners were designed to be rounded. But, if you or a client insist on having rounded corners for all users, you can use a two-pronged approach: keep the border-radius for supporting browsers and use one of the old non-CSS3 approaches for IE8 and below (although I suggest avoiding this for rounded corners if possible). You can follow this approach with other new CSS3 effects, too.
This plays into the second part of the question: "Are there occasions where it might not be appropriate to use HTML5 and/or CSS3?" Yes, there are. Previously, I discussed one possible scenario. I don't recommend a blanket approach, because each web site is its own entity with its own set of requirements. Whether you're creating a site for yourself or someone else, figure out those requirements ahead of time so you can plan accordingly.
For instance, it's important to know a site's audience. If you're creating a site for a client, request their visitors' browser usage statistics. If you've been asked to create an intranet site for a company that uses IE7 as its lone browser (and intends to for the foreseeable future), well, you won't be able to use CSS3. Knowing that upfront impacts both your design and development efforts. That's just one example; fortunately, it's not common. Additionally, you'll want to be careful about using features that aren't as mature in the specs and/or browsers. You could try out much of this stuff on non-critical sites or pages you don't launch, to be ahead of the curve.
Right about now readers might be wondering, "How do I find out which browsers support what, which new HTML5 and CSS3 features are safe to use now, and what to do if I want an older browser to approximate a feature it doesn't support?" Thankfully, there are some great sites that help answer that, namely When Can I Use, CSS3 Click Chart, and HTML5 Please.
When Can I Use details browser support, while CSS3 Click Chart categorizes each CSS3 feature as either "common stuff" or "cutting-edge," along with descriptions, code examples, and much more. HTML5 Please marks each feature with "use," "caution," or "avoid." It covers HTML5, HTML5-related APIs, CSS3, and more. And it suggests fallback methods and "polyfills" that you can use to provide comparable behavior in browsers that don't support a particular feature.
It's a really exciting, fast-moving time in the industry, so sites like these are valuable resources for people of all experience levels. They help you get a snapshot of the current state of affairs pretty quickly. Furthermore, Modernizr is the go-to script to use in your site to detect if a browser supports a particular feature so you can apply different CSS or behavior, as desired.
Summing it up, I recommend using the stable HTML5 and CSS3 features as much as you can, but just be aware that you may need to make accommodations for older browsers and adjust your approach some from site to site.
Ian: For people new to Peachpit's Visual QuickStart Guide series, what does this style of book teach readers about HTML and CSS?
Bruce: The HTML5 and CSS3 Visual QuickStart Guide largely serves beginners, so it teaches readers HTML and CSS from the ground up. For that reason, it doesn't just cover some of the new features in HTML5 and CSS3; it includes features HTML5 and CSS3 inherited from earlier versions of HTML and CSS, too. So, readers will learn everything from HTML elements for headings, paragraphs, lists, and citations to those for headers, footers, asides, figures, and tons more. It also covers how to build forms, and incorporate media with HTML5 audio and video and Flash. On the CSS side, it teaches you everything from styling text and using custom fonts, to applying colors, background images, drop shadows, gradients, and numerous other visual effects, to implementing layouts for mobile phones, desktops, and devices in between.
The book also mentions various best practices throughout so readers learn how and why to build sites that have good semantics, are accessible, are easy to manage, and so on. I thought these were important to emphasize given it may be the first book about building sites for many readers. I wanted to help give them a good foundation. It also covers particulars of launching a site, like testing and debugging pages, getting a domain name and web host, and publishing your site. In short, if you don't know the first thing about how to build and launch a site, the book shows you how.
For those who are new to the QuicksStart series, it's known for its approachable, informative style. Chapters contain largely task-based topics, such as "Marking Navigation" and "Applying Multiple Backgrounds" that explain how to use one or more HTML elements or CSS properties. This approach serves two purposes: you get information in logical chunks if you're just reading through it, and the book becomes a handy guide when you're building a site and aren't sure how to use a part of HTML or implement a particular design treatment. And like other Visual QuickStart Guides, this one is littered with code examples, screen shots, illustrations, tips, and sidebars that complement the text and step-by-step instructions.
Ian: You mention in the introduction that this 7th edition is a major revision of the previous edition published in 2006. In what ways does it differ from the previous version?
Bruce: Yes, that's true. There isn't a page in the book that wasn't updated in one way or another. A lot has happened on the web front since 2006, so it was important for the book to reflect that. One example is that the previous edition discussed the differences between HTML 4.01 and XHTML 1.0 and the various flavors therein, such as Transitional vs. Strict. That was appropriate at the time, but with HTML5 being the way forward, this new edition focuses squarely on HTML5. If the book does mention earlier versions of (X)HTML, it's usually in the context of explaining why HTML5 approaches something in a particular way, such as the redefinition of the b and i elements. To be clear, though, the book does cover the elements that HTML5 inherited from earlier HTML versions, because they're part of HTML5 just as much as the new elements.
There is a lot of new material: code examples were modified, and we redid nearly every screenshot. Several chapters updated from the previous edition are virtually new, receiving a major overhaul that in some cases meant all but rewriting them from scratch to make them current. Chapters 3, "Basic HTML Structure," 4, “Text,” 12, "Style Sheets for Mobile to Desktop," and 17, "Video, Audio, and Other Multimedia" (written by contributing author Ian Devlin), are a few examples.
There were other changes, too, but that gives you an idea of the revisions.
Ian: What previous knowledge of web development do readers need to get the most out of the book?
Bruce: Readers don't need any prior knowledge or experience. Since Elizabeth Castro started this book in 1996, it has always been geared toward the absolute beginner who wants to learn how to build and launch a site. I think it's one of the reasons it's been popular over the years, both with individual readers and in classroom settings. So, with this seventh edition, it was important to maintain that approach and breadth of coverage.
I think readers with prior experience can learn from it, too, particularly regarding the new and redefined HTML5 and CSS3 features, ARIA's landmark roles, and some other areas I've mentioned. But most of the information about HTML elements and CSS properties from before HTML5 and CSS3, such as optimizing images, getting a domain name, and uploading a site's files, will already be familiar to them.
Ian: The book covers both HTML5 and CSS3. Do these technologies only work together, or are they equally operable with earlier versions such as HTML 4.01 and CSS2.1?
Bruce: Great question. HTML5 and CSS3 don't only work as a unit. Your choices are only limited by what features a browser supports. For instance, if it supports the CSS3 box-shadow property, which allows you to create drop shadows, it'll work in your page regardless of whether it's HTML 4.01, XHTML 1.0, HTML5, and so on; the browser doesn't care. (Furthermore, if the browser doesn't support box-shadow, it'll ignore it and continue about its business.) Similarly, you could create an HTML5 page that doesn't leverage any of the new CSS3 features at all.
So, you can mix and match as you like. Of course, lots of people are using HTML5 and CSS3 together, because modern browser support is very strong for a lot of the new features, they offer more possibilities than their predecessors, and they're the way forward.
Ian: Chapter 3 discusses HTML5's new article and section elements in detail, giving many examples of their use. Do you think that these two elements are particularly difficult to use, or is it just a case of getting people to think differently about the content these elements will contain?
Bruce: The article and section elements have caused some confusion, but I think you're right. Learning to use them is about recognizing the kinds of content they're intended to represent. For one of the few times in the book, I quoted definitions from the HTML5 spec when describing how to use article and section. In part, I did that because I think it can help to read those definitions carefully a few times, and let them sink in. I've done that myself, and I think the purpose of article and section becomes more clear when you combine that with looking at examples of each element in practice.
Basically, article is for independent, self-contained content that could be redistributed (syndication is one example the spec sites), like blog entries, newspaper articles, user comments, or a reusable widget. If your content isn't something that could be redistributed on its own—which doesn't mean it has to be—it isn't an article.
Meanwhile, you can think of section as being more organizational or structural in nature. It's a generic document or application section that denotes a "thematic grouping of content," to quote the spec. So, when you use section you're saying, "This content is a section of the page" (when surrounding the news section, for example), "That content is a section of an article" (when nested in an article), or "That content is a section in a tabbed module" (each tab has its own section). It helps to keep the "thematic grouping" part of section's definition in mind. It's one of the reasons section is not only different than article, but also div, a generic container that conveys zero meaning about its contents.
There's still some subjectivity involved in deciding when to use article and section, and that's fine. It's true of some other elements, too. It just depends on how you personally categorize your content.