Appendix M. Browser Support as of March 2013

Documenting feature implementation in browsers means aiming at a moving target, so the best I can do is take a snapshot. When considering whether to use one of the features in this book, always check the following sites for the most up-to-date information:

• HTML5 Please, http://html5please.com/

• The CSS3 Test, http://css3test.com/

• The HTML5 Test, http://html5test.com/

• Can I Use…, http://caniuse.com/

When I started this book midway through 2012, I took a gamble on which features I thought would be best to cover, including not only those that had already been well implemented but also some that I thought stood a good chance of being implemented when the book went to print (or soon after). As I write this in early 2013, it seems that the pace of wider adoption has been slower than I anticipated for some of the features contained in Internet Explorer 10 (such as Grid Layout, Regions, and Exclusions), but everything else is proceeding apace.

The Browsers in Question

Far too many browsers exist for me to provide a decent overview of feature support on each. Instead, in this appendix, I’ll stick to the key modern desktop browsers—Chrome, Firefox, Internet Explorer 10, and Safari—and their mobile equivalents, as I’ve done throughout this book.

As this book was going to press, Opera announced that it would be phasing out its own Presto rendering engine and that future versions of the browser would instead use Chromium, the branch of WebKit that Chrome is also based on. But that doesn’t mean Presto will be going away in the short term—it’s already embedded on many devices that don’t tend to update, such as TVs and games consoles. In the long term, feature support should be considered the same as Chrome, but I’ve kept it distinct here for legacy support.

When discussing mobile browsers, I usually mean both smartphone and tablet and, more often than not, that means Safari mobile and the Android browser (although both are based on WebKit, there’s quite a deal of variety between them). Firefox, Internet Explorer, and Opera use the same rendering engine across different platforms (although see the previous paragraph about Opera), so I’ll only mention the mobile version of those browsers where any differences exist (which is not often).

When I refer to Android, I mean the stock browser that comes with most versions of the Android OS up to 4.2 (the most recent as I write this). Newer releases will likely include the new mobile version of Chrome, which, like Firefox and Opera, can be considered more or less equivalent to its desktop sibling.

As I’ve mentioned before, there really is no substitute for testing on actual devices. If possible, you should create a device library or join one in your area; if that’s completely out of the question, ask other developers for their experiences.

Enabling Experimental Features

Many browsers, especially Chrome and Firefox, are being much more cautious than they used to be with regard to implementing experimental features. Where previously they would implement features with a vendor prefix and roll them out to all users, now they usually require that you explicitly enable certain features with a configuration flag.

In Firefox, you do this by entering about:config in the URL bar, at which point you’ll see a message that warns you of the consequences of dabbling in the browser’s inner workings. If this doesn’t deter you, you can find the feature you want and enable it before restarting your browser in order to gain access to the now-enabled feature.

In Chrome, the process is much the same except that you enter chrome://flags, no warning message appears, and the features are usually enabled by toggling a link marked Enable.

Chapter 1: The Web Platform

Every major modern desktop browser comes with a set of developer tools that includes a console (only Internet Explorer 7 and below don’t have one). The situation on mobile devices and tablets is a bit more complicated: Most browsers don’t have developer tools by default, but they can be connected to their desktop equivalents for debugging, as explained in Test and Test and Test Some More.

Chapter 2: Structure and Semantics

The newer HTML5 structuring elements appear in Internet Explorer 9 and above and in all other major modern browsers. Discussion around some of these elements is still ongoing as I write this. Some browsers are beginning to support a main element despite opposition from spec editor Ian Hickson, whereas other elements such as hgroup are at risk of being dropped.

Using the attribute-based accessibility and semantic extensions WAI-ARIA, microformats, RDFa, and microdata in any browser is completely safe. The microdata API is implemented in Firefox and Opera.

Data attributes are also supported in all browsers, although the API using dataset is not present in Internet Explorer or Android 2.3 and below. The jQuery method works cross browser.

Chapter 3: Device-Responsive CSS

As I write this, media queries are available in Internet Explorer 9 and above and in all other major modern browsers. The media features related to device dimensions are the most widely implemented. The resolution media feature is in Internet Explorer 10, Firefox, and Opera and was implemented in the WebKit core at the end of 2012, so it’s making its way into WebKit-based browsers.

The dppx unit should be in all modern browsers bar Internet Explorer by the time you read this, and devicePixelRatio is in WebKit browsers, Opera, and Firefox (including mobile versions).

The @viewport at-rule is in Opera, Internet Explorer 10, and WebKit, using the vendor prefix of each. The matchMedia API is in Internet Explorer 10 and all other modern browsers but not in Android 2.3 and below.

The CSS property box-sizing is in all browsers, although it requires a vendor prefix in Firefox and versions 3.0 and below of Android. Only Firefox supports the padding-box value. The calc() value function is in IE9 and above, Firefox, desktop WebKit browsers, and from version 6.0 of mobile Safari. It’s not in Android or Opera and requires the -webkit- prefix in other mobile WebKit browsers.

The viewport-relative length units—vh, vw, etc.—are in IE9 (with a few bugs) and IE10, Firefox, and most WebKit browsers except Android, but not present in Opera. The rem unit is in IE9 and above and all other major browsers.

The object-fit and object-position properties are implemented in Opera only and marked as “at risk” in the spec, so face an uncertain future, especially now that Opera is moving to use WebKit.

Chapter 4: New Approaches to CSS Layouts

The multi-column layout properties are implemented in IE10 and all other modern browsers. The use of vendor prefixes is required in WebKit-based browsers and Firefox, and Firefox also lacks support for the column-span property. Only Opera and IE10 support the break-before and break-after properties.

Flexbox is supported in all major browsers and requires a vendor prefix in WebKit-based user agents. IOS6.1 and below use a hybrid of the current syntax and an older one: The justify-content property isn’t implemented, and it instead has the old box-pack property. I hope this will no longer be the case when you read this appendix.

IE10 also uses an outdated syntax, fully vendor prefixed. I recommend you read the documentation in the “Internet Explorer 10 Guide for Developers” for detailed information: http://msdn.microsoft.com/library/ie/hh673531%28v=vs.85%29.aspx/.

Firefox supports only single-line Flexbox, so the flex-wrap property and flex-flow shorthand property are ignored.

As explained in Chapter 4, IE10 is the only browser to support Grid Layout, using an older version of the syntax with the -ms- prefix. Work is underway on implementing this in WebKit, which should use the spec-compliant syntax. The grid-template property is not currently implemented in any browser.

Chapter 5: Modern JavaScript

The async attribute is in IE10 and most other browsers other than Android versions 2.3 and below and Opera. The defer attribute is the same but also has support at least back to IE8.

The addEventListener() method is in IE9 and above and all other major browsers, as is the DOMContentLoaded event.

Despite the uncertainty around existing patents, touch events are in Chrome, Firefox, Safari for iOS, and Android. IE10 has support for pointer events, such as MSPointerDown, which are vendor prefixed.

The querySelector() and querySelectorAll() methods are fully implemented in all modern browsers, from IE8 and higher. The getElementsByClassName() method is almost as well implemented, lacking support only in IE8. The classList object is in IE10 and above, and most other browsers except for Android version 2.3 and below.

Chapter 6: Device APIs

The Geolocation API is in IE9 and all other major browsers. Device orientation is present in mobile WebKit browsers, Chrome, and Firefox mobile. Do bear in mind, however, that device APIs depend on certain functions being available on the phone; just because the Device Orientation API is implemented in a browser, it doesn’t necessarily follow that the device has an accelerometer.

Opera has implemented the Full Screen API, as have desktop WebKit browsers, Chrome for Android, and Firefox. The WebKit and Firefox implementations have some subtle differences, but rather than trying to explain those here, I’ll refer you to the MDN article “Using Fullscreen Mode” at https://developer.mozilla.org/docs/DOM/Using_fullscreen_mode/. Firefox and WebKit browsers support the :-moz-full-screen and :-webkit-full-screen pseudo-classes, respectively.

The Vibration, Battery Status, and Network Information APIs are available in Firefox mobile only. Despite support for each apparently landing in WebKit throughout 2012, I can’t find any working implementations.

The getUserMedia() method is implemented in Opera, and in Firefox and Chrome with vendor prefixes (mozGetUserMedia, webkitGetUserMedia). Firefox currently requires that you opt in to use getUserMedia() with the media.navigator.enabled flag because of its experimental nature.

Web Storage is in IE8 and above and all other major browsers.

The Drag and Drop API is partially supported in IE8 and IE9, and fully implemented in IE10 and other major desktop browsers. Owing to its nature, it isn’t supported in mobile browsers.

The File API is fully implemented in Firefox, Chrome, Safari (iOS and desktop), and Opera, and partially supported in IE10 and Android. The FileReader API is fully implemented in IE10 and all other desktop browsers, plus WebKit mobile browsers including Android from version 3.0.

Chapter 7: Images and Graphics

Some form of SVG support is present in IE9 and above, Android 3.0 and above, and all other major browsers. SVG filters are slightly more limited, being unavailable in IE9 and Android, although using SVG filters on HTML elements works reliably only in Firefox. The new CSS filter() function is currently implemented in nightly Chrome builds, but it is disabled by default. The use of fragment identifiers in SVG is possible only in IE10 and Firefox.

Support for the canvas element is in IE9 and above and all other major browsers. Firefox, Chrome, Safari (desktop), and Opera all have implementations of WebGL, although it’s disabled by default in some browsers, notably Safari and Chrome for Android.

Chapter 8: New Forms

Levels of support for the various form elements, especially those with on-screen controls, vary wildly among browsers and are changing all the time. Rather than try to capture that here, I’ll refer you to the HTML5 Test, which has the most comprehensive and up-to-date coverage. Using the new input types is generally considered safe, as the browser will fall back to the text type if a different value is not recognized.

The Constraint Validation API is present in IE10 and all other major browsers. Safari supports the API but has no on-screen error notifications.

Chapter 9: Multimedia

The video and audio elements, along with their related APIs, are in IE9 and above and all other major browsers, although with the caveat about supported file types discussed in Chapter 9. The track element is supported in the desktop versions of IE10, Safari 6 and above, Chrome, and Opera; Chrome for Android is the only mobile browser to offer support. Media Fragments are implemented in Firefox and WebKit browsers.

The Web Audio API is experimentally implemented in Chrome and Safari (iOS and desktop) using the webkitAudioContext() constructor. Of WebRTC, only the getUserMedia() method is currently supported, which was mentioned in Chapter 6.

Chapter 10: Web Apps

Support for AppCache is present in IE10 and all other major browsers.

Chapter 11: The Future

Chrome is the only browser to have any support for the new Web Components features; it has implemented the Shadow DOM (with the vendor-prefixed webkitShadowRoot() constructor) and templates. Both must be explicitly enabled. Work on custom elements is underway.

As far as I know, no other browser vendors have committed to implementing Web Components yet, although I understand that Firefox will in the future. Firefox already has support for scoped styles, as does Chrome.

CSS Regions are implemented in IE10 and Chrome, although, once again, the latter currently requires that you enable it using a flag. Both require vendor prefixes on the properties, and IE10 allows only content inside an iframe as the source.

Exclusions are available exclusively in IE10, using the -ms- prefix.

The feature queries @supports at-rule is available in Firefox and Opera, and Firefox also recognizes the CSS.supports() method. Work is underway to bring them to WebKit browsers and may already be in place as you read this.

Cascading Variables are implemented in Chrome only and must be explicitly enabled.