HTML5 canvas cheatsheet

Our colleague, Colin Cieloha, American author and content marketer at recommended the HTML5 canvas cheatsheet developed by his company (and embedded below).

Colin Cieloha

Colin writes about everything that will draw his attention with a focus on the mobile and e-commerce space.  When he is not writing he is spending his time traveling the globe and snowboarding.  You can follow him on his Twitter at @ColinCieloha or on Linkedin. We asked Colin a number of questions about this resource. Details are below.

Become a Canvas Master with this HTML5 Cheat Sheet by has released a new cheat sheet that enables new and experienced web developers alike to create original illustrations and animations. With the use of HTML5 advanced technology, coding enthusiasts of all experience levels are able to read and use this cheat sheet to create impressive designs. Canvas can also respond to all the usual JavaScript events, like clicking and keyboard commands and button clicks, so it’s even easier to use. Here we will explore the benefits of using the Canvas cheat sheet and how Canvas holds up against traditional Camel Case. It’s sure to save you time, effort, and headache.

Why is it important for web professionals to know/ use this cheat sheet?

It saves time! Instead of having to remember all the coding or search for individual codes, an HTML cheat sheet provides all of the most used codes in one easy place. There’s a lot to be said for having all of that extra effort minimized, the common codes are just a click of your bookmarks away. This is convenient for those freelance designers that are in a time crunch as this allows them to complete their work faster and reach deadlines.

Why should they be focused on canvas now?

Canvas technology is amazing because it’s super easy to use. For example, Canvas can draw colorful text to help your message pop on the screen – and you can even animate it! HTML <canvas> objects can move, too, whether it’s just a few bouncing balls or an intricate animation that tells a story. For designers interested in gaming software, the <canvas> element is a brilliant choice for building characters, worlds, and then setting it all into motion.

Canvas isn’t magic (close, but not magic). You’ll still need a basic understanding of HTML and JavaScript to make these codes work for you the way you want, but the <canvas> element is simple and easy to use. The HTML <canvas> element’s purpose is to create graphics, according to lines of script, but it’s only a container. The <canvas> element draws paths, boxes, circles, text, and helps you to create images. It also provides the user with graphs and charts to order their graphic data designs. To draw graphics, Canvas uses a JavaScript context object, which makes it easy and fast to create graphics in your design.

The <canvas> element runs into some trouble with older browsers, however, and may not be supported. Canvas is, however, supported in all recent versions of all major browsers, so as long as your browser is updated, Canvas should work just fine. Canvas’s default size is three hundred pixels by one hundred and fifty pixels, width and height respectively, but is customizable. You can adjust the size of the canvas by using the HTML height and width property in the program.

With Canvas, function names are short and easy to recognize, unlike functions written in CamelCase. Identifiers in CamelCase often require lowercase where it would be more convenient to use all caps. For example, acronyms. It’s much easier to identify a function, if acronyms like HTML or SQL are written in full capitalization, but CamelCase sometimes negates this convenience.

This causes a serious headache for designers when two acronyms need to be side by side in a line of script: “parse DBM XML” would become “parseDBMXML” or when the function starts with an acronym, like “SQL server” (which the designer would be forced to convert to “sQLServer”). Even if a programmer considers acronyms lower case words and writes “oldHtmlFile”, “parseDbmXml” or “sqlServer”, it causes a mess because it makes it difficult to discern if it an acronym or not. Best case scenario, the designer wastes time.  The worst case scenario, they make a mistake and now must comb through complicated lines of script to amend the problem.


Hopefully this sheds light on the massive benefits of the Canvas cheat sheet. Using this cheat sheet will save you time and help you to become a more efficient programmer, web designer, or even help you gain more solid experience as a beginner in this field. I encourage you to go check out‘s Canvas cheat sheet below and begin to create using their helpful, easy to read codes. Have fun creating and I hope this saves you more time!

The post HTML5 canvas cheatsheet appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Font preloading for HTML5 games

In game development there are two methods of rendering text: via bitmap fonts and vector fonts. Bitmap fonts are essentially a sprite sheet image that contains all the characters of a given font. The sprite sheet uses a regular font file (traditionally .ttf). How does this apply to game development on the Web and HTML5 games?

You can use bitmap fonts as usual – they are just images, after all, and most HTML 5 game engines or libraries support them straight away. For vector font rendering, we can rely on any font that is accessible via CSS: this includes both system fonts already present in the player’s computer (like Arial or Times New Roman), or Web Fonts, which can be downloaded on the fly, if they are not already present in the system.

However, not all game engines or frameworks include mechanisms to load these fonts as regular assets –like images or audio files – and rely on them being present already. This can lead to quirks in which the game tries to render a text in a font that is not loaded yet… Instead, the player will get no text, or text rendered with an alternate or default font.

In this article we will explore some techniques for preloading Web Fonts into our games, and describe how to integrate them with a popular 2D game framework: Phaser.

How Web Font loading works

There are two ways of loading a Web Font: via CSS (using @font-face) or via JavaScript (using the Font Loading API). The CSS solution has been available for some time; while the JavaScript API is not widely adopted yet by browsers. If you want to release a game these days, we recommend the CSS method for its portability.

Declaration with @font-face

This is simply a declaration in your CSS code that allows you to set up a font family and point to the places where it can be fetched. In this snippet we declare a font family named Amatica SC, and assume that we have a TTF file as an asset.

@font-face {
  font-family: 'Amatica SC';
  font-style: normal;
  font-weight: 400;
  src: local('Amatica SC'),
       url(fonts/amaticasc-regular.ttf) format('truetype');

Note: In addition to pointing to specific files, we can also point to font names that might be installed in the user’s computer (in this case, Amatica SC or AmaticaSC-Regular).

Actual loading

It’s important to remember that declaring a font family via CSS does not load the font! The font is loaded only when the browser detects for the first time that it’s going to be used.

This can cause a visual glitch: either the text is rendered with a default font and then changes to the Web Font (this is known as FOUT or Flash Of Unstyled Text); or the text isn’t rendered at all and remains invisible until the font becomes available. In websites this is usually not a big deal, but in games (Canvas/WebGL) we don’t get the automatic browser re-rendering when the font is available! So if we try to render the text and the font is not available, it is a big deal.

So we need to actually download the font before we try to use it in our game…

How to force a Web Font download

The CSS Font Loading API

The JavaScript API does force a font to load. As of today, it only works on Firefox, Chrome, and Opera (you can check for the most up-to-date font-loading support information in

Note that when using FontFaceSet, you still need to declare your fonts somewhere –in this case, with @font-face in the CSS.

Typekit’s Web Font Loader

This is an open-source loader developed by TypeKit and Google – you can check out the Web Font Loader repository in Github. It can load self-hosted fonts, as well as fonts from popular repositories like Typekit, Google Fonts, etc.

In the following snippet we will load Amatica SC directly from Google Fonts and specify a callback function – to render text in a 2D canvas– that will be invoked when the fonts are loaded and ready for use:

FontFace Observer library

FontFace Observer is another open-source loader that doesn’t contain ad-hoc code for common font repositories. If you are self-hosting your fonts, this might be a better choice than Typekit’s since it is a lighter-weight file size.

This library uses a Promise interface – but don’t worry, there’s a version with a polyfill if you need to support older browsers. Here again, you need to declare your fonts via CSS as well, so the library knows where to go to fetch them:

Integrating font loading in Phaser

Now that we’ve seen how to load Web Fonts in HTML5, let’s discuss how to integrate these fonts with a game engine. The process will differ from one engine or framework to another. I have picked Phaser as an example, since it’s widely used for 2D game development. You can take a look at some online examples here:

And, of course, there is the Github repository with full source code, so you can take a closer look at what I’ve built.

Here’s how Phaser works: the game is divided in game states, each of which executes a sequence of phases. The most important phases are: init, preload, create, render, and update. The preload phase is where we must load game assets like images, sounds, etc. but unfortunately Phaser’s Loader does not provide a method for font preloading.

There are several ways to bypass or work around this issue:

Delaying font rendering

We can use the Font Loading API or a library to force a font download in the preload phase. However, this creates a problem. Phaser’s Loader doesn’t allow us to indicate it when all loading is completed. This means we can’t pause the Loader and prevent the preload phase from ending so that we can switch to create – this is where we would want to set up our game world.

A first approach would be to delay the text rendering until the font is loaded. After all, we have a callback available in the promise, right?

function preload() {
  // load other assets here
  // ...

  let font = new FontFaceObserver('Amatica SC');
  font.load().then(function () {
    game.add.text(0, 0, 'Lorem ipsum', {
      font: '12px Amatica SC',
      fill: '#fff'

There is a problem with this approach: What happens if the callback is invoked before the preload phase has ended? Our Phaser.Text object would then be wiped out once we switch to create.

What we can do is guard the creation of the text under two flags: one that indicates that the font has loaded, and a second one that indicates that the create phase has started:

var fontLoaded = false;
var gameCreated = false;

function createText() {
  if (!fontLoaded || !gameCreated) return;
  game.add.text(0, 0, 'Lorem ipsum', {
      font: '12px Amatica SC',
      fill: '#fff'

function preload() {
  let font = new FontFaceObserver('Amatica SC');
  font.load().then(function () {
    fontLoaded = true;

function create() {
  gameCreated = true;

The main disadvantage of this method is that we completely ignore Phaser’s Loader. Since this doesn’t queue the font as an asset, the game will start and the fonts will not be there — this will probably cause a blinking effect or a glitch. Another problem is that the “Loading” screen or bar will ignore fonts, will display as if 100% loaded, and switch to the game even though our font assets still haven’t loaded.

Using a custom loader

What if we could modify Phaser’s Loader and add it to whatever we need? We can! We can extend Phaser.Loader and add a method to the prototype that will queue an asset – a web font! The problem is that we need to modify one internal (meant for private use) Phaser.Loader method, loadFile, so we can tell the Loader how to load the font, and when loading has been finished.

// We create our own custom loader class extending Phaser.Loader.
// This new loader will support web fonts
function CustomLoader(game) {, game);

CustomLoader.prototype = Object.create(Phaser.Loader.prototype);
CustomLoader.prototype.constructor = CustomLoader;

// new method to load web fonts
// this follows the structure of all of the file assets loading methods
CustomLoader.prototype.webfont = function (key, fontName, overwrite) {
    if (typeof overwrite === 'undefined') { overwrite = false; }

    // here fontName will be stored in file's `url` property
    // after being added to the file list
    this.addToFileList('webfont', key, fontName);
    return this;

CustomLoader.prototype.loadFile = function (file) {, file);

    // we need to call asyncComplete once the file has loaded
    if (file.type === 'webfont') {
        var _this = this;
        // note: file.url contains font name
        var font = new FontFaceObserver(file.url);
        font.load(null, 10000).then(function () {
        }, function ()  {
            _this.asyncComplete(file, 'Error loading font ' + file.url);

Once this code is in place, we need to create an instance of it and swap it into game.load. This swapping must take place as soon as possible: in the init phase of the first game state executed.

function init() {
    // swap Phaser.Loader for our custom one
    game.load = new CustomLoader(game);

function preload() {
    // now we can load our font like a normal asset
    game.load.webfont('fancy', 'Amatica SC');

The advantage of this method is real integration with the loader, so if we have a loading bar it will not finish until the font has been completely downloaded (or timed out). The disadvantage, of course, is that we are overriding an internal method of Phaser, so we have no guarantee that our code will continue to work in future versions of the framework.

A silly workaround…

A method that I have been using in game jams is to not start the game at all until I know that the font is ready. Since most browsers won’t render a text until the web font has been loaded, I just create a splash screen with a Play button that uses the web font… This way I know that the button will be visible once that font has loaded, so it’s safe to start the game then.

The obvious disadvantage is that we are not starting to load assets until the player presses that button… But it does work and it is very simple to implement. Here’s an screenshot example of one of these splash screens, created with regular HTML5 DOM elements and CSS animations:

Screen Shot 2016-06-28 at 15.23.24

And there you have it, Web Font rendering in HTML5 games! In the future, once the Font Loading API is more mature, HTML5 game engines and frameworks will start to integrate it in their code, and hopefully we won’t have to do this ourselves or find a usable workaround.

Until then, happy coding! 🙂

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

HTML5 games: 3D collision detection

Last week we took a look at Tilemaps, and I shared some new articles that I’d written on MDN. This week I’m back to introduce 3D collision detection, an essential technique for almost any kind of 3D game. I’ll also point you to some more new articles about game development on MDN! Hope they inspire you to stretch your skills.

In 3D game development, bounding volumes provide one of the most widely used techniques for determining whether two virtual objects will collide (i.e., intersect with each other) during game play. The technique of bounding volumes consists of wrapping game objects with some virtual volumes, and applying intersection algorithms to describe the movement and interaction of these volumes. You can think of this approach as a shortcut: it is easier and faster than detecting intersections between arbitrary, complex shapes.

In terms of bounding volumes, the use of axis-aligned bounding boxes (AABB) is a popular option. Depending on the game, sometimes spheres are used as well. Here’s an image of some 3D objects wrapped with AABB:

Screen Shot 2015-10-16 at 15.11.21

The new MDN article on 3D collision detection describes how to use generic algorithms to perform 3D collision detection with AABB and spheres. This article should be useful regardless of the game engine or programming language you are using to develop your game.

We also published an article about doing collision detection with bounding volumes using three.js, a popular 3D library for JavaScript. (Learn more about three.js.)

Check out the live demos and peek at their source code. One of the demos uses a physics engine (in this case, Cannon.js) to perform collision detection. Embedded below you can find another demo that shows how to use Three.js to detect collisions:

Hope you enjoy the demos and find them useful. If there’s a particular topic in HTML5 game development you’d like to learn more about, please drop a comment here and let us know! We’ll try to get it covered for you.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Power Surge – optimize the JavaScript in this HTML5 game using Firefox Developer Edition

Power Surge!

The Firefox Developer Tools team wanted to find a fun way to show off the great performance tools we’ve just added to the Firefox Developer Edition browser. We partnered with Przemys?aw Sikorski (aka rezoner) author of Playground.js and the arcade puzzle game QbQbQb, to create “Power Surge,” a fun game which shows off how the new Performance tools can help developers find slow JavaScript code. The special twist is that the more you optimize the code in the game, the more ships and powers you win in gameplay!

First off, check out this quick screencast from Mozilla engineer Harald Kirschner on how Power Surge works:

To get going with Power Surge:

We’d really like to hear back from you about Power Surge! Tweet to us at @FirefoxDevtools and @mozhacks to share your solutions.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Build an HTML5 game—and distribute it

Last year, Mozilla and Humble Bundle brought great indie titles like FTL: Faster Than Light, Voxatron, and others to the Web through the Humble Mozilla Bundle promotion.  This year we plan to go even bigger with developments in JavaScript such as support for SIMD and SharedArrayBuffer.  Gaming on the Web without plugins is great; the user doesn’t have to install anything they don’t want, and if they love the game, they can share a link on their social media platform du jour.  Imagine the kind of viral multiplayer networking possibilities!

Lately, I’ve been focusing on real-time rendering with WebGL and while it is quite powerful, I wanted to take a step back and look at the development of game logic and explore various distribution channels.  I’ve read a few books on game development, but I most recently finished Build an HTML5 Game by Karl Bunyan and thought I’d share my thoughts on it.  Later, we’ll take a look at some alternative ways other than links to share and distribute HTML5 games.

Book review: Build an HTML5 Game

Build an HTML5 Game (BHG) is meant for developers who have programmed before; have written HTML, CSS, and JavaScript; know how to host their code from a local server; and are looking to make a 2D casual game. The layout presents a good logical progression of ideas, starting small, and building from work done in previous chapters. The author makes the point that advanced 3D visuals are not discussed in this book (as in WebGL). Also, the design of familiar genres of game play mechanics are avoided. Instead, the focus is on learning how to use HTML5 and CSS3 to replace Flash for the purpose of casual game development. The game created throughout the chapters is a bubble shooter (like the Bust A Move franchise). Source code, a demo of the final game itself, and solutions to further practice examples can be found online at:


I would recommend this book to any junior programmer who has written some code before, but maybe has trouble breaking up code in to logical modules with a clean separation of concerns.  For example, early on in my programming career, I suffered from “monolithic file” syndrome.  It was not clear to me when it made sense to split up programs across multiple files and even when to use multiple classes as is typical in object-oriented paradigms.  I would also recommend this book to anyone who has yet to implement their own game.

The author does a great job breaking up the workings of an actual playable game into the Model-View-Controller (MVC) pattern.  Also, it’s full of source code, with clearly recognizable diffs of what was added or removed from previous examples.  If you’re like me and like to follow along writing the code from technical books while reading them, the author of this book has done a fantastic job making it easy to do.

The book is a great reference. It exposes a developer new to web technologies to the numerous APIs, does a good job explaining when such technologies are useful, and accurately weighs pros and cons of different approaches.  There’s a small amount of trigonometry and collision detection covered; two important ideas that are used frequently in game development.

Another key concept that’s important to web development in general is graceful degradation.  The author shows how Modernizr is used for detecting feature support, and you even implement multiple renderers: a canvas one for more modern browsers, with a fallback renderer that animates elements in the DOM.  The idea of multiple renderers is an important concept in game development; it helps with the separation of concerns (separating rendering logic from updating the game state in particular); exposes you to more than one way of doing things; and helps you target multiple platforms (or in this case, older browsers). Bunyan’s example in this particular case is well designed.


Many web APIs are covered either in the game itself or mentioned for the reader to pursue.  Some of the APIs, patterns, and libraries include: Modernizr, jQuery, CSS3 transitions/animations/transforms, Canvas 2D, audio tags, Sprite Atlases, DOM manipulation, localStorage, requestAnimationFrame, AJAX, WebSockets, Web Workers, WebGL, requestFullScreen, Touch Events, meta viewport tags, developer tools, security, obfuscation, “don’t trust the client” game model, and (the unfortunate world of) vendor prefixes.

The one part of the book I thought could be improved was the author’s extensive use of absolute CSS positioning.  This practice makes the resulting game very difficult to port to mobile screen resolutions. Lots of the layout code and the collision detection algorithm assume exact widths in pixels as opposed to using percentages or newer layout modes and measuring effective widths at run time.

Options for distributing your game

Now let’s say we’ve created a game, following the content of Build an HTML5 Game, and we want to distribute it to users as an app.  Personally, I experience some form of cognitive dissonance here; native apps are frequently distributed through content silos, but if that’s the storefront where money is to be made then developers are absolutely right to use app stores as a primary distribution channel.

Also, I get frequent questions from developers who have previously developed for Android or iOS looking to target Firefox OS. They ask,“Where does my binary go?” — which is a bit of a head-scratcher to someone who’s familiar with standing up their own web server or using a hosting provider.  For instance, one of the more well known online storefronts for games, Steam, does not even mention HTML5 game submissions!

A choice of runtimes

I’d like to take a look at two possible ways of “packaging” up HTML5 games (or even applications) for distribution: Mozilla’s Web Runtime and Electron.

Mozilla’s Web Runtime allows a developer with no knowledge of platform/OS specific APIs to develop an application 100% in HTML5.  No need to learn anything platform specific about how windows are created, how events are handled, or how rendering occurs.  There’s no IDE you’re forced to use, and no build step.  Unlike Cordova, you’re not writing into a framework, it’s just the Web.  The only addition you need is an App Manifest, which is in the standards body within the W3C currently.

An example manifest from my IRC app:

  "name": "Firesea IRC",
  "version": "1.0.13",
  "developer": {
    "name": "Mozilla Partner Engineering",
    "url": ""
  "description": "An IRC client",
  "launch_path": "/index.html",
  "permissions": {
    "tcp-socket": {
      "description": "tcp"
    "desktop-notification": {
      "description": "privMSGs and mentions"
  "icons": {
    "128": "/images/128.png"
  "type": "privileged"

Applications developed with Mozilla’s Web Runtime can be distributed as links to the manifest to be installed with a snippet of JavaScript called “hosted apps,” or links to assets archived in a zip file called “packaged apps.”  Mozilla will even host the applications for you in, though you are free to host your apps yourself.  Google is also implementing the W3C manifest spec, though there are a few subtleties between implementations, currently, such as having a launcher rather than a desktop icon.

Here’s the snippet of JavaScript used to install a hosted app:

var request = window.navigator.mozApps.install(manifestUrl);
request.onsuccess = function () {
request.onerror = function () {

A newer io.js (Node.js fork)-based project is Electron, formerly known as Atom Shell and used to build projects like the Atom code editor from GitHub and the Visual Studio Code from MicrosoftElectron allows for more flexibility in application development; the application is split into two processes that can post messages back and forth.  One is the browser or content process, which uses the Blink rendering engine (from Chromium/Chrome), and the main process which is io.js.  All of your favorite Node.js modules can thus be used with Electron.  Electron is based off of NW.js (formerly node-webkit, yo dawg, heard you like forks) with a few subtleties of its own.


Once installed, Mozilla’s Web Runtime will link against code from an installed version of Firefox and load the corresponding assets.  There’s a potential tradeoff here.  Electron currently ships an entire rendering engine for each and every app; all of Blink.  This is potentially ~40MB, even if your actual assets are significantly smaller.  Web Runtime apps will link against Firefox if it’s installed, otherwise will prompt the user to install Firefox to have the appropriate runtime.  This cuts down significantly on the size of the content to be distributed at the cost of expecting the runtime to already be installed, which may or may not be the case.  Web Runtime apps can only be installed in Firefox or Chromium/Blink, which isn’t ideal, but it’s the best we can do until browser vendors agree on and implement the standard.  It would be nice to allow the user to pick which browser/rendering engine/environment to run the app in as well.

While I’m a big fan of the Node.js ecosystem, I’m also a big fan of the strong guarantees of security provided by the browser.  For instance, I personally don’t trust most applications distributed as executables.  Call me paranoid, but I’d really prefer if applications didn’t have access to my filesystem, and only had permission to make network requests to the host I navigated to.  By communicating with Node.js, you bypass the strong guarantees provided by browser vendors.  For example, browser vendors have created the Content Security Policy (CSP) as a means of shutting down a few Cross Site Scripting (XSS) attack vectors.  If an app is built with Electron and accesses your file system, hopefully the developer has done a good job sanitizing their inputs!

On the other side of the coin, we can do some really neat stuff with Electron.  For example, some of the newer Browser APIs developed in Gecko and available in Firefox and Firefox OS are not yet implemented in other rendering engines.  Using Electron and its message-passing interface, it’s actually possible to polyfill these APIs and use them directly, though security is still an issue.  Thus it’s possible to more nimbly implement APIs that other browser vendors haven’t agreed upon yet.  Being able to gracefully fallback to the host API (rather than the polyfill) in the event of an update is important; let’s talk about updates next.

Managing updates

Updating software is a critical part of security.  While browsers can offer stronger security guarantees, they’re not infallible.  “Zero days” exist for all major browsers, and if you had the resources you could find or even buy knowledge of one.  When it comes to updating applications, I think Mozilla’s Web Runtime has a stronger story: app assets are fetched every time, but defer to the usual asset caching strategy while the rendering engine is linked in.  Because Firefox defaults to auto updating, most users should have an up-to-date rendering engine (though there are instances where this might not be the case).  The runtime should check for updates for packaged apps daily, and updates work well.  For Electron, I’m not sure that the update policy for apps is built in.  The high value of exploits for widely installed software like rendering engines worries me a bit here.

Apps for Mozilla’s Runtime work currently anywhere where Firefox for desktop or mobile does: Windows, OS X, Linux, Android, or Firefox OS.  Electron supports desktop platforms like Windows, OS X, or Linux.  Sadly, neither option currently supports iOS devices.  I do like that Electron allows you to generate actual standalone apps, and it looks like tools to generate the expected .msi or .dmg files are in the works.

Microsoft’s manifold.js might be able to bridge the gap to all these different platforms and more.  Though I ran into a few road bumps while trying it out, I would be willing to give it another look.  For me, one potentially problematic issue is requiring developers to generate builds for specific platforms.  Google’s Native Client (NaCl) had this issue where developers would not build their applications for ABIs (application binary interfaces) they did not possess hardware to test for, and thus did not generate builds of their apps for them.  If we want web apps to truly run everywhere, having separate build steps for each platform is not going to cut it; and this to me is where Mozilla’s Web Runtime really shines. Go see for yourself.

In conclusion

If I missed anything or made any mistakes in regards to any of the technologies in this article, please let me know via comments to this post.  I’m more than happy to correct any errata. More than anything, I do not want to spread fear, uncertainty, or doubt (FUD) about any of these technologies.

I’m super excited for the potential each of these approaches hold, and I enjoy exploring some of the subtleties I’ve observed between them.  In the end, I’m rooting for the Web, and I’m overjoyed to see lots of competition and ideation in this space, each approach with its own list of pros and cons.  What pros and cons do you see, and how do you think we can improve?  Share your (constructive) thoughts and opinions in the comments below.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Building Interactive HTML5 Videos

The HTML5 <video> element makes embedding videos into your site as easy as embedding images. And since all major browsers support <video> since 2011, it’s also the most reliable way to get your moving pictures seen by people.

A more recent addition to the HTML5 family is the <track> element. It’s a sub-element of <video>, intended to make the video timeline more accessible. Its main use case is adding closed captions. These captions are loaded from a separate text file (a WebVTT file) and printed over the bottom of the video display. Ian Devlin has written an excellent article on the subject.

Beyond captions though, the <track> element can be used for any kind of interaction with the video timeline. This article explores 3 examples: chapter markers, preview thumbnails, and a timeline search. By the end, you will have sufficient understanding of the <track> element and its scripting API to build your own interactive video experiences.

Chapter Markers

Let’s start with an example made popular by DVD disks: chapter markers. These allow viewers to quickly jump to a specific section. It’s especially useful for longer movies like Sintel:

The chapter markers in this example reside in an external VTT file and are loaded on the page through aelement with a kind of **chapters. The track is set to load by default:

<video width="480" height="204" poster="assets/sintel.jpg" controls>
  <source src="assets/sintel.mp4" type="video/mp4">
  <track src="assets/chapters.vtt" kind="chapters" default>

Next, we use JavaScript to load the cues of the text track, format them, and print them in a controlbar below the video. Note we have to wait until the external VTT file is loaded:

track.addEventListener('load',function() {
    var c = video.textTracks[0].cues;
    for (var i=0; i<c.length; i++) {
      var s = document.createElement("span");
      s.innerHTML = c[i].text;

In above code block, we’re adding 2 properties to the list entries to hook up interactivity. First, we set a data attribute to store the start position of the chapter, and second we add a click handler for an external seek function. This function will jump the video to the start position. If the video is not (yet) playing, we’ll make that so:

function seek() {
  video.currentTime = this.getAttribute('data-start');
  if(video.paused){; }

That’s it! You now have a visual chapter menu for your video, powered by a VTT track. Note the actual live Chapter Markers example has a little bit more logic than described, e.g. to toggle playback of the video on click, to update the controlbar with the video position, and to add some CSS styling.

Preview Thumbnails

This second example shows a cool feature made popular by Hulu and Netflix: preview thumbnails. When mousing over the controlbar (or dragging on mobile), a small preview of the position you’re about to seek to is displayed:

This example is also powered by an external VTT file, loaded in a metadata track. Instead of texts, the cues in this VTT file contain links to a separate JPG image. Each cue could link to a separate image, but in this case we opted to use a single JPG sprite – to keep latency low and management easy. The cues link to the correct section of the sprite by using Media Fragment URIs.Example:,0,160,90

Next, all important logic to get the right thumbnail and display it lives in a mousemove listener for the controlbar:

controlbar.addEventListener('mousemove',function(e) {
  // first we convert from mouse to time position ..
  var p = (e.pageX - controlbar.offsetLeft) * video.duration / 480;
  // ..then we find the matching cue..
  var c = video.textTracks[0].cues;
  for (var i=0; i<c.length; i++) {
      if(c[i].startTime <= p && c[i].endTime > p) {
  // we unravel the JPG url and fragment query..
  var url =c[i].text.split('#')[0];
  var xywh = c[i].text.substr(c[i].text.indexOf("=")+1).split(',');
  // ..and last we style the thumbnail overlay = 'url('+c[i].text.split('#')[0]+')'; = '-'+xywh[0]+'px -'+xywh[1]+'px'; = e.pageX - xywh[2]/2+'px'; = controlbar.offsetTop - xywh[3]+8+'px'; = xywh[2]+'px'; = xywh[3]+'px';

All done! Again, the actual live Preview Thumbnails example contains some additional code. It includes the same logic for toggling playback and seeking, as well as logic to show/hide the thumbnail when mousing in/out of the controlbar.

Timeline Search

Our last example offers yet another way to unlock your content, this time though in-video search:

This example re-uses an existing captions VTT file, which is loaded into a captions track. Below the video and controlbar, we print a basic search form:

    <input type="search" />
    <button type="submit">Search</button>

Like with the thumbnails example, all key logic resides in a single function. This time, it’s the event handler for submitting the form:

form.addEventListener('submit',function(e) {
  // First we’ll prevent page reload and grab the cues/query..
  var c = video.textTracks[0].cues;
  var q = document.querySelector("input").value.toLowerCase();
  // ..then we find all matching cues..
  var a = [];
  for(var j=0; j<c.length; j++) {
    if(c[j].text.toLowerCase().indexOf(q) > -1) {
  // ..and last we highlight matching cues on the controlbar.
  for (var i=0; i<a.length; i++) {
    var s = document.createElement("span"); = (a[i].startTime/video.duration*480-2)+"px";

Three time’s a charm! Like with the other ones, the actual live Timeline Search example contains additional code for toggling playback and seeking, as well as a snippet to update the controlbar help text.

Wrapping Up

Above examples should provide you with enough knowledge to build your own interactive videos. For some more inspiration, see our experiments around clickable hot spots, interactive transcripts, or timeline interaction.

Overall, the HTML5 <track> element provides an easy to use, cross-platform way to add interactivity to your videos. And while it definitely takes time to author VTT files and build similar experiences, you will see higher accessibility of and engagement with your videos. Good luck!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Resources for HTML5 game developers

Today we released Firefox 31 and it offers a couple of new features that help HTML5 game developers to code and debug sophisticated games. In addition Mozilla blogged about the first commercial games leveraging asm.js, Dungeon Defenders Eternity and Cloud Raiders both of which were cross-compiled in to JavaScript using the Emscripten compiler. Games like these show that HTML5 is ready as a game platform.

If you are interested in working with Emscripten you can get more information at the main Emscripten wiki or grab the code on the github page. Another good resource is the getting started with Emscripten tutorial on MDN. If you are wondering about the performance of asm.js, read asm.js performance improvements in the latest version of Firefox make games fly! for details.

In this post we’ll introduce you to some of the resources built by Mozillians that allow you to code and debug HTML5 based games. This list is not exhaustive and we appreciate feedback on any valuable resources that would help in this arena. Don’t be shy and tell us about them in the comments.

Where To Start

When developing an HTML5 based game, you have a lot of choices to make. These range from what editor to use, if the game will use Canvas 2d, WebGL, SVG, or CSS up to which specific rendering frameworks and game engines to use. Most of these decisions will be based on the developer experience and the platforms the game will be published on. No article will answer all these questions but we wanted to put together a post that would help get you started down the path.

One of the key resources available for game developers on MDN is the Games Zone. This section of MDN contains general game development articles, demos, external resources and examples. It also includes detailed descriptions of some of the APIs that a developer will need to be aware of when implementing an HMTL5 game, including sound management, networking, storage and graphics rendering. We are currently in the process of adding content and upgrading the zone. In the future we hope to have content and examples for most common scenarios, frameworks and tool chains.

In the meantime here are a few posts and MDN articles that help game developers getting started.


As an HTML5 developer you will have no shortage of tools at your disposal. In the Mozilla community we have been hard at work expanding the features that Firefox Developer Tools provide. These include a full-featured JavaScript Debugger, Style Editor, Page Inspector, Scratchpad, Profiler, Network Monitor and Web Console.

In addition to these, some notable tools have been updated or introduced recently and offer some great functionality for the game developer.

Canvas Debugger

With the current release of Firefox, we added a Canvas Debugger to the browser.
The Canvas Debugger allows you to trace through all canvas context calls that are used to generate a frame. Calls are color coded for specific calls for things like drawing elements or using a specific shader program. The Canvas Debugger is not only useful when developing a WebGL based game but can also be used when debugging a Canvas 2D based game. In the game below you can see in the animation strip as each image is drawn to the canvas. You can click any of these lines to get directly to the part of your JavaScript responsible for this action.
Two very common issues that have been reported when using the Canvas Debugger are with animations generated using setInterval instead of requestAnimationFrame and inspecting canvas elements in an iFrame.

To get more information about the Canvas Debugger be sure to read over Introducing the Canvas Debugger in Firefox Developer Tools.

Shader Editor

When developing WebGL based games it is very useful to be able to test and alter shader programs while the application is running. Using the Shader Editor within the developer tools makes this possible. Vertex and Fragment Shader programs can be modified without the need to reload the page, or black boxed to see what effect this has on the resulting output.

For more information on the Shader Editor, be sure to see Live editing WebGL shaders with Firefox Developer Tools post and take a look at this MDN article which contains a couple of videos showing live editing.

Web Audio Editor

The current version of Firefox Aurora (32) – has a Web Audio Editor. The Editor displays a graphical representation of all the Audio Nodes and their connections in the current AudioContext. You can drill down to specific attributes of each node to inspect them.

The Web Audio API provides more robust and complex sound creation, manipulation and processing than what is available in the HTML5 Audio tag. When using the Web Audio API make sure to read over Writing Web Audio API code that works in every browser as it contains pertinent information about support for the various audio nodes.

For more information on the Web Audio Editor be sure to read this Hacks article introducing the Web Editor and this MDN article.

Network Monitor

When developing an HTML5 based game network impact can be not only cumbersome but also costly if the user is on mobile device. Using the Network Monitor you can visually inspect all network request for location, time spent on the operation, and the type and size of the artifact.
In addition you can use the Network Monitor to get a visual performance analysis of your app when cached versus non-cached.

To get more information on the Network Monitor see the MDN page.


When starting your game one of your first choices will be which editor to use. And there are a lot of them (Sublime, Eclipse, Dreamweaver, vi, etc). In most cases a you already have a favorite. If you are interested in doing your development within the Browser you may want to have a look at the Web IDE that was recently released in Firefox Nightly.

The Web IDE project provides not only a fully functional editor but also acts as a publishing agent to various local and remote platforms, debugger, template framework and application manager. In addition the framework supporting this project provides APIs that will allow other editors to use functionality provided in the tool. To get more details on the work that is being done in this area have a look at this post.

In order to keep up-to-date with news on the Firefox Developer Tools, follow their article series on the Hacks blog. For more detailed information on new, stable developer tools features, check out their documentation on MDN.


The MDN Games Zone lists various APIs and articles that are useful for beginning game development.
In addition to these resources you may be interested in looking over some additional posts that can be valuable for development.

If your game is going to support multiplayer interaction using either WebRTC or WebSockets you may also be interested in looking at Together.js which provides collaborative features for web apps. To get an idea what is possible take a look at Introducing TogetherJS.

Many games will require storage and IndexedDB can be used to handle these needs. For information on extending the capabilities of IndexedDB read over Breaking the Borders of IndexedDB. You may also be interested in localForage which provides browser agnostic support for simple storage. To get more details about this library read over this Hacks post.

Game Optimization

HTML5 games today offer a great deal of power to the game developer. That said many of these games are going to be played on a mobile device, which in comparison to your desktop will pale in performance. So if you plan on your game being a success across platforms it is important that you optimize your code. The Optimizing your JavaScript Game for Firefox OS post has a lot of great techniques to help you build a game that performs well on low-end mobile devices.


In order to reach the most users of your game you may want to consider offering it in different languages. As part of this developers should start with localization built into the game. We are doing a great deal of work around recruiting translators to help you translate your game. To get more information about this initiative see this post.

Your Voice

As Mozilla is about the community of developers and users, we want your help and your feedback. If you have recommendations for specific features that you would like to see in the products make sure to either get involved in discussion on or through our mailing lists. You can also log bugs at In addition we are also provide additional feedback channels for our DevTools and Open Web Apps.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Adding captions and subtitles to HTML5 video

This article is also available on MDN.

With the introduction of the <video> and <audio> elements to HTML5, we finally have a native way to add video and audio to our websites. We also have a JavaScript API that allows us to interact with this media content in different ways, be it writing our own controls or simply seeing how long a video file is. As responsible web developers, we should also be constantly thinking about making our content more accessible, and this doesn’t stop with video and audio content. Making our content accessible to all is an important step, be it for someone who is hard of hearing or someone who doesn’t understand the language that the content is delivered in, inclusion can be paramount.

Thankfully HTML5 also provides us with a native way of making our media content more accessible by adding subtitles and captions via the <track> element. Most major browsers support this natively to varying degrees, which the first part of this article shows, but it also provides a JavaScript API, with which we can access and use the text tracks (e.g. subtitles) that are available. This article also shows how this API can be used to detect what captions/subtitles have been added to a HTML5 video, and how that data can be used to build a selectable menu of available text tracks and ultimately provide a more consistent interface across the various browsers.

In articles on MDN, we have looked at how to build a cross browser video player using the HTMLMediaElement and Window.fullScreen APIs, and also at how to style the player. This article will take the same player and show how to add captions and subtitles to it, using Web_Video_Text_Tracks_Format and the <track> element.

Captioned video example

In this article, we will refer to the Video player with captions example. This example uses an excerpt from the Sintel open movie, created by the Blender Foundation.

Video player with stand controls such as play, stop, volume, and captions on and off. The video playing shows a scene of a man holding a spear-like weapon, and a caption reads "Esta hoja tiene pasado oscuro."

Note: You can find the source on Github, and also view the example live.

HTML5 and Video Captions

Before diving into how to add captions to the video player, there are a number of things that we will first mention, which you should be aware of before we start.

Captions versus subtitles

Captions and subtitles are not the same thing: they have significantly different audiences, and convey different information, and it is recommended that you read up on the differences if you are not sure what they are. They are however implemented in the same way technically, so the material in this article will apply to both.

For this article we will refer to the text tracks displayed as captions, as their content is aimed at hearing people who have difficulty understanding the language of the film, rather than deaf or hard-of-hearing people.

The <track> element

HTML5 allows us to specify captions for a video using the Web Video Text Tracks (WebVTT) format. The WebVTT specification is still being worked on, but major parts of it are stable so we can use it today.

Video providers (such as the Blender Foundation) provide captions and subtitles in a text format with their videos, but they’re usually in the SubRip Text (SRT) format. These can be easily converted to WebVTT using an online converter such as srt2vtt.

Modifications to the HTML and CSS

This section summarises the modifications made to the previous article’s code in order to facilitate the addition of subtitles to the video. If you are not interested in thism and just want to get straight into the JavaScript and more relevant CSS, skip to the Caption implementation section.

In this example we are using a different video, Sintel, as it actually has some speech in it and therefore is better for illustrating how captions work!

HTML Markup

As mentioned above, we need to make use of the new HTML5 <track> element to add our caption files to the HTML5 video. We actually have our captions in three different languages — English, German, and Spanish — so we will reference all three of the relevant VTT files by adding <track> elements inside our HTML5 <video> element:

<video id="video" controls preload="metadata">
   <source src="video/sintel-short.mp4" type="video/mp4">
   <source src="video/sintel-short.webm" type="video/webm">
   <track label="English" kind="captions" srclang="en" src="captions/vtt/sintel-en.vtt" default>
   <track label="Deutsch" kind="captions" srclang="de" src="captions/vtt/sintel-de.vtt">
   <track label="Español" kind="captions" srclang="es" src="captions/vtt/sintel-es.vtt">

As you can see, each <track> element has the following attributes set:

  • kind is given a value of captions, indicating the type of content the files contain
  • label is given a value indicating which language that caption set is for for example English or Deutsch — these labels will appear in the user interface to allow the user to easily select which caption language they want to see.
  • src is assigned a valid URL pointing to the relevant WebVTT caption file in each case.
  • srclang indicates what language each captions files’ contents are in.
  • The default attribute is set on the English <track> element, indicating to the browser that this is the default caption file definition to use when captions have been turned on and the user has not made a specific selection.

In addition to adding the <track> elements, we have also added a new button to control the captions menu that we will build. As a consequence, the video controls now look as follows:

<div id="video-controls" class="controls" data-state="hidden">
   <button id="playpause" type="button" data-state="play">Play/Pause</button>
   <button id="stop" type="button" data-state="stop">Stop</button>
   <div class="progress">
      <progress id="progress" value="0" min="0">
         <span id="progress-bar"></span>
   <button id="mute" type="button" data-state="mute">Mute/Unmute</button>
   <button id="volinc" type="button" data-state="volup">Vol+</button>
   <button id="voldec" type="button" data-state="voldown">Vol-</button>
   <button id="fs" type="button" data-state="go-fullscreen">Fullscreen</button>
   <button id="captions" type="button" data-state="captions">CC</button>

CSS Changes

The video controls have undergone some minor changes in order to make space for the extra button, but these are relatively straightforward.

No image is used for the captions button, so it is simply styled as:

.controls button[data-state="captions"] {

There are also other CSS changes that are specific to some extra JavaScript implementation, but these will be mentioned at the appropriate place below.

Caption implementation

A lot of what we do to access the video captions revolves around JavaScript. Similar to the video controls, if a browser supports HTML5 video captions, there will be a button provided within the native control set to access them. However, since we have defined our own video controls, this button is hidden, and we need to define our own.

Browsers do vary as to what they support, so we will be attempting to bring a more unified UI to each browser where possible. There’s more on browser compatibility issues later on.

Initial setup

As with all the other buttons, one of the first things we need to do is store a handle to the captions’ button:

var captions = document.getElementById('captions');

We also initially turn off all captions, in case the browser turns any of them on by default:

for (var i = 0; i &lt; video.textTracks.length; i++) {
   video.textTracks[i].mode = 'hidden';

The video.textTracks property contains an array of all the text tracks attached to the video. We loop through each one and set its mode to hidden.

Note: The WebVTT API gives us access to all the text tracks that are defined for an HTML5 video using the <track> element.

Building a caption menu

Our aim is to use the captions button we added earlier to display a menu that allows users to choose which language they want the captions displayed in, or to turn them off entirely.

We have added the button, but before we make it do anything, we need to build the menu that goes with it. This menu is built dynamically, so that languages can be added or removed later by simply editing the <track> elements within the video’s markup.

All we need to do is to go through the video’s textTracks, reading their properties and building the menu up from there:

var captionsMenu;
if (video.textTracks) {
   var df = document.createDocumentFragment();
   var captionsMenu = df.appendChild(document.createElement('ul'));
   captionsMenu.className = 'captions-menu';
   captionsMenu.appendChild(createMenuItem('captions-off', '', 'Off'));
   for (var i = 0; i < video.textTracks.length; i++) {
      captionsMenu.appendChild(createMenuItem('captions-' + video.textTracks[i].language, video.textTracks[i].language,         video.textTracks[i].label));

This code creates a documentFragment, which is used to hold an unordered list containing our captions menu. First of all an option is added to allow the user to switch all captions off, and then buttons are added for each text track, reading the language and label from each one.

The creation of each list item and button is done by the createMenuItem() function, which is defined as follows:

var captionMenuButtons = [];
var createMenuItem = function(id, lang, label) {
   var listItem = document.createElement('li');
   var button = listItem.appendChild(document.createElement('button'));
   button.setAttribute('id', id);
   button.className = 'captions-button';
   if (lang.length > 0) button.setAttribute('lang', lang);
   button.value = label;
   button.setAttribute('data-state', 'inactive');
   button.addEventListener('click', function(e) {
      // Set all buttons to inactive, i, a) {
         captionMenuButtons[i].setAttribute('data-state', 'inactive');
      // Find the language to activate
      var lang = this.getAttribute('lang');
      for (var i = 0; i < video.textTracks.length; i++) {
         // For the 'captions-off' button, the first condition will never match so all will captions be turned off
         if (video.textTracks[i].language == lang) {
            video.textTracks[i].mode = 'showing';
            this.setAttribute('data-state', 'active');
         else {
            video.textTracks[i].mode = 'hidden';
      } = 'none';
   return listItem;

This function builds the required <li> and <button> elements, and returns them so they can be added to the captions menu list. It also sets up the required event listeners on the button to toggle the relevant caption set on or off. This is done by simply setting the required caption’s mode attribute to showing, and setting the others to hidden.

Once the menu is built, it is then inserted into the DOM at the bottom of the videoContainer.

Initially the menu is hidden by default, so an event listener needs to be added to our captions button to toggle it:

captions.addEventListener('click', function(e) {
   if (captionsMenu) { = ( == 'block' ? 'none' : 'block');

Caption menu CSS

We also added some rudimentary styling for the newly created captions menu:

.captions-menu {
.captions-menu li {
.captions-menu li button {
    padding:2px 5px;

Styling the displayed captions

One of the less well known about and supported features of WebVTT is the ability to style the individual captions (something called text cues) via CSS Extensions.

The ::cue pseudo-element is the key to targetting individual text track cues for styling, as it matches any defined cue. There are only a handful of CSS properties that can be applied to a text cue:

For example, to change the text colour of the text track cues you can write:

::cue {

If the WebVTT file uses voice spans, which allow cues to be defined as having a particular “voice”:

00:00:00.000 --> 00:00:12.000
<v Test>[Test]</v>

Then this specific ‘voice’ will be stylable like so:

::cue(v[voice='Test']) {

Note: Some of the styling of cues with ::cue currently works on Chrome, Opera, and Safari, but not yet on Firefox.

Browser Compatibility

Browser support for WebVTT and the <track> element is fairly good, although some browsers differ slightly in their implementation.

Internet Explorer

Since Internet Explorer 10+ captions are enabled by default, and the default controls contain a button and a menu that offers the same functionality as the menu we just built. The default attribute is also supported.

Note: IE will completely ignore WebVTT files unless you setup the MIME type. This can easily be done by adding an .htaccess file to an appropriate directory that contains AddType text/vtt .vtt.


Safari 6.1+ has similar support to Internet Explorer 11, displaying a menu with the different available options, with the addition of an “Auto” option, which allows the browser to choose.

Chrome and Opera

These browsers have similar implementations again: captions are enabled by default and the default control set contains a ‘cc’ button that turns captions on and off. Chrome and Opera ignore the default attribute on the <track> element and will instead try to match the browser’s language to the caption’s language.


Firefox’s implementation was completely broken due to a bug, leading to Mozilla turning off WebVTT support by default (you can turn it on via the media.webvtt.enabled flag.) However, this bug looks to have been fixed and WebVTT support re-enabled as of Gecko 31, so this will not be a problem for Firefox final release users for much longer (on Gecko 29 as of the time of this writing.)


If, after reading through this article you decide that you can’t be bothered to do all of this and want someone else to do it for you, there are plenty of plugins out there that offer caption and subtitle support that you can use.

This small plugin implements subtitles, captions, and chapters as well as both WebVTT and SRT file formats.
This video player is very extensive and does a lot more than simply support video captions. It supports WebVTT, SRT, and DFXP file formats.
Another complete video player that also support video captions, albeit only in SRT format.
LeanBack Player
Yet another video player that supports WebVTT captions as well as providing other standard player functionality.
This player also supports captions through WebVTT and SRT files.
Supports WebVTT video subtitles.

Note: You can find an excellent list of HTML5 Video Players and their current state at HTML5 Video Player Comparison.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

[video+slides] FirefoxOS – HTML5 for a truly world-wide-web (Sapo Codebits 2014)

Chris Heilmann at SAPO codebits
Today the good people at Sapo released the video of my Codebits 2014 keynote.

In this keynote, I talk about FirefoxOS and what it means in terms of bringing mobile web connectivity to the world. I explain how mobile technology is unfairly distributed and how closed environments prevent budding creators from releasing their first app. The slides are “>available on Slideshare as the video doesn’t show them.

There’s also a screencast on YouTube.

Since this event, Google announced their Android One project, and I am very much looking forward how this world-wide initiative will play out and get more people connected.

Photo by José P. Airosa ‏@joseairosa

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Do HTML5 apps have to be online all the time?

One would think that almost five years after the definition of HTML5 offline capabilities this question would be answered. As someone spending a lot of time on HTML5 panels and Q&A sessions at conferences I can tell you though that it gets asked every single time.

being offline

As part of the App Basics for Firefox OS video series we recorded a very short video that shows that HTML5 apps totally can work offline:

You can see the demo explained in the video in action here: non-offline version and offline enabled version.

So here it is: No, HTML5 apps don’t have to be online all the time, they do work offline if you write them the right way.

“But, but, but, but, but…”, I already here people go, “it is not that simple, as there are lots of issues with offline functionality”.

Yes, there are. Appcache is a less than perfect solution, as researched in-depth by Jake Archibald and published in non-minced words almost 2 years ago. There are also issues with localStorage being string based and synchronous and thus being less than optimal for large datasets. For larger datasets the issue is that indexedDB is not supported by all browsers, which is why you need to duplicate your efforts using WebSQL or use an abstraction library instead.

But: these are not insurmountable issues. I am very happy to see offline first becoming a UX starting point, I am super excited about discussions about replacing AppCache and the ServiceWorker proposal showing a much more granular approach to the issue.

For an in-depth showcase how offline can really work, check out Andrew Bett’s 2012 Full Frontal talk.

The problem is that these are details that don’t interest the business person considering using HTML5. All they hear is experts complaining and bickering and saying that offline HTML5 doesn’t work. Which isn’t true. It doesn’t work perfectly, but nothing on the web ever does. Many, many things in Android and iOS are broken, and many apps don’t work offline either. These shortcomings are not advertised though which makes native apps appear as a much more reliable alternative. We should stop showing our behind the scenes footage as a highlight reel.

I really, really want this question to not show up any longer. The documentation and proof is out there. Let’s tell people about that. Please?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)