Articles by Chris Heilmann

Sort by:


  1. Privacy policy guidelines and Template for web apps

    Privacy Releasing an app is much more than just coding it. You are providing a service to people and they trust you with their data. With the amount of reports of apps “calling home” and storing and sending your data to third parties without your consent rising it is important to make it plain and obvious what you do. An easy to understand and plain Privacy Policy is not only a good service but it can make it easier for investors and users to choose your product over another.

    Ramping up developers to submit and publish their apps to the Mozilla Marketplace we just released a few simple to understand Privacy policy guidelines complete with an HTML/CSS/RSS Privacy Policy Template on GitHub.

    Whilst the guidelines are not a substitute for a real lawyer and don’t provide legal advice they have some very simple and powerful tips to get you going:

    • Design your app or add-on so that what you actually do with user data is what users think you are doing with it.
    • Try to give the user as much control over their data as you can, such as giving them the choice to opt-in to or opt-out of data collection whenever possible.
    • Try to limit your data collection and use to only the data that you need.
    • Design your app and service to protect the security of your user’s data in its collection, storage, and use.
    • Respond to user questions and concerns about your privacy practices.
    • Avoid ‘secret’ updates.
    • Make your use of social features transparent, so that users are aware of when they’re sharing data socially.
    • Give people a way to turn off automatic sharing or make more granular choices about sharing data.
    • Obtain consent from users when necessary, especially for location and other sensitive information.
    • Put a link to your privacy policy and, if you have them, your “terms of use” somewhere in your app.

    Avoid confusion and problems in the future by getting the basics right – and that very much includes privacy concerns in your app.

  2. State of the browser in London, England

    Last Saturday in London, England the State of the browser conference brought together developer advocates from almost all browser vendors to give the audience an overview of what is going on in the world of browsers.

    Browser panel

    Browser panel with Bruce Lawson (Opera), Chris Heilmann (Mozilla), Martin Beeby (Microsoft) and Paul Kinlan (Google)

    My involvement was to talk about the state of HTML5 when seen from a native market’s perspective, show some cool new technologies that need our input and take part in the browser panel to discuss current issues. Here are the talks and screencasts. Videos recorded by the organisers should follow soon.

    Talk “Broken HTML5 promises – are we ‘appy?”

    The main Mozilla presentation was about feedback on HTML5 we got at Mobile World Congress from mobile developers, how we as an HTML5 community fail to answer their questions and get tangled up in petty bickering over details instead and what Mozilla does to make HTML5 work across the board.

    The slides with notes are available here and the screencast (with bad audio, sorry) is on

    Breakout session: “The bleeding edge of HTML needs blood donors”

    The breakout session (which was repeated twice) was much less of a “talk” but more of a show and tell in a smaller room. Therefore the screencast is a bit more raw but shows what you can do right now.

    The slides with notes are available here and the screencast is on

    The conference

    All in all the conference was great value for money. All the speakers had great information to give and there was no “marketing talk” promising things that don’t work outside lab environments.

    • Michael Mahemoff did a great job introducing the day with a “native vs. web knockout” talk.
    • Paul Kinlan showed what is coming in Chrome and how Web Intents can change the way we solve app communication over the web
    • Martin Beeby gave a glimpse of how the web can merge with newer devices and UX needs of users

    Seb Lee-Delisle took all the browsers to the performance test to end all performance tests by animating millions of 3D particles and seeing which browser would be the one that can show the most without slowing down. In the end Firefox was the winner with 3695244 particles at 10FPS. Of course this is not a real measure (especially seeing IE10 was run in a VM) but it is always fun to see Seb code live.
    Particles competition results

    I guess my favourite piece about the conference was that the browser panel was very much about answering people’s questions instead of trying to beat each other in being the browser that people should use. British understatement at its best.

  3. Click highlights with CSS transitions

    When you watch screencasts from time to time you’ll see that some software adds growing dots to the clicks the person explaining does to make them more obvious. Using CSS transitions this can be done very simply in JavaScript, too.
    click highlighting with CSS

    Check out the following demo on JSFiddle and you see what we mean. When you click on the document a dot grows where you clicked and it vanishes again. If you keep the mouse pressed the dot stays and you can move it around.

    JSFiddle demo.

    Moving the dot

    The code is incredibly simple. We generate a DIV element and move it with the mouse. For this, we need JavaScript. Check the comments to see what is going on:

      // create a DIV element, give it an ID and add it
      // to the body
      var plot = document.createElement('div'),
          pressed = false; = 'clickhighlightplot';
      // define offset as half the width of the DIV
      // (this is needed to put the mouse cursor in
      // its centre)
      var offset = plot.offsetWidth / 2;
      // when the mouse is moved and the mouse button is pressed,
      // move the DIV to the current position of the mouse cursor
      document.addEventListener('mousemove', function(ev) {
        if (pressed) { moveplot(ev.pageX, ev.pageY); }
      }, false);
      // when the mouse button is pressed, add a class called
      // 'down' to the body of the element and define pressed
      // as true. Then move the DIV to the current mouse
      // position.
      document.addEventListener('mousedown', function(ev) {
        pressed = true;
        moveplot(ev.pageX, ev.pageY);
      }, false);
      // when the mouse is released, remove the 'down' class
      // from the body and set pressed to false
      document.addEventListener('mouseup', function(ev) {
        pressed = false;
      },  false);
      // move the DIV to x and y with the correct offset
      function moveplot(x, y) { = x - offset + 'px'; = y - offset + 'px';

    This takes care of creating and moving the DIV and also gives us classes on the body element to play with.

    Growing the dot

    The growing of the dot uses CSS transitions. We change the scale of the dot from 0,0 to 1,1 in a certain amount of time. Notice that we need to scale down rather than up as Webkit zooms scaled elements instead of leaving crisp outlines like Firefox does (the first iteration of this script scaled a 10×10 pixel dot upwards and looked horrible).

    #clickhighlightplot {
      cursor: pointer;
      pointer-events: none;
      background: rgba(255, 255, 10, 0.7);
      height: 100px;
      position: absolute;
      border-radius: 100px;
      -webkit-transition: -webkit-transform 1s;
         -moz-transition: -moz-transform 1s;
          -ms-transition: -ms-transform 1s;
           -o-transition: -o-transform 1s;
              transition: transform 1s;
       -webkit-transform: scale(0, 0);
          -moz-transform: scale(0, 0);
           -ms-transform: scale(0, 0);
            -o-transform: scale(0, 0);
               transform: scale(0, 0);
    .down #clickhighlightplot {
      -webkit-transform: scale(1, 1);
         -moz-transform: scale(1, 1);
          -ms-transform: scale(1, 1);
           -o-transform: scale(1, 1);
              transform: scale(1, 1);

    Fixing the “covered clickable elements” issue

    The main annoyance with the way the script works now is that you cover elements with the growing dot making them effectively unclickable. That might not be what you want which is why we need to make sure the dot covers them but still allows for clicks to go through. The good news is that there is a thing called pointer events for that. This is supported in Firefox and Webkit but sadly enough not in IE and Opera.

    Moving from JS and CSS to pure JS (but using CSS)

    Now, whilst it is cool to be able to maintain all the look and feel in CSS, the issue is that we need to repeat all the vendor prefixes and we run into issues that browsers might not support what we want to do. That’s why sometimes it makes more sense to move the whole functionality into JavaScript as we have the chance to test support there and write less code.

    Clickhighlight.js does all that. Instead of keeping the maintenance in the CSS (and requiring you to add all the vendor prefixes) you can now have the effect by simply adding the script and calling its init() method:

    <script src="clickhighlight.js"></script>

    Elements with the class “nohighlight” will not get the effect. You can change the look by passing an initialisation object:

      size:        '300px', // the maximum size of the dot
      duration:    '2s',    // duration of the effect (seconds)
      colour:      'green', // the dot colour - RGBA = transparency
      nohighlight: 'notme'  // class of elements not highlighted

    You can see it in action in this video on YouTube:

    The next steps could be to add touch support and to turn this into a bookmarklet so you can use it on any page. Any other ideas?

  4. Bret Victors "Inventing on principle" – and a few things it inspired

    Bret Victor‘s “Inventing on principle” talk (also available on YouTube in case you want to skip ahead) from this year’s CUSEC is one of these hours of your life where you watch something and go “wow”:

    Video on Vimeo.

    Bret talks about having a principle to follow when inventing new things. A principle that guides you in your decisions instead of concentrating on the product you want to build. He is not the first to do that and he mentions a few other people in the talk who took the same approach and got very successful with it.

    Bret’s big principle is that “creators need an immediate connection to what they create” and shows that right now in most cases this connection is broken. We write code, we compile, we load in a browser and we see the result. That is not immediate but a two steps removed way of creating. The same way we make animations. We create timelines, set keyframes and change values and see if it worked or not. In the talk Bret shows a few demos for tools that would break those steps down to immediacy – you code and see what you do at the same time. Much like the thing WYSIWYG editing promised us in the past but on a more creative level. Bret shows games that are created whilst playing them, how changing values in an interactive manner makes it possible for you to find different effects and even how to write algorithms simpler by having a tool that asks for values of variables you define while you code them.

    This video has been making the rounds quite a lot and it is very cool to see that whilst not finding their own guiding principle, some developers got so excited they started implementing Bret’s ideas.

    Frogatto and Friends for example is a game that has an editor that allows you to play the game and create levels at the same time.

    Cedric Vivier of the Mozilla Devtools team also took a leaf out of Bret’s book and created the Live Scratchpad extension for Firefox which makes it easy to write code much more immediate than how we do it now.

    Video on Vimeo.

    We are only just scratching the surface of what can be done with computers. Modern technologies and new ways of interacting with machines can make it much easier for people to be creative. We just need to think past our own experiences and start imagining what could come if we just allow it to.

  5. HTML5 conversion and information at Mosync hackathon in Stockholm, Sweden

    It is not often that you find yourself in a disused nuclear reactor from the 50s to talk about state-of-the-art web technology. For about a hundred developers and designers this is exactly what happened last Saturday in Stockholm, Sweden.


    The R1 reactor played host to the Mosync hackathon organised to get developers to try out the Wormhole and Reload technologies, both of which make it very easy to build apps based on HTML5 or C++ for both feature and smartphones.

    Mosync asked Mozilla to participate after a quick brownbag in their office on HTML5 a few weeks ago. So we went and gave an introduction on “HTML5 and the near-future of the web”. You can read the slides here and see a screencast with audio on YouTube.

    The topics covered in the talk are:

    And as I had some time and brought my trusty Competition Pro joystick, I thought I should give the Gamepad API a whirl and created the world’s first joystick powered kitten cube (maybe).

  6. HTML5 audio and audio sprites – this should be simple

    As we’re having a HTML5 Audio developer derby this month, I thought it fun to play with audio again. And I found it sadly enough pretty frustrating.

    One thing I proposed in a lot of talks is using the idea of CSS sprites and apply them to HTML5 audio. You’ll get the same benefits – loading one file in one HTTP request instead of many, avoiding failure as files might not get loaded and so on.

    To test this out I wrote the following small demo using the awesome Music Non Stop by Kraftwerk.

    Clicking the different buttons should play the part of the music file and nothing more. This works fine in Firefox, Chrome and Opera on my computer here. Safari, however, fails to preload the audio and the setting of the current time is off. The code is simple enough that this should work:

    <div id="buttons"></div>
    <audio preload controls>
      <source src="boing-boomchack-peng.mp3" type="audio/mp3"></source>
      <source src="boing-boomchack-peng.ogg" type="audio/ogg"></source>
    // get the audio element and the buttons container
    // define a sprite object with the names and the start and end times
    // of the different sounds.
    var a = document.querySelector('audio'),
        buttoncontainer = document.querySelector('#buttons'),
        audiosprite = {
          'all': [ 0, 5 ],
          'boing': [ 0, 1.3 ],
          'boomtchack': [ 2, 2.5 ],
          'peng': [ 4, 5 ]
        end = 0;
    // when the audio data is loaded, create the buttons
    // this way non-HTML5 browsers don't get any buttons
    a.addEventListener('loadeddata', function(ev) {
      for (var i in audiosprite) {
        buttoncontainer.innerHTML += '<button onclick="play('' +
                                      i + '')">' + i + '</button>';
    }, false);
    // If the time of the file playing is updated, compare it
    // to the current end time and stop playing when this one
    // is reached
    a.addEventListener('timeupdate', function(ev) {
      if (a.currentTime > end) {
    // Play the current audio sprite by setting the currentTime
    function play(sound) {
      if ( audiosprite[sound] ) {
        a.currentTime = audiosprite[sound][0];
        end = audiosprite[sound][1];;

    Now, this is nothing new, Remy Sharp wrote about audio sprites in 2010 and lamented especially the buggy support in iOS (audio won’t load at all until you activate it with a touch – something that sounds horribly like the “click to active” Flash has on IE).

    Other issues are looping and latency of HTML5 audio. As reported by Robert O’Callahan there is a work-around by cloning the audio element before playing it (with an incredibly annoying test) and this fix has been used in the Gladius HTML5 game engine.

    All in all it seems HTML5 audio still needs a lot of work which is why a lot of Games released lately under the banner of HTML5 use Flash audio or no audio at all. This is sad and needs fixing.

    Interestingly enough there are some great projects that you could be part of. Are we playing yet? by Soundcloud and others for example is a test suite for audio support in browsers. You can write own tests on GitHub and report results to the browser makers.

    The jPlayer team has a great HTML5 Media Event Inspector showing just how many of the HTML5 media events are supported in your current browser.

    If you want to be safe, you can use SoundManager 2 by Scott Schiller to have an API that uses HTML5 when possible and falls back to Flash when the browser doesn’t have any support. It also fixes a few issues for you.

    Speaking of Scott Schiller, he continually gives good insight on the state of audio. There is a 51 minute video of his article on 24 ways “Probably, Maybe, No: The State of HTML5 Audio“.

    A shorter and more recent talk on the same subject is also available:

    All in all it would be interesting to hear what you think of the state of HTML5 audio:

    • Did the companies that heralded HTML5 as the end of plugins drop the ball?
    • Is it really sensible to have an API that returns probably or maybe or ” when you ask it if the browser can play a certain type of media?
    • What could be done to work around these issues?

    Let’s re-ignite the discussion on HTML5 audio, after all we need it for the future of messaging in the browser and telephony, too.

    Oh and another thing. Of course there is the Audio Data API of Firefox and the web audio proposal from Webkit available but getting those running in mobile devices will be a much bigger change. If you want to know more about those and libraries to work around their differences, there is a great overview post available on Happyworm.

  7. Porting "Me & My Shadow" to the Web – C++ to JavaScript/Canvas via Emscripten

    Editors note: This is a guest post by Alon Zakai of the Mozilla Emscripten team. Thanks Alon!

    Me & My Shadow is an open source 2D game, with clever gameplay in which you control not one character but two. I happened to hear about it recently when they released a 0.3 version:

    Since I’m looking for games to port to the web, I figured this was a good candidate. It was quite easy to port, here is the result: Me & My Shadow on the Web

    Me and my shadow

    You can also get the source on GitHub.

    The port was done automatically by compiling the original code to JavaScript using Emscripten, an open-source C++ to JavaScript compiler that uses LLVM. Using a compiler like this allows the game to just be compiled, instead of manually rewriting it in JavaScript, so the process can take almost no time.

    The compiled game works almost exactly like the desktop version does on the machines and browsers I’ve tested on. Interestingly, performance looks very good. In this case, it’s mainly because most of what the game does is blit images. It uses the cross-platform SDL API, which is a wrapper library for things like opening a window, getting input, loading images, rendering text, etc. (so it is exactly what a game like this needs). Emscripten supports SDL through native canvas calls, so when you compile a game that uses SDL into JavaScript, it will use Emscripten’s SDL implementation. That implementation implements SDL blit operations using drawImage calls and so forth, which browsers generally hardware accelerate these days, so the game runs as fast as it would natively.

    For example, if the C++ code has

    SDL_BlitSurface(sprite, NULL, screen, position)

    then that means to blit the entire bitmap represented by sprite into the screen, at a specific position. Emscripten’s SDL implementation does some translation of arguments, and then calls

    ctx.drawImage(src.canvas, sr.x, sr.y, sr.w, sr.h, dr.x, dr.y, sr.w, sr.h);

    which draws the sprite, contained in src.canvas, into the context representing the screen, at the correct position and size. In other words, the C++ code is translated automatically into code that uses native HTML canvas operations in an efficient manner.

    There are some caveats though. The main problem is browser support for necessary features, the main problems I ran into here are typed arrays and the Blob constructor:

    • Typed arrays are necessary to run compiled C++ code quickly and with maximum compatibility. Emscripten can compile code without them, but the result is slower and needs manual correction for compatibility. Thankfully, all browsers are getting typed arrays. Firefox, Chrome and Opera already have them, Safari was only missing FloatArray64 until recently I believe, and IE will get them in IE10.
    • The Blob constructor is necessary because this game uses Emscripten’s new compression option. It takes all the datafiles (150 or so), packs them into a single file, does LZMA on that, and then the game in the browser downloads that, decompresses, and splits it up. This makes the download much smaller (but does mean there is a short pause to decompress). The issue though is that we end up with data for each file in a typed array. It’s easy to use the BlobBuilder for images, but for audio, they need the mimetype set or they fail to decode, and only the Blob constructor supports that. It looks like only Firefox has the Blob constructor so far, I’ve been told on Twitter there might be a workaround for Chrome that I am hoping to hear more about. Not sure about other browsers. But, the game should still work, just without sound effects and music.

    Another caveat is that there is some unavoidable amount of manual porting necessary:

    JavaScript main loops must be written in an asynchronous way: A callback for each frame. Thankfully, games are usually written in a way that the main loop can easily be refactored into a function that does one iteration, and that was the case here. Then that function that does one main loop iteration is called each frame from JavaScript. However, there are other cases of synchronous code that are more annoying, for example fadeouts that happen when a menu item is picked are done synchronously (draw, SDL_Delay, draw, etc.). This same problem turned up when I ported Doom, I guess it’s a common code pattern. So I just disabled those fadeouts for now; if you do want them in a game you port, you’d need to refactor them to be asynchronous.

    Aside from that, everything pretty much just worked. (The sole exception was that this code fell prey to an LLVM LTO bug, but Rafael fixed it.) So in conclusion I would argue that there is no reason not to run games like these on the web: They are easy to port, and they run nice and fast.

  8. Launching Evangelism Reps – getting the army of awesome ready to take the stage

    Today the Developer Engagement Team has launched the Evangelism Reps program – a special interest group within ReMo. Each year, we get thousands of requests to send Mozilla speakers around the world to talk about HTML5, new web technologies, Mozilla’s mission, our projects, products and more. Now, we would love for you to join the effort and become a Mozilla speaker too!

    This program is open to paid staff and Mozilla Reps of all skill levels and capabilities. If you are a new speaker and have always wanted to represent Mozilla at events, you can take advantage of our advanced speaker training where you can learn from people like Christian Heilmann and Robert Nyman on how to give effective presentations and get access to their best practices. People who are veteran speakers can also benefit by having the tools and resources available to host events, prepare stunning screen casts and be mentors to new Evangelism Reps.

    We encourage all current Mozilla speakers to please join our Speaker Database even if you don’t join the Evangelism Reps program. This will help us know who you are and match you up with the speaking opportunities that fit you best.

    The Evangelism Reps program information is on the wiki:

    Please contact us at if you are interested in joining the team. We anticipate our first training to be held in May so stay tuned for this exciting opportunity.

  9. People of HTML5: Andrew Betts on building the HTML5 app

    HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.

    Andrew Betts Today we are featuring Andrew Betts, director of Assanka.

    We came across Andrew because of his talk “We’ve Got a Website for That – The FT Web App and the Future of the Mobile Web” at the BlackBerry Devcon in Amsterdam where he did a great job allowing us to peek under the hood of the Financial Times web app. You can reach Andrew on Twitter as @triblondon.

    The video interview

    You can see the video on any HTML5 enabled device here (courtesy of

    10 Questions for Andrew Betts

    1) You worked on the HTML5 application for the financial times. What made you go HTML5 and not native? How many people were involved at all?

    The FT has an agnostic approach when it comes to the formats and technologies we can use to display our content. The choice has to suit the content, the reader, and our business model. Before we launched the HTML5 app there was already an FT native app on iOS, and it received an Apple design award, but HTML5 offered several significant benefits, the most important of which was to allow us to maintain a direct relationship with the reader. Secondary benefits include a faster update process, an investment in future cross-platform compatibility (HTML5 is yet to fully realise the dream of write-once, run everywhere), and freedom from restrictions and rules that are (or may be in future) imposed by app store operators.

    2) What would you say was the easiest part and what was the thing that you had to spend the most time on to make it work?

    Interactions are the hardest thing to crack. Matching behaviour to user expectations is frighteningly complex, especially when you realise that instinctive expectations of swipe behaviour is actually quite varied and inconsistent. One example of this complexity is swiping horizontally from the bottom of a section page, which takes you to the top of the next one. If you then swipe back, do you end up where you were, or at the top? So dealing with interactions is both technically hard and architecturally challenging.

    Offline behaviour is also very tough. We get a lot of “User x can’t use the app offline” style support requests, and those are very hard to debug. We log every report but the priority is to figure out the scale of the problem.

    The easiest thing to deal with is probably layout. We send all legacy browsers to so we only have to cope with the most recent major versions, and that means that generally we get good standards support for CSS.

    3) How did you deal with the differences in interfaces? A mobile has much less space than a tablet and again less than a desktop. Are you using mediaqueries to give different experiences?

    We group devices into one of four sizes based on media queries, and we vary which resources we use slightly based on the reported DPI, but most of our responsive layout logic is done in JavaScript. We make a few assumptions right now to make development easier, such as that the user cannot change the size of the browser window, except by rotating the device, so we only need to change the layout on orientation change, not in response to arbitrary resizing of the window. We also currently assume the user has no mouse cursor, so there are no hover effects.

    4) How does input get into it? Is it simple enough to build touch interfaces in HTML5 or did you have to use some trickery?

    Quite a lot of trickery is involved, unfortunately. The browser has to tread a fine line between on the one hand offering a touch API to web developers and getting out of their way to let them use it, and on the other, dealing with the fact that almost all websites are still built for keyboard and mouse, so the browser needs to help the user deal with that. We developed a polyfill called Fastclick which makes click events fire as fast as touch events, and that certainly helps us provide an experience that is as snappy as using a native app.

    We also deal with swiping in a few quite distinctly different ways. Swiping between sections is an endless carousel, and we implement the tracking and sliding ourselves, by maintaining hidden page containers to the left and right of the current view and applying CSS 3D transforms. But paging through an article requires different scroll mechanics – it has a fixed length, and we have to lay out the whole article in one go to know how many pages there are. Pages that scroll vertically are a different challenge again, and there we use a combination of leaving the browser to do scrolling natively, and simulating it where we need slightly different behaviour.

    You’ll also notice that the pages don’t ‘bounce’ when you hit the top and bottom of the page, despite that being the normal behaviour in the iOS browser. We’ve gone to quite some lengths to ensure that the user experience mirrors an app and doesn’t feel like the device ‘coping’ with a site that hasn’t been designed to be viewed using a device with touch input.

    5) You said in your talk at Blackberry Devcon that you are using localStorage to cache your JavaScript libraries and some of the images. Why not use WebSQL or IndexDB for that? Isn’t the synchronous nature of localStorage slowing things down?

    No, actually localStorage is considerably faster than WebSQL (we are yet to use IndexedDB because it’s not supported on some of our target platforms). The time required for a lookup by key in localStorage is many times less than the equivalent SELECT statement on a WebSQL table. It’s true that it’s synchronous, but if the critical aspect affecting perceived performance is the time required to fetch data, which it often is, then localStorage offers a much faster response. it’s also typically reliable and relatively stable compared to the behaviour of WebSQL and particularly the HTML5 app cache.

    6) You also said that localStorage uses UTF-16 instead of UTF-8. This means you can store two ASCII characters in one UTF-16 one and thus double the storage capacity, right? Can you share some code? This would be incredible to use for everybody out there.

    Both localStorage and WebSQL use UTF-16 in webkit browsers, it’s one of many aspects of the implementation of these technologies that don’t make a lot of sense! We’re experimenting with some algorithms for compressing our data so we can make more efficient use of that storage, and one of those is to combine two characters into a single UTF-16 one. We’re not using that in production yet, but when we do we’re certainly hoping to open source it.

    There are simpler things to be done as well. A cursory poke and prod of WebSQL tables suggest that column names are stored along with the value in every cell, so some attempts to increase efficiency are as simple as using single character column names. Clearly we ought not to have to do all this, but it’s the price you pay for dealing with bleeding edge features in browsers.

    7) What would you consider the best start for someone when they want to build an HTML5 app? What are the first things to get sorted?

    Decide ahead of time what you’re trying to achieve. I could be a pedant and say that making your site HTML5 is really just a matter of changing the DOCTYPE, so an ‘HTML5 app’ is really whatever you define it to be, and having a clear idea of that is a good place to begin. Are you building something just for touch, or for keyboard and mouse as well? Does it need to work offline? Will it be crawlable by search spiders? Will it work with JavaScript disabled?

    There are some great resources like MDN, but we often find ourselves reading the HTML5 specs, and sometimes even the webkit source code to find out how something is actually implemented.

    8) Can native and web apps be the same thing?

    Technically, I guess not – strictly speaking a native app is complied code running directly on a platform, but the hybrid model seems to be getting ever more popular, and I often see apps which are thinly veiled web browsers. If you look at it from the user perspective and say, can a web app feel exactly like a native app, I don’t see why not. The challenges are greater because of the diversity of uses that web technologies are designed for, and the diversity of platforms on which they are used. And for uses such as gaming, native code is always likely to run faster and have deeper access to the OS.

    But for applications like publishing, which after all was the original purpose of the web, web technologies do provide support for most of the user experience concepts that we need.

    9) What about testing? How did you approach this? Do you have an array of hardware to play with?

    It’s a nightmare. We had a local electrician built us a charging station where we could store all our devices and keep them charged all the time. We have around 45 individual devices in our team (that’s around 4 times more devices than we have people). We’re constantly looking at ways of improving our testing process, and we keep revisiting automated, on device testing, but we’re not using it in our build cycle as yet. Right now we have a team of very dedicated testers who poke and prod devices all day.

    10) As someone who went through the process of building a big HTML5 app, what would you like to have from browser vendors to make your life easier?

    A blithe answer is ‘How long do you have’, but in practice we have to accept we’re using freshly minted technologies and there might be teething troubles. The main things on our shopping list are: more frequent and aggressive browser updates (especially on Android, where the browser is the problem child of the mobile web world), a better and more reliable app cache, and hardware acceleration of CSS transforms.

  10. Making the Dino roar – syncing audio and CSS transitions

    It started with Brian King setting up our Google+ page using this round MDN logo by John Slater. I thought this looks cool and reminded me of the famous MGM intro so I wondered if I could turn it into an intro for our video tutorials (not sure if we will do that though). And, some photoshop and sound work later and with a sprinkle of HTML5 audio and CSS transitions, here we are (source on GitHub):

    I started with the sound. If you need Creative Commons licensed sounds, Freesound is a good resource. So I took Chinese Fanfare by Nick-Nack and Roar by CGEffex and put them together in Audacity.

    Saving them as OGG and MP3 gave me an audio element that I could tie into. All I needed was to listen to the timeupdate event and compare the currentTime to trigger the animations. The animations (rotation of the dino and opening and closing of the jaw) are CSS transitions triggered by classes on the parent element. The main trick was to store both the dino and the jaw inside a div and transition them separately. The jaw animation also needed a change in transformation origin as we don’t rotate the image around its center.

    If you got seven minutes to spare, here is a blow-by-blow screencast explaining what is going on: