Making Sense of HTML5 with SharePoint: Hello World

If you’ve been following along with this series, you’ve probably been thinking “Great, but what can I do with HTML5 in SharePoint?” In other words ‘What’s in it for me?” Let’s take a look at a simple example.

First of all, as I mentioned in the last article, we need to make some modifications to the SharePoint master page so that we can take advantage of the HTML5 goodness. It actually gets a bit more complicated than just changing the doctype and a meta tag. Luckily, SharePoint design guru Kyle Schaeffer has done the hard work for us and has published v5, the Responsive HTML5 Master Page for SharePoint 2010. For this article (and probably many following articles), I’m going to use Kyle’s v5 master page to help leapfrog us into HTML5-land. You should be able to follow Kyle’s instructions pretty easily to get v5.master up and running in your environment. Remember that you should only use it in a test environment for this exercise, as there are many reasons why using the v5 master may not be a good idea for your production sites today.

Once you get v5.master installed, the home page of your site ought to look something like this:

image

I’m keeping the look that Kyle’s given us in v5.master as is because it’s distinctive looking and we can easily tell that we’re doing something different. In addition to getting a great HTML5 setup, v5.master also gives you a responsive design layout. As you start to think about how HTML5 and CSS3 might help you to provide SharePoint support for different screen sizes, responsive design is one approach you might consider. (We should really pause here to give Kyle a big hand; this is truly great work!)

So, we’ve got v5.master in place and we can now take advantage of HTML5. (I feel a little like Julia Child when she says “I just happen to have a completed soufflé right here in this other oven.”) In thinking about what a “Hello World” for HTML5 and SharePoint might be, I struggled a little. Regardless what I chose, there had to be some up front work (borrowing Kyle’s v5.master page gets me past that) and putting the words “Hello World” on the page doesn’t show any real HTML5 goodness. I think I’ve settled on something simple enough, yet useful enough, to prove that HTML5 can really make your pages sing, and more easily than using other methods.

One of the things we get with HTML5 is some new attributes for input elements. Input elements are the things we use in HTML to get input from the user. So, for instance, the Title column in any SharePoint list is rendered on the list forms as an input element that looks like this:

<input name="ctl00$m$g_3f366f7e_f974_479a_afcf_552d2de2688e$ctl00$ctl05$ctl00$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" title="Title" class="ms-long ms-spellcheck-true" id="ctl00_m_g_3f366f7e_f974_479a_afcf_552d2de2688e_ctl00_ctl05_ctl00_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" type="text" maxLength="255"/>

Once you get past the really long (and ugly) name and id attributes, the input element is pretty simple. It has a title attribute that contains the name of the column (‘Title”), a few CSS classes (“ms-long ms-spellcheck-true”), a type (“text”), and a maxLength (“255″). As far as HTML elements go, it’s about as straightforward as it gets.

Depending on your branding, the input element will render looking something like this. We’ve all seen it before.

Now, we’ve all visited sites where there is a helpful prompt inside the input element that tells us what we should plan to type into it.

It’s a great little mechanism to help a user to understand what they need to do next. We’ve all become very used to it and while we may not notice it after a while, it can lend a great assist. The nice thing about it is that the prompt text disappears when we put our cursor into the input element and it only reappears if we leave the element without typing a value.

SharePoint doesn’t give us this behavior out of the box, but we can make it happen with a little script.

var titleInput = $("input[title='Title']");
var promptText = "Please type a title for this item";

// When we click into the element, remove the prompt text if it is there
titleInput.click(function() {
  if($(this).val() == promptText) $(this).val("");
});

// When we leave the element, replace the prompt text if there is no value
titleInput.blur(function() {
  if($(this).val() == "") $(this).val(promptText);
});

// Set the initial prompt text if there's no value by triggering the blur event
titleInput.blur();

That’s not too complicated, yet it’s more complicated than it seems like it ought to be. I didn’t have an example lying around, so I decided to write it from scratch, which took me about ten minutes. I needed to think about the edge conditions (what if there’s a value but it’s not the promptText?)

So what does HTML5 gain us that makes this easier? Well, there’s a new attribute for the input element called “placeholder”. To get the behavior that I wanted above, I can simply do this:

$("input[title='Title']").prop("placeholder", "Please type a title for this item");

Now you may be saying “Wait a minute. You’re still writing script!” Indeed I am, but it’s only one line of script. The only reason I need to use script at all is that SharePoint doesn’t “know” anything about the placeholder attribute. (I could write managed code to modify the Title column across the board, but that would be tremendous overkill and may not even be what we want.) All the script is doing is adding the placeholder attribute to the input element, and HTML5 takes care of the rest and we get this in the active DOM:

<input name="ctl00$m$g_3f366f7e_f974_479a_afcf_552d2de2688e$ctl00$ctl05$ctl00$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" title="Title" class="ms-long ms-spellcheck-true" id="ctl00_m_g_3f366f7e_f974_479a_afcf_552d2de2688e_ctl00_ctl05_ctl00_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" type="text" maxLength="255" placeholder= "Please type a title for this item"/>

Well, HTML5 doesn’t actually do anything, but it tells the browser that it should do the prompt text thing. Unfortunately, Internet Explorer 9 doesn’t support the placeholder attribute yet (check the HTML5 Test again) so I had to run through this little exercise in Firefox.

And there’s the rub again. Since browsers don’t all behave the same yet, we have to consider which HTML5 capabilities we can use. Kyle’s v5.master loads HTML5 Shiv if the browser is IE < 9, but that doesn’t seem to fix it and I didn’t feel like monkeying with it to get it working in IE. In other words, there are still monsters here for those who are not wary.

So, there you go: a “Hello World” exercise, if you will. The real point (in case I didn’t make it well enough) is that HTML5 gives us easier ways to do some common tasks. In this case it’s a simple prompt in an input element, but there are more complex tasks (think playing videos, and more) that HTML5 will also make much easier. Stay tuned for more…

This post also appeared on NothingButSharePoint.com‘s EndUserSharePoint channel on 2012-04-18. Visit the post there to read additional comments.

2 Comments

  1. For me the most exciting aspects (prospects?) of HTML5 on sharepoint is the canvas element – being able to whip up snazzy clickable charts and graphs (although achievable with flot charts already) from list data.
    The other is cross-document messaging. Data could be passed from sharepoint pages to non-sharepoint web applications without having to involve xhr. IE9 supports these just fine. On another note IE9 has great support for the DOM right up to level 3, css3 support and a complete implementation of ecmascript edition 5 so the things it’s lacking in html5 support compared to other browsers mightn’t be as bad as it sounds. I think the future is really exciting with sharepoint and html5!

    Reply

Leave a Reply