Making Sense of HTML5 with SharePoint: Browser Capabilities
In my last article I talked about what HTML5 is and that it will help us get to a more “Semantic Web”, but I didn’t explain what the W3C standards really mean. Partly that’s because the process is long and drawn out and murky at best. When I talk about the HTML5 recommendations and standards, maybe I should put “recommendations” and “standards” in bold, flashing text. The word recommendation is closer to the mark. Take that and the fact that the HTML5 standards are in draft mode, and there’s a lot of loosey-goosy-ness to the whole thing. I’ve seen quite a few people saying that the HTML5 standard will be finalized in 2022, and they aren’t really joking. That’s about par for the course if we look at the life cycles of past HTML standards.
What all that means for browser capabilities is that they are basically all over the place. While each browser team wants to support HTML5 (at least if they want to be as cool as the other kids), they each have different priorities and interpretations of the standard.
The HTML5 Test
One good way to understand what this all adds up to is to look at a site that I found called The HTML5 Test. It’s not the only site out there that will tell you how your browser stacks up, but I like the way it gives an overall score and then breaks things out into easy to understand sections.
Because of my consulting work, and even more because of my SPServices development work, I have most of the major browsers on my laptop. Here’s how the versions of each browser I have stack up on The HTML5 Test:
| Internet Explorer 9 Version: 9.0.8112.16421 |
 |
| Firefox 11 Version 11.0 |
 |
| Safari 5 Version 5.1.5 (7534.55.3) |
 |
| Chrome 18 Version 18.0.1025.142 m |
 |
| Opera 11 Version 11.62 Build 1347 |
 |
While it may seem just like a gratuitous way to add a bunch of images to this article to make it longer, I thought it was interesting enough to include the details. As you can see, the scores are all over the place, and none of them are all that close to the maximum of 475. (If you have an eye for this sort of thing, you’ll note that even these snapshot images don’t look exactly the same, though they should.) Worst of all, our dear old friend IE9 scores the lowest. If you dig into the details of the scores, you’ll see that the variations are even harder to think through.
What this tells us is the we have to be very careful to understand what our browser base is for SharePoint if we want to take advantage of the goodness that HTML5 provides. (This is true of any so-called “front end” development that you do – you simply *must* know your browser targets and have good strategies to deal with them all.) I haven’t been able to find any typical browser distribution statistics for SharePoint on the Interwebs, but SharePoint itself can tell you what browsers are visiting your installation if you look at the Web Analytics statistics.
If you are lucky enough to be building your solutions in an organization where the supported browser base is proscriptive (e.g., everyone *must* use IE8 or Firefox 11 or something) then your job may be a little bit easier. However, as the BYOD movement takes hold, even that luxury is eroding. On the other hand, if you’re developing for an Internet site, then all bets are off. You’ll see everything from IE6 to Netscape to Opera to IE10 Beta and back again.
SharePoint and Browser Support
SharePoint 2010 itself, while it can be used with just about any browser, is really primed for Internet Explorer. If you look at the out of the box v4.master page, you’ll find several strong indications of this. In fact, these are the two first things you’ll need to change to start using HTML5 in SharePoint.
First, there’s the DOCTYPE.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
This doctype tells browsers which standard to adhere to. In this case, it’s the XHTML 1.0 Strict standard. This setting precludes us from getting any HTML5 goodness. To enable HTML5, it’s a simple matter of changing the doctype to the simpler:
<!DOCTYPE html>
Next, the v4.master page has a meta tag in the header which forces Internet Explorer into IE8 mode:
<meta http-equiv="X-UA-Compatible" content="IE=8"/>
To allow IE9 to flex the HTML5 muscles that it *does* have, you can change this to:
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
So Now What?
As I noted above, even IE9 doesn’t score all that well on The HTML5 Test. So how can we try to take advantage of HTML5 until Internet Explorer and all of the other browsers catch up to the moving target that is the HTML5 standard?
Well, luckily, there are people out there who understand these issues well and they have written some things that can help.The most well-known option is something called Modernizr.
Modernizr is an open-source JavaScript library that helps you build the next generation of HTML5 and CSS3-powered websites.
Modernizer falls into the class of software known as “shims”. Shims let us use functionality which isn’t there for us yet by mimicking that functionality in a different way or otherwise filling in the gaps. Or, in geekspeak from Wikipedia:
In computer programming, a shim (from shim) or shiv is a small library that transparently intercepts an API and changes the parameters passed, handles the operation itself, or redirects the operation elsewhere. Shims typically come about when the behavior of an API changes, thereby causing compatibility issues for older applications which still rely on the older functionality. In such cases, the older API can still be supported by a thin compatibility layer on top of the newer code. Shims can also be used for running programs on different software platforms than they were developed for.
Once the browsers catch up, the shim won’t need to do as much and eventually we’ll be able to get rid of it. (Don’t hold your breath – 2022 is a long way off.)
You can reference Modernizr in your master page to take advantage of HTML5 functionality that the browsers doesn’t yet provide. It’s not a silver bullet, of course. You still need to understand your target browser base and think about how you are going to use the new standards to get the best results. Knowing where in all that the shim is going to support you is key.
I’m not going to go into anything specific that Modernizr can help with in this article, but I will touch upon useful capabilities it provides as we see how we can use HTML5 in SharePoint as we go along.
Don’t worry; cool demo stuff is coming. I just think that we should understand the basics first.
Resources
- The HTML5 Test
- Understand Top Browser statistics in SharePoint 2010 Web Analytics by Wictor Wilén (@wictor)
- HTML5 and SharePoint 2010 (and the IE9 Beta) by Randy Drisgill (@drisgill)
- Modernizr
I would use the EDGE value in the Meta tag, as follows:
Why? If you leave it at IE=9, then when IE 10 comes out, IE 10 will only render it like IE 9, and will not able to use whatever nifty html 5 capabilities are native to it.
Reference is here:
http://msdn.microsoft.com/en-us/library/ie/cc288325(v=vs.85).aspx
Scott:
Fair point. I decided to err on the side of caution, as many SharePoint admins and developers want to know exactly what’s going on. We also have no way of knowing what silliness IE10 might introduce. For many organizations, it’ll be another round of testing prior to roll out.
M.