SharePoint and HTML5 investigation (Part 2)

Method

The main MO is to create a masterpage for use on a specific platform/browser. I’ve created two but you could create any number to deliver the best experience for each platform. The two platforms I consider are:

• Browsers that (theoretically) support all the HTML5 functionality I’d like to use
• Browsers that don’t, but need to be supported. For example for the standard SharePoint edit page experience.

My solution consist of the following components (See image). The main idea is that, based on the browser's capabilities, the masterpage and the control on the page (layout) are switched to html5 or xhtml mode.

Masterpage switcher (Extended Publishing Page)

I’m using two masterpages: one for showing a fancy HTML5 page to browsers capable of handling it, and another standard XHTML masterpage for use with legacy browsers and for the edit mode. The switch between them needs to be done in the OnPreInit method of an extended PublishingPage that checks the browser's capabilities in order to decide which masterpage to use.

Browser check

Currently simply checks the browser from the Request.Browser property. This is done for simplicities' sake, the check can be very advanced. It can also set multiple properties like IsMobile, IsHTML5, etc. The UserAgentInfo class can also be used which gives advanced and up to date info on the browser used, so you can do serverside feature detection. See the article on JS libraries for feature detection as well.

HTML panel

This panel simply checks whether the page is in HTML5 mode or not and creates a html5 or div tag around it’s contents.
If the page is in HTML5 mode, it'll render for example <section></section>, if the page isn't it'll render <div class="section"></div>.


Next to this it has another feature. The panel will hide or show it's child webpartzones based on the page's mode (HTML5 or not) and an attribute of the webpartzone (IsHTML5). If the page is in edit mode it will show all webpartzones, but in display mode it shows only the webpartzones that are in the same HTML mode as the page. In this way you can add HTML5 content to one webpartzone and older version HTML to another zone in the panel and then it will only show the contents of the appropriate webpartzone. In this way it is unnecessary to create two display modes for each webpart, but you can target specific content at certain browsers/devices.

JS and CSS resources for specific platforms

There are different css+js resources used for the two masterpages. This improves simplicity of the solution and therefore makes it easier for web developers to create the styling and realize their interaction designs. Too many different masterpages would complicate this again of course, so keep the amount as limited as possible for example one for mobile, one for legacy and one for new browsers (just a thought).

Utilities and Definitions

Used for creating the right tags and other stuff.

MVC webpart (TO DO)

Because there are two different masterpages, one for legacy and one for HTML5 capable browsers, the webparts themselves (possibly) also need to render in two modes. Using a Model-View-Controller pattern the extra webpart development is minimized because only multiple views need to be created, while the controller and the model can be developed once. Also, since adding the feature to the HTML panel that it can display one webpartzone depending on the HTML state of the page, you could use an older, non-html5 webpart to display to legacy browsers, while showing a new html5 webpart to new browsers.



Continue to Part 3

Part 1 is about the background for the investigation on this subject, why HTML  5 + SharePoint.

Part 2 is about the work that was done, it contains links to the code and solution overview.

Part 3 is about the results that were found, and should get a discussion going on what can be improved and other possible paths to pursue.