HTML5 and Microsoft Developer Tools:
Beyond Microsoft’s involvement with the W3C and the HTML5 technologies supported in the browser, there’s another dimension to Microsoft’s approach to HTML5 that’s important for developers: its approach to HTML5 tooling.In early 2011, Microsoft updated two of its development tools with service packs: Visual Studio 2010 and Expression Web 4. The service packs for both of these tools provided an HTML5 document type for validation, as well as IntelliSense for new HTML5 tags and attributes. If you’re using Visual Studio 2010 SP1, you can enable the HTML5 Schema by clicking Tools | Options | Text Editor | HTML | Validation, and then selecting the HTML5 option in the Target drop-down list, as shown in Figure 1. You can also set HTML5 as the default schema from the HTML Source Editing Toolbar in any HTML file, as shown in Figure 2.
Figure 1 Enabling the HTML5 Schema via the Options Dialog
Figure 2 Setting the HTML5 Schema on the HTML Source Editing Toolbar
Once your default schema is set, you’ll gain IntelliSense support in Visual Studio for the 28 new semantic tags in HTML, as well as new tag-specific and global attributes, as show in Figure 3.
Figure 3 HTML5 IntelliSense in Visual Studio 2010 SP1
Microsoft further updated its HTML5 support with its release of the Web Standards Update for Microsoft Visual Studio 2010 SP1 in June 2011. This extension, which works with all editions of Visual Studio 2010, adds further HTML5 IntelliSense and validation to Visual Studio, includes JavaScript IntelliSense for new browser capabilities like Geolocation and DOM Storage, and provides comprehensive CSS3 IntelliSense and validation. You can download this extension, which will be regularly updated to provide enhanced tooling for HTML5 development, from bit.ly/m7OB13.
For Expression Web 4 SP1, setting the HTML5 schema under Tools | Page Options offers the same IntelliSense, and the tool also provides CSS3 IntelliSense for several draft CSS3 modules like border-radius, box-shadow, transform and the like.
If you’re using WebMatrix (see http://www.microsoft.com/web/webmatrix/next/), you may have noticed that all new .html, .cshtml or .vbhtml documents you create contain default markup similar to what’s shown in Figure 4. As I’ll discuss in the next article in this series, this is a basic, valid HTML5 document. Most notably, the doctype and meta charset tags have lost a lot of cruft. Using this simple doctype triggers HTML5 mode across all modern browsers, and WebMatrix makes it easier for you by providing an HTML5 document by default.
Figure 4 A Default HTML Document in WebMatrix
- <!DOCTYPE html>
- <html lang="en">
- <head>
- <meta charset="utf-8" />
- <title></title>
- </head>
- <body></body>
- </html>
The takeaway here is that even though HTML5 is just emerging in our browsers, official tool support is quickly being added, and Microsoft is even adding support for libraries (like Modernizr) from the community. You can target HTML5 with some help from Microsoft tools today, and expect that that HTML5 support will continue to grow and improve over time.
‘Adopting’ HTML5 in Your Applications
By now, you should realize that HTML5 isn’t a single entity that you can adopt or migrate to in one fell swoop. Adopting HTML5, rather than being a wholesale choice, is about making a technology-by-technology evaluation and determining which technologies are right for your application. For each HTML5 technology you evaluate, look at (at least) the following factors when deciding whether that technology is ready for you to adopt:- How widely implemented across all major browsers is the technology?
- How would you adopt this technology and “polyfill” support for browsers that don’t support a given feature?
However, even with that stable set of HTML5 technologies, you shouldn’t ignore your users who haven’t moved to a newer browser. If you’re heavily involved in the day-to-day development for your site, you no doubt have some rough idea of the percentages of users visiting your site with a given browser. For most of us, it would be easy to look at the percentage of users visiting with an older browser and come to the conclusion that adopting any HTML5 technologies would negatively impact those users. Luckily there’s “polyfilling” to save us from waiting until some foggy date in the future to adopt HTML5.
Paul Irish (a developer on the jQuery and Modernizr projects) defines a polyfill as “… a shim that mimics a future API, providing fallback functionality to older browsers.” A polyfill is like spackle for your Web sites; it’s a way to determine if a given HTML5 feature is available to the user currently browsing your site, and to provide either a shim that “fills in” that support or a course of graceful degradation that enables your site to still function fully.
The most popular library associated with polyfilling is Modernizr, the JavaScript library I mentioned earlier. Modernizr provides some basic polyfills for semantic markup, feature detection for major HTML5 technologies and support for conditional CSS based on supported features. As noted, Modernizr will be the subject of an upcoming article; it will also feature prominently (along with many other polyfilling libraries) throughout this series. To learn more, download Modernizr at modernizr.com.
When it comes to choosing which technologies to adopt, your final list may be a combination of widely supported specifications and other specifications for which you’ll have to polyfill support for certain browsers. Only you will know the exact makeup of that list based on your current needs and context.
In the coming months, I’ll discuss several notable specifications, from Geolocation and Forms and Canvas, to Web Workers, Web Sockets and IndexedDB. Some of these are widely supported and “site-ready,” and some, like Web Sockets, are too groundbreaking to ignore, regardless of where they stand today. With each specification, I’ll discuss current and known future support, some basics about how you can implement the specification’s features on your sites, and how to polyfill support for browsers that don’t support a given feature.
