Add the <main>-Element to Modernizr 2.6.2

We don’t need this anymore

With Modernizr v2.7.0 we don’t need this work around anymore. Please update to this version if you use <main>.

tl;dr: You can add the new main-element to Modernizr 2.6.2 by using HTML5 Shiv’s window.html5 option to add your own elements to the shiv.

Since I use some bleeding edge stuff in HTML and CSS in actual projects for clients I ran into one particular issue a couple of times lately and I thought I share a little workaround with you.

Modernizr’s current state

Modernizr includes HTML5 Shiv to make HTML5 elements like header, figure and time known and styleable in old IE. Due to development for Modernizr version 3 the current version is Modernizr 2.6.2 which was published nearly a year ago (September 2012) when the main-element wasn’t around yet. Thus the version of HTML5 Shiv does not include a shiv for the main-element.

Today main is part of the HTML5 specification and is implemented in Chrome, Firefox and Safari Nightlies. You can read more about its value especially for semantics and accessibility on MDN and in a recent article at HTML5 Doctor.

The guys behind HTML5 Shiv included the main-element some time ago (you can learn more about the process of including some kind of default styling for the element in another HTML5 Shiv issue (thanks Mathias for the pointer)) and it is available in version 3.6.2. Sadly the latest stable version of Modernizr only includes version 3.6.1 of the shiv and there is no date set for a new release of Modernizr since everyone on the team tries to push version 3 to be out as soon as possible which will them include the new version of the shiv.

The Workaround

Until then we need to work around the missing shiv for the main-element (along with dialog and template).
Luckily it is possible to extend the list of elements HTML5 Shiv operates upon via its html5.elements option that we can use as needed.

First of all we need to create an object html5 on the window object and then add all elements that we want to be shiv’d.

window.html5 = {
  elements: 'abbr article aside audio bdi canvas data datalist details dialog ' +
      'figcaption figure footer header hgroup main mark meter nav output progress ' +
      'section summary template time video'

It is useful to take the list from the current version of the shiv to include all elements that need the shiv.

This code needs to be included before Modernizr is actually invoked so it might be useful to place it inline right before you insert Modernizr itself.

There is another way to include only specific elements like for example the main-element after Modernizr is already included:

window.html5.elements = 'main';
window.html5.shivDocument(document); // re-invoke the `shivDocument` method


This method is pretty straightforward and saves you a lot of time debugging or working around the inclusion of the main-element if you use Modernizr anyway.

HTML5 Boilerplate – v4.0.0

HTML5 Boilerplate is out with the new version 4.0.0.

There were some significant changes since the last version that are listed up in the changelog (also see below). Most of them because of the excellent work by Nicolas Gallagher – thanks for leading HTML5 Boilerplate with such great effort.

HTML5 Boilerplate v4.0.0 - Star

What’s new?

This was done throughout the last seven months of development and resolving bugs:

  • Add documentation in a separate folder – everything that is directly concerned with the project was moved from the wiki
  • Switch from Public Domain to MIT license
  • Separate Normalize.css from the rest of the CSS
  • Improve console.log protection
  • Replace hot pink text selection color with a neutral color
  • Nicolas introduced a better image replacement technique
  • Code format and consistency changes (<3!)
  • Remove superfluous inline comments
  • CSS file and JS files & subdirectories were renamed
  • Update to jQuery 1.8 and Modernizr 2.6.1.

From the Changelog

Sadly we could not integrate Grunt.js into the project with some simple tasks because we had to face certain problems when it comes to integrate the CSS file that is build by Grunt into the repository and other impediments.

Now HTML5 Boilerplate 4.0.0 is out and I’d encourage you to view the source, learn and contribute.
If you find bugs or potential pitfalls please let us know in the issues.
Cheers to the H5BP community and especially all HTML5 Boilerplate contributors.

Apart from HTML5 Boilerplate Alex Gibson, Nicolas and others updated Mobile Boilerplate to version 4.0.0, so go and check it out too!

And another thing: Both HTML5 Boilerplate and Mobile Boilerplate have a new website which looks kinda awesome, I think!

Download from GitHub

A Travel Through Time – and Back

Somehow… <time> Disappeared

As you might have heard the <time>-element was removed from the HTML5 specification last saturday by Ian “Hixie” Hickson, the editor of the spec. Hixie decided to remove <time> and replace it by the more general <data>-element.

A question that came up: Why got<time> removed and why did nobody stop Hixie?

Well: There Google+. Also we talked about this issue on the (german) podcast Working Draft on monday. I was invited by Christian “Schepp” Schäfer to discuss about some stuff with himself and Marc.

Steve Faulkner was the first one (for what I noticed) that tweeted about that intensively and was really upset by the dropping. Furthermore it was his tweet that encouraged me to keep track of the whole story.

Steve explained on the the mailing-list of the W3C why he likes to revert the changes made by Hixie the day before. Others also liked the time-element and requested a revert.

There were some pretty good blog posts about that topic, as for instance

As it turns out <time> is wildly in use all over the web:

  • the WordPress twentyeleven-theme uses it
  • The Boston Globe makes use of it
  • I’m using it on this page
  • And many others too…

As so many people where effected by the change that was made to the spec and many people though it was a bad decision there was hope that this story was not over yet… And it wasn’t.

Again Steve Faulkner tweeted:

“I feel confident that <time> will be back in the W3C HTML5 specification by the end of the week”

~ Steve Faulkner, 31. Oct 2011 via Twitter

This was a decent statement as you can say by today.
There were proposals on how to deal with <time> and how to improve it for the future and get it back into the spec. A leading role in this process is held by Tantek Çelik. Read his comment on Bruce Lawson’s post. Also Stephanie Sullivan Rewis has some interesting thoughts.

And then – the Turningpoint

Currently the TPAC 2011 is happening which is a conference and meeting of the W3C and its members.
At (Please notice my use of <time> in this case. Nice, right… right?) people of the W3C HTML Working Group met and discussed about <time> and its removal. You could have followed the discussion on IRC on W3C’s channel #html-wg. Here you can find the “minutes” (a transcription) of it. Tantek added this as a point for discussion to the Agenda.

As this all was said, there was a mail on the mailing-list by the Chairs of the HTML WG asking the editor of the spec (Hixie) “for a revert of this change to be completed no later than the end of day on Tuesday 8th of November”. If Hixie will not change this until Tuesday the Chairs will ask the W3C staff “to make this change”. What ever this means then… I have no idea.

Today Tantek began to define some new requirements for the <time>-element and its attribute datetime (especially the syntax of the mentioned attribute).

So what’s the conclusion now?

All the things I mentioned above show how strong the community is and how many people try to get the best out of the tools we have.

Hixie’s decision to remove the <time>-element in favor of the <data>-element was not found democratically by everyone contributing to the HTML5 spec but was a bossy behavior.

Personally I learnd a lot about the process within the W3C, the WHATWG, how the specification is build, and so on asf… This was pretty good and I feel good about how things work.

I hope there are more people who like keep a little bit more track of what is going on with all the new stuff and be part of decisions that are made.

Thank you for reading all the words I wrote.

Thank you Steve, Tantek, thank you Eric Eggers, Shelley Powers, thank you everyone who was able to do something about the odd removal of <time>. You guys rockkk!

Offer Files as Download with a@download

So the spec introduces a new attribute on a-tags (so called “links” – this may be new to you ;-)) called download (short: a@download – this technique of connecting attributes with tags is written up and documented by Mathias Bynens).

When you link to a file like an image or a PDF-document it will be displayed within the browser normally. The download-attribute in links prevents this behavior and offers the file as a download in your browser.


The spec allows the attribute for having a value. This value can be a string which defines the name of the downloaded file. As a default the browser takes the file’s original name.

And this is what it could look like in HTML:

<a href="path/to/file/file.png" download="a-nice-image.png">Download this file</a>

The value of the download-attribute overwrites the filename with a-nice-image.png.

The Content-Disposition-header can overwrite the name for the file.

This really nice demo exports a written text and offers it as download (but be aware of browser-support – see below).


The download-attribute is not supported very good at the moment of writing this article.
Chrome supports it since its version 14. Version 14 is only a view weeks away from the stable release.
Firefox 8alpha (Aurora-channel) does not support it as far as I experienced it. I did not find anything about any intensions when Mozilla will include it.
And the other ones? No support yet!

So, what’s the fallback?

There are other techniques to serve a file that will be offered as a downloads in the browser. For instance you can use an HTTP-Header that’s a mime-type that the browser does not know.

Here is an example with PHP:

header('Content-Type: application/force-download');
header('Content-Disposition: attachment; filename="some-file-name.ext"');

You should then open the download in a new window or tab, or in an iframe to prevent any stupid browser-behavior.

More about this issue here.

The Difference between Push and Pull

Push and Pull

You do know the nice message which is submitted to your smartphone when someone mentions you on Twitter?

iOS gets these messages via push. This means the server tells the app something like “Hey look, there’s something new on your Twitter-account”.
On Android this is done with push, too. It was introduced in version 2.1.0 in mid of July. Before this release they requested all Tweets via “pull”: The app asks the server “Yo server, somethin’ new here?”.


So where’s the difference besides the obvious?

  • with pull the app has to connect to the server in a certain time-interval
  • this means heigh power drain
  • it may take some time until you receive a message via pull*
  • push may hold an open connection to the server: more data is send

* Site note: I noticed that it also may take some time until a new message is delivered with push technology on iOS or Android (for Twitter-App). If anyone knows more on this issue please share your thoughts.

The way we do it today

If you’re coding an online app you have something where you’re displaying new messages or so. The known approach is to return asynchronously to the server via JavaScript and evaluate the answer. Something like this:

$.getJSON( 'messages.php' , function( data ) {
  // If there is a message
  if ( data.length &gt; 0 ) {
    $.each( data['msg'], function() {
      // Do some fancy stuff with messages…

This is “pull”. It is not enough to request the answer of this file once, because this would evaluate the data only once. This is why there has to be a kind of timed event which fires the request in an interval.

This is what it could like with an intervall of 1 minute:

! function pull_request() {
  $.getJSON( 'messages.php' , function( data ) {
    // If there is a message
    if ( data.length &gt; 0 ) {
      $.each( data['msg'], function() {
        // Do some fancy stuff with messages…
  window.setTimeout( function() {
  }, 1000 * 60 );
} ();

As you can see, there is an IIFE surrounding the code. I am doing this in order to call the timeout recursively. For more information please read Ben Almans article on this issue.

What else is possible

This will work totally fine. Let’s take a look at other possible ways.

The Wikipedia article about push sais:

Push technology, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server.

With HTML5 the WHATWG introduces The WebSocket API.

WebSocket API

The WebSocket API enables websites and apps to communicate with a server. A polyfill for browsers that do not support WebSocket and as a framework you should definitely check out Socket.IO.

There were some definitions of this API in the spec that had some security problems and so browser vendors implemented some stuff that is outdated by now. There is a kinda “last call” specification for this API which are already implemented in Chrome dev channel (version 14) and Firefox 7. The API is available with a current version of Webkit so it should be in Safari soon.

Server-Sent Events

Furthermore there is the Server-Sent Event which is dedicated to fulfill push notifications. The event is already supported in stable versions of Safari, Chrome, Firefox and Opera. See When Can I Use… for more information.

The Server-Sent Event is a DOM event and can be accessed via new EventSource( file ); in JavaScript, while file is a server-file which publishes the notification. With the onmessage-event it is possible to listen to the changes of notifications.

var source = new EventSource( 'messages.cgi' );
source.onmessage = function( e ) {
  // do something with the notification, e.g. log it in the console.
  console.log( );


With the given technologies it is possible to send notifications via push to the client-site. There are polyfills for “older” browsers (like pulling data). It is possible to use these tools today.

If you have any experience with the topic of pushing data, please share your thoughts and ideas in the comments.
Thanks for reading though.

I am going to develop a web-app with a friend of mine. We are using node.js for the server part. I am pretty exited to deal with it. We will definitely need something like a push event. We’ll see what will be best.

Read more and follow-up info:

  • Follow Ian Hickson on Twitter or Google+. He is the editor of the spec for Server-sent Events and The WebSocket API.
  • You should checkout the Modernizr Polyfill Wiki to get some information on polyfills for older browsers with WebSockets aso.