Older browsers that are still widely used by end users (namely IE6/7/8) do not have support for the new elements in HTML5. Now that we decided to go HTML5 for D8, it would be nice if Drupal played nice with those browsers too.
One great way to enable HTML5 element support in IE6/7/8 is to have the http://code.google.com/p/html5shiv/ added to Drupal core. This is a very small script that allows people to use the new HTML5 elements such as section, article, header, footer and so on.
Reasons for html5shiv as a candidate for inclusion:
1. To allow us to use all the new HTML5 elements in D8
2. Support contrib HTML5 themes out of the box without them having to pull the script from google code, which almost all D7 HTML5 themes are currently doing.
#963832: Decide how to use HTML5 in Drupal 8
#1077356: HTML5 in core battle plan
#1256132: Add innerShiv to core (after HTML5shiv is in) (might be redundant if jQuery 1.7 or latest gets in core - see more about it bellow)
#474684: dependencies for themes, so they can depend on modules (which might allow having this -or any other polyfill- as a separate core module that people can enable/disable as required)
#865536: drupal_add_js() is missing the 'browsers' option tries to tackle conditional loading of js. This will in turn allow this or any other polyfill we choose to be loaded only when required (IOW when browser = IE6/7/8).
modernizr as an alternative polyfill
People mentioned/suggested using Modernizr as an alternative polyfill. There's a contrib project with a D6 and a D7 version available. Its 7.x-3.x branch allows #1278504: Call Modernizr.load() from theme .info files. Jacine provides a comparison between the two polyfills in #73.
HTML5 element support & jQuery
jQuery seems to aim to add HTML5 element support in its upcoming 1.7 version:
1. Events rewrite (unifying bind/live/delegate, fixing bubbling)
2. HTML5 element support
...their roadmap doesn't clarify though whether they actually mean that they will allow older browsers to support HTML5 elements (what html5shiv/modernizr do) or if they simply mean to support HTML5 elements selection *if* the browser already supports their rendering. With regards to that, there's this bug in jQuery's issue queue we should be keeping an eye on.
jQuery 1.7 won't come with it's own built-in HTML5 shivs (you'll still have to load in a shiv of choice into the document head), but it will address two important issues previous releases have suffered:
1) In jQuery 1.6.4 and below, HTML5 elements were not supported with innerHTML but this is rectified with the newest release. HTML5 elements now added with any methods using innerHTML under the hood are added to a successfully shim'd document or document fragment as one would expect.
2) HTML5 elements being cloned (when an element is cloneNode'd) will now use an alternative approach to cloning which supports cloning HTML5 elements cross browser.
html5shiv is MIT licensed, so we either need an exception to be included or request developers to dual-license it under GPL as well. It is now dual-licensed under GPL v2 after Jacine took care of contacting the developers a bout it (see #68 and #69).
#139 has a patch. This issue is no longer postponed because of the drupal_add_js issue with no support for the browser options (thats been fixed).
User interface changes
Original report by Jeff Burnz
[...original text is (mostly unchanged) included in the issue summary - just split and placed in the appropriate sections, so omitted here in order to keep the summary as short as possible...]