How and Why to Start Using HTML5 and CSS3 Now: An Interview with Bruce Hyslop
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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/).
Unrelated to forms, I'm also a fan of data-* attributes, a really handy addition to HTML5 for associating small bits of data with elements for JavaScript manipulation.
Simplified syntax
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.
APIs
Once you've achieved a level of comfort with JavaScript and building sites, you can venture into the APIs and discover other exciting parts of HTML5 beyond the semantic elements and media playback. The Offline Web applications feature with its ApplicationCache (AppCache) API is great because it allows you to make a site work even if the user isn't connected to the Internet, and to control cache updates. You can do this for a simple site or a full-blown web application. It provides benefits if you're browsing online, too, because a browser will pull a file from the cache if it exists, instead of from the server.
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:
• box-shadow
• 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.)
Before these CSS3 properties existed, we had to resort to a slew of solutions (or perhaps, "solutions") to achieve similar effects. Most of the approaches were image-based or—worse—required Flash, and sometimes involved extra HTML markup or JavaScript. Even though they could help a site's design, they usually felt a little dirty to use, and they made your pages heavier. So, handling effects like these is not only easier with CSS3, but also typically speeds up your pages (provided you don't abuse some of them). Of course, CSS3 media queries are hugely useful, too, given their role in implementing techniques like Responsive Web Design for building one site for a wide variety of devices. Not coincidentally, the book focuses on these and a few other popular new CSS3 features that hopefully beginning readers would want to use the most.
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.
Similarly, I encourage people to use the new HTML5 elements like header, footer, nav, article, section, aside, figure, and so on, with the caveat that you can't style them in IE8 and prior without using a bit of JavaScript to make those browsers recognize them. The easiest way to do this is to include in your pages the script known alternatively as the "HTML5 shiv" or "HTML5 shim"; see http://code.google.com/p/html5shiv/. This does mean your pages may not look quite as intended if a user visits your site with JavaScript turned off in IE8 or prior. This usually represents a very small percentage of users. At the same time, I advocate looking out for all users to the greatest extent you can. A page doesn't have to look the same when JS is off, as long as it's usable and presentable. If you'd like, you can avoid writing CSS that targets these HTML5 elements directly in order to minimize the "no JS" effect; there are related techniques you can find online. And if you or your clients are uncomfortable with this condition, you can always use divs as the containers where you'd otherwise use new HTML5 elements. These instances probably won't arise often, though.
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.
I think it's important for potential readers to know some of what the book doesn't cover, too, so they can be sure to invest in books that best suit their needs. For instance, it doesn't show you how to use the HTML5 canvas element or JavaScript APIs, advanced topics that demand having more experience than our main audience (who, for one, aren't expected to know JavaScript at all). Among the new features CSS3 has to offer, the book focuses on some of the ones beginning readers may find the most useful today, given CSS3 — even just the new stuff of it — could fill a book by itself. There are some great books like Introducing HTML5, Stunning CSS3, and The Book of CSS3 that focus solely on the new parts of HTML5, including canvas and the APIs, or only the new things in CSS3, including in-progress and experimental stuff. Books like those are great for readers with prior experience, which is their target. The HTML5 and CSS3 VQS serves a different audience and purpose.
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.
Ian: Even though you don't cover them in the book, what do you think of the addition of transforms, transitions and animations to CSS3? Do you think that they have a place in CSS or that such functionality should be left to JavaScript?
Bruce: I think they're a great addition and do think they have a place in CSS, though I understand why some feel they creep into the realm of behavior (JavaScript's traditional role) or stretch the idea of what is meant by presentation (CSS' traditional role) in some cases. But, I think it's healthy to be flexible in our thinking, particularly if it leads to or supports innovations that are ultimately beneficial, which, of course, can be a matter of opinion, too.
There are a few practical reasons I think they have a place in CSS. One reason is these effects become accessible to a wider audience of people building sites, namely those who don't know JavaScript or who are a little intimidated by it. Some find the CSS syntax more approachable. Of course, those who wish to handle these effects with JavaScript can continue to do so. Though, as I'll explain next, sometimes they may benefit from going the CSS route.
Another reason is you can reduce the time it takes for your page to load and render by defining them in CSS. JavaScript is one of our biggest enemies in this regard. If you just want to enhance the look and feel of your site with a few subtle transforms or other effects, it's overkill to load a JS file or files, particularly considering most people will likely include a whole library like jQuery. It's true there are methods to minimize the impact of loading JS, but the everyday person building a site probably doesn't know about them, and it's still some extra overhead. Why not avoid it if you can? Mobile device users stand to benefit even more from these effects being in CSS, because, of course, their connections tend to be slower. It's commonplace for mobile users to browse the so-called "desktop version" of sites, which tend to be heavy enough as it is. So, now more than ever, it's incumbent on us as site builders to make our sites load as efficiently as possible. Keeping JS to a minimum is one way to do so.
Lastly, CSS transforms, transitions and animations will often perform better—they may appear smoother and more natural to the eye. I should mention, though, that standards folks and browser vendors have made efforts toward improving JavaScript-driven animations by introducing the likes of the requestAnimationFrame API.
Those are the main reasons I think they have a place in CSS and why they are good tools to have at our disposal. It's not an either/or situation, though. There are times when JavaScript will be the right tool for the job. And, if you'd like, you can use JavaScript as the fallback solution for browsers that don't support CSS transforms, transitions, and animations. So, there's room for both.
Ian: Some of the new features in HTML5 are JavaScript APIs, which aren't covered in this book. Why did you make that decision?
Bruce: The APIs are a great addition and push browser capabilities forward several leaps. The decision not to cover them, though, was almost entirely based on considering the book's beginner-level audience. As I touched on briefly, learning and taking advantage of the JavaScript APIs demands having a good amount of experience under your belt, such as with JavaScript itself. The books that do cover the APIs quite understandably tend to jump right into them without explaining how to write JavaScript, because they can assume readers already know it. Our book can't make that assumption and also doesn't teach JavaScript, because it's a huge topic of its own. So, the book focuses on the parts of HTML5 that the target audience can use. Hopefully, readers will go on to learn JavaScript and explore the APIs.