Found 435 results for “html5”

Sort by:


  1. There is no simple solution for local storage

    TL;DR: we have to stop advocating localStorage as a great opportunity for storing data as it performs badly. Sadly enough the alternatives are not nearly as supported or simple to implement.

    When it comes to web development you will always encounter things that sound too good to be true. Sometimes they are good, and all that stops us from using them is our notion of being conspicuous about *everything* as developers. In a lot of cases, however, they really are not as good as they seem but we only find out after using them for a while that we are actually “doing it wrong”.

    One such case is local storage. There is a storage specification (falsely attributed to HTML5 in a lot of examples) with an incredibly simple API that was heralded as the cookie killer when it came out. All you have to do to store content on the user’s machine is to access the navigator.localStorage (or sessionStorage if you don’t need the data to be stored longer than the current browser session):

    localStorage.setItem( 'outofsight', 'my data' );
    console.log( localStorage.getItem( 'outofsight' ) ); // -> 'my data'

    This local storage solution has a few very tempting features for web developers:

    • It is dead simple
    • It uses strings for storage instead of complex databases (and you can store more complex data using JSON encoding)
    • It is well supported by browsers
    • It is endorsed by a lot of companies (and was heralded as amazing when iPhones came out)

    A few known issues with it are that there is no clean way to detect when you reach the limit of local storage and there is no cross-browser way to ask for more space. There are also more obscure issues around sessions and HTTPS, but that is just the tip of the iceberg.

    The main issue: terrible performance

    LocalStorage also has a lot of drawbacks that aren’t quite documented and certainly not covered as much in “HTML5 tutorials”. Especially performance oriented developers are very much against its use.

    When we covered localStorage a few weeks ago using it to store images and files in localStorage it kicked off a massive thread of comments and an even longer internal mailing list thread about the evils of localStorage. The main issues are:

    • localStorage is synchronous in nature, meaning when it loads it can block the main document from rendering
    • localStorage does file I/O meaning it writes to your hard drive, which can take long depending on what your system does (indexing, virus scanning…)
    • On a developer machine these issues can look deceptively minor as the operating system cached these requests – for an end user on the web they could mean a few seconds of waiting during which the web site stalls
    • In order to appear snappy, web browsers load the data into memory on the first request – which could mean a lot of memory use if lots of tabs do it
    • localStorage is persistent. If you don’t use a service or never visit a web site again, the data is still loaded when you start the browser

    This is covered in detail in a follow-up blog post by Taras Glek of the Mozilla performance team and also by Andrea Giammarchi of Nokia.

    In essence this means that a lot of articles saying you can use localStorage for better performance are just wrong.


    Of course, browsers always offered ways to store local data, some you probably never heard of as shown by evercookie (I think my fave when it comes to the “evil genius with no real-world use” factor is the force-cached PNG image to be read out in canvas). In the internal discussions there was a massive thrust towards advocating IndexedDB for your solutions instead of localStorage. We then published an article how to store images and files in IndexedDB and found a few issues – most actually related to ease-of-use and user interaction:

    • IndexedDB is a full-fledged DB that requires all the steps a SQL DB needs to read and write data – there is no simple key/value layer like localStorage available
    • IndexedDB asks the user for permission to store data which can spook them
    • The browser support is not at all the same as localStorage, right now IndexedDB is supported in IE10, Firefox and Chrome and there are differences in their implementations
    • Safari, Opera, iOS, Opera Mobile, Android Browser favour WebSQL instead (which is yet another standard that has been officially deprecated by the W3C)

    As always when there are differences in implementation someone will come up with an abstraction layer to work around that. Parashuram Narasimhan does a great job with that – even providing a jQuery plugin. It feels wrong though that we as implementers have to use these. It is the HTML5 video debate of WebM vs. H264 all over again.

    Now what?

    There is no doubt that the real database solutions and their asynchronous nature are the better option in terms of performance. They are also more matured and don’t have the “shortcut hack” feeling of localStorage. On the other hand they are hard to use in comparison, we already have a lot of solutions out there using localStorage and asking the user to give us access to storing local files is unacceptable for some implementations in terms of UX.

    The answer is that there is no simple solution for storing data on the end users’ machines and we should stop advocating localStorage as a performance boost. What we have to find is a solution that makes everybody happy and doesn’t break the current implementations. This might prove hard to work around. Here are some ideas:

    • Build a polyfill library that overrides the localStorage API and stores the content in IndexedDB/WebSQL instead? This is dirty and doesn’t work around the issue of the user being asked for permission
    • Implement localStorage in an asynchronous fashion in browsers – actively disregarding the spec? (this could set a dangerous precedent though)
    • Change the localStorage spec to store asynchronously instead of synchronously? We could also extend it to have a proper getStorageSpace interface and allow for native JSON support
    • Define a new standard that allows browser vendors to map the new API to the existing supported API that matches the best for the use case?

    We need to fix this as it doesn’t make sense to store things locally and sacrifice performance at the same time. This is a great example of how new web standards give us much more power but also make us face issues we didn’t have to deal with before. With more access to the OS, we also have to tread more carefully.

  2. March Dev Derby: Show us what you can do with CSS 3D transforms

    The March Dev Derby begins today! A monthly contest hosted by the Mozilla Developer Network, the Dev Derby allows creative web developers to push the web forward and compete for fame, glory, and prizes too.

    This month, we want to see what you can do with CSS 3D transforms. New to the topic? That’s okay. We have a great article on CSS 3D transforms over on the MDN that should help you get started. Additionally, Mozilla principal evangelist Chris Heilmann has contributed three great resources on the topic: an article on getting started, an article on progressively enhanced rollovers, and a screencast on rollovers. With all this great documentation, you’ll be an expert in no time.

    The Prizes

    • First place: An Android mobile device from Motorola or Samsung and an article featuring your work here on Mozilla Hacks.
    • Second place: A hand-crafted laptop messenger bag from Rickshaw.
    • Third place: A limited edition MDN t-shirt to show off your geek cred.

    You might have noticed that the March Derby already has three entries. Want to get a head start like these people did? We are also accepting entries related to HTML5 audio (April Derby) and the Websocket API (May Derby). Submit today!

  3. Presentation: HTML5 and friends at Mobile World Congress 2012

    As part of the WIP Jam at the Mobile World Congress in Barcelona, Spain we were asked to give and introduction to HTML5 so we sent Chris Heilmann and Joe Stagner to set the record straight in terms of what HTML5 is and what you can do with it.

    The presentation was on the last day of the conference and both of us had spent long hours explaining all Mozilla technologies on our booth and really not enough hours sleeping in between. In addition to that the room was a boiling 30 degrees and packed with lots of developers. It seems we did a good job regardless as nobody left and we had a lot of great questions afterwards.

    The slides (well, the HTML5 document) are available for you to see:

    Slides for HTML5 and friends

    However, they make much more sense when you see them in context, which is why we also provide you with a screencast of the talk:

    All in all it was a lot of fun talking to people at MWC and Boot to Gecko showed that HTML5 is the future of mobile as much as it is already the present technology of choice on the desktop.

  4. Friday fun: Trigger Rally in WebGL

    As reported by Creative JS, Jasmine Kent ported her open source Linux racing game Trigger Rally to WebGL to run in HTML5 browsers. In the following video you can see it running pretty smoothly on my MacBook air that is already running 12% of CPU without it starting (as ScreenFlow is recording and VLC was playing music whilst TweetDeck used quite a chunk, too):

    If you are the artistic type, you can even design your own levels for the game.

    You can play play Trigger Rally online here: or follow it on Twitter @triggerrally.

  5. Rounding-up the first Mozilla HTML5 games work week

    A few weeks ago I wrote about the first Mozilla HTML5 games work week in Toronto and why it is important. In this post I summarise the week’s events and highlight some key observations.


    Before I start I should point out that I won’t be making any dramatic announcements from Mozilla or going into too much detail about some of the decisions that were made during the work week. While some important discussions and decisions did occur, some aren’t quite ready to be made public yet. However, we will be posting specifically about some of these things in the coming weeks so keep an eye open. The purpose of this post is to give an overview of the week’s events and some of the discussions that were made.

    So with that out of the way, let’s crack on.

    Why a HTML5 games work week?

    With the amount of buzz happening around HTML5 and JavaScript, it could be seen as surprising that we hadn’t organised a get-together of all the interested parties within Mozilla sooner. The long and short of it is that it has only been recently that we have begun to construct a consistent vision and commitment to HTML5 games.

    To create a vision we need to find out who within the Mozilla community is actually interested in games and how we can work together to lay the path towards the future. The HTML5 games work week was set up to start the ball rolling. It’s safe to say that Mozilla cares a lot about games and this work week is just the beginning.

    Aside from the internal interest and passion to build games, there are an increasing number of HTML5 games being released in the Web community each and every week. This shows that there is desire for these types of games and for browsers to work out how to support them.


    It’s also clear that there are areas of improvement that need to be addressed within all browsers so that HTML5 games can flourish in the future. The point of the work week has been to bring all interested parties together in one place to make stuff happen and actually make decisions about how to address these issues.

    From another perspective, the work week gave Mozilla the chance to listen to external developers and hear about the issues they are experiencing in the real world of HTML5 game development. We don’t develop games every day, so it is of absolute importance for us to fully understand the concerns of the people who do. Without this type of feedback we simply won’t be able to make our improvements as useful as they could be.

    Who was there?

    The work week was split into 2 parts: the first was attended by Mozilla staff and key Mozilla contributors, and the second included some invited external guests.


    It was clear from the beginning that we had a whole bunch of people within Mozilla who were passionate about games and wanted to see us commit to them. I already knew a handful of these people, but I had absolutely no idea that so many Mozillians from so many different areas of the organisation were so interested. It great to see all those people in one (big) room working together to make awesome stuff happen.

    The invited guests for the second part of the work week included developers from game studios like EA, as well as individual developers who have proven themselves experts in specific technologies, like WebGL. We worked with these guests to hear about issues from the guys dealing with this stuff every single day. It was absolutely fascinating to hear their concerns and work with them to find ways of improving the situation for games on the Web.

    What was discussed?

    Throughout the week we discussed a whole variety of topics ranging from how to better engage with the game developer community all the way to narrowing down fine-grained performance improvements to be made in JavaScript.


    Overall, both the internal Mozilla staff and invited guests covered the following areas and many more (in no particular order):

    • Looking into the issue of mobile and how its requirements differ from those on the desktop
    • Working out what tools are needed for authoring HTML5 games
    • Graphics, specifically Canvas and WebGL
    • Delving into the issues surrounding DRM and the protection of assets
    • NaCl and Emscripten as methods of porting existing games to the Web
    • Being clear about who exactly wants HTML5 games
    • Looking at what dev tools are required to ease the debugging of games
    • Learning the business model behind games from those with years of experience in this area
    • Working out how to better engage with the game development community
    • Producing a roadmap for the Firefox platform specifically related to games
    • Looking at ways JavaScript performance could be increased
    • Discussing the situation with asset management and how it can be solved
    • Uncovering any new WebAPIs that might become necessary
    • Delving deep into common audio issues and looking at its future
    • Hearing how high-precision timers would be used by game developers
    • Learning about WebRTC and how it will provide the functionality for peer-to-peer communication
    • Looking at how games tie into the Mozilla Marketplace and the questions that Mozilla needs to answer in this area

    All in all we covered a huge amount of stuff in the space of just a few days. I won’t list each and every decision that was made but rest assured that you’ll be hearing about them in the near-future as they get finalised and released.

    In the meantime, please check out the Are We Fun Yet site as it’s where you’ll be able to keep tabs on the status of game-related technology within Mozilla. There are also some links to the detailed feedback and notes taken during this work week.

    External demos and code review

    During the final 2 days of the work week we saw demos from our external guests and worked with them to review specific issues that they have been experiencing in Firefox.


    These demos proved invaluable for those within Mozilla to get a better idea of how professional game developers are using the technologies on the Web. We were inspired and amazed by the quality of these demos and the kind of games that could be created by pushing JavaScript right to the very limits.

    As a result of these demos and code reviews, issues have been pinned down, test-cases written, and in some cases even fixes produced there and then. It was really a very useful aspect of the work week that we clearly need to explore further in the future.

    What’s next?

    So, what does that future look like for Mozilla and game development? Frankly, very bright indeed. There is so much interest and desire within Mozilla to further the Web as a platform for games. It’s clear that we have the knowledge and resources, we just need to work out how best to apply them.

    While we work on refining our position on games and exactly how we’re going to tackle them, there are a few things that I can say for sure about the future.

    The first is that we’re dedicated to helping developers learn how to use Web technologies, that’s the reason why MDN and this blog exist. We’ve started to work on ways to help developers learn how to use Web technologies to create games. We’re not quite there yet but it’s a priority.

    Stack of gamepads

    Aside from MDN, we are going to be reaching out to developers at game-related events. At some events we’ll be even bringing along hardware for you to play with and hack with JavaScript APIs, like gamepads for the Gamepad API. We’ll also be present at some of the larger events like GDC so we can keep up to speed with the game world and talk to developers about the issues they’re facing.

    You’ll also see games as a focus on this year’s Mozilla Festival. We’re refining the program but we’re working on tying in elements like the successful Game On competition that we ran last year.

    Documenting the game-related decisions and discussions within Mozilla is key, and it is something that we’re working on improving. For now the best place to keep up to date is this blog, the #games channel on, and the HTML5 games page on the Mozilla wiki.

    With recent announcements it’s clear that Boot to Gecko (B2G) and games will be an area that Mozilla and the developer community will explore in the near future. It will be interesting to see what people do with a mobile platform as open and hackable as B2G.

    I could go on but it’s safe to say that there is a whole bunch of stuff happening around games at Mozilla, it’s an exciting time indeed. No doubt we’ll have another work week in the coming months to take stock and take more steps in the right direction.

  6. Accepting February Dev Derby entries for one extra day

    Wait a minute, there are how many days in February?

    Looks like leap day got the best of us. Earlier today, we ended the February Dev Derby prematurely, making it impossible for some of you to submit those last-minute demos for a couple of hours.

    To make up for this oversight, we will accept February Dev Derby submissions for one extra day. Please submit your entry before March 1 at 11:59:59 p.m. PT for them to be counted.

    Want to get a head start on an upcoming Derby? We are now accepting entries related to CSS 3D Transforms (March) and HTML5 audio (April). Submit today!

  7. Q & A With Michal Biniek: HTML5 Hacker and Frequent Dev Derby Winner

    Editor’s Note: Michal Biniek is a frontend developer on the Innogames Lagoonia team, and an enthusiast of JavaScript and new web technologies like HTML5/CSS3, WebSockets, and WebRTC. Back in November, michal.b took 2nd place in the MDN Developer Derby with Rob in Soundland, a fanciful Canvas demo.

    It was the fourth time one of Michal’s demos made to the Derby finals, and it was the third time he’d placed. If you’ve been following Dev Derby since it launched last year, you might remember seeing Fly, fly! or Too Many Fish in the Sea. Congratulations Michal, we can’t wait to see your next demo! Submissions are now open for upcoming Derbies: CSS 3D transforms, Audio, and the Web Sockets API.

    Tell us about developing Rob in Soundland and where your idea came from?

    My first idea for the Canvas demo was to prepare some kind of visualization – a sound visualization which could make a nice connection between two senses – vision and hearing. I thought it would be also nice if the user could interact with the application through keyboard or mouse.

    Finally I decided to prepare a simple game with third-person view in an infinite world, where the main character – Rob – wanders through the colorful (almost psychedelic) squares which are playing different notes.

    Interesting fact is that the game doesn’t contain any external media elements like images or sounds. Everything is generated using HTML5 technologies: Images are pre-generated at the start of the game and sounds are created and played ad hoc using the Audio Data API.

    Rob in Soundland - Canvas demo screenshot

    Do you remember your first computer and your first website?

    My first computer was Elwro Junior – the Polish version of a ZX Spectrum computer (English description here). A few years later I got my first PC with a 486 25MHz processor inside and a magical ‘turbo’ button.

    My history with websites started around 1999 when I prepared a site about my hobbies – skiing and astronomy. I even put some animations using JavaScript and DHTML (a buzzword from long ago):
    Never the marquee tag ;)

    How did you get started coding and hacking?

    I started coding on ZX Spectrum in BASIC, but shortly after that I moved to Turbo Pascal on the new PC. I think it is also important that my father was an IT teacher at school – so when I had some problems with programming I could always ask him for help.

    For me, the visual is one of the most important aspects of an application. That’s why I found Delphi/C++ Builder a really nice solution for building UIs. This is also the reason why I liked HTML from the beginning – as a perfect language for UIs, which with JavaScript is much easier to run animations rather that trying to run it on forms.

    You mentioned you’re from Wroclaw, Poland, and work as a Web developer for Innogames? Do you work remotely? What tools do you use for development?

    Actually, I live in Hamburg, where I got the software developer job at Innogames half a year ago. However, I still quite often visit Wroclaw.

    I’m working in team that works on Lagoonia, one of the latest games developed by Innogames. Modern Javascript engines in browsers enable us to take full advantage of JavaScript (and new features from HTML5 like sound and canvas). We can create games which easily compete with Flash-based games without additional runtime machine!

    Lagoonia by Innogames

    I usually use Eclipse to develop JavaScript applications. I find it a quite good code editor (however sometimes slow) with code auto-completion that works quite well. For testing and debugging, I use Firebug and the built-in console in Firefox, one of the best debugging tools for web applications ever.

    Do you play online games? What games influence your work? What do you play the most these days?

    I discovered online games while I was a student. I started with FPS shooters then switched to MMORPGs like MuOnline. I think that multiplayer games are the future of gaming – it is usually much more fun to play with real players rather than against a computer.

    My current company – Innogames is also focused on online games (mainly browser games) where the most important part is cooperation with other users.

    We can still observe old games (even from the days of the ZX Spectrum) refreshed with new fancy graphics and multiplayer mode which are bestsellers nowadays. However, many indie games show us completely new concepts of games – and I think these types of games influence me the most.

    Apart from that, I really like Valve games – especially for great stories in games like Half Life/Portal universum.

    The Nyan Cat version of your August History API demo reminded us how fast memes can travel on the Internet. Tell us about Fly, fly! and how the idea came to you?

    It was quite hard to find an original idea for the usage of History API, which in my opinion is prepared especially for websites using AJAX to set up the content. However, it could also be used as a timeline for virtual travels. The initial idea for this project was a flight by plane through the different cities.
    However I found it boring and I decided to add the popular Nyan Cat – one of the most positive memes – as an optional mean of transport. This choice causes the Nyan Cat to leave a rainbow-colored contrail in the sky, instead of leaving white lines, which makes the world more colorful and friendly for people.

    In addition, everything was matched to the original concept of the demo, even the different graphics looks much better – dark background, Nyan Cat instead of a plane, and a colorful path for the journey.

    Fly, fly - History API demo

    You’ve submitted 7 Dev Derby demos since the program launched, and 4 of them have placed as finalists. Congratulations and thank you! Are you working on another demo? Any other cool projects you want to tell us about?

    Thank you! Currently I’m working on another simple game using touch events, however a project grew up a bit and I’m not sure if I’ll find enough time to finish it before the deadline.
    Zombie-kiwi-touchevents-demo screenshot

    In the meantime I’m working with my colleague Barry Nagel on our own framework for HTML5 games, which is named Machine5. The goal of this project is to find the simplest way to create stunning HTML5 games and to provide a simple and easily maintainable project structure for developers.

    Machine5 game engine

    When you think about HTML5 & new Web technologies what are you most excited about?

    I’m really glad that the Canvas element is currently widely available and I can freely use it. It is a perfect solution for simple games – and I hope soon WebGL will be also available on all browsers, because it is a great feature that allows creating fullscreen games. Using these technologies together with new audio APIs and WebSockets or WebRTC as a communication stream, we can soon expect real FPS games like Counter Strike or a less violent type of game such as Sims MMO version ;)

    Anybody else who helps on your demos? Anyone you want to mention?

    I’d like to thank to Robert Zatycki for all the brainstorms about possible ideas for games and other applications. Some concepts which we were talking about were used in games.

    And I’d also like to thank to my brothers – Paweł and Łukasz who tested carefully my demos before I released them and for their frank feedback.

    What inspired you to participate in Dev Derby? Can you say something more about Open Source, Mozilla and why you contribute?

    Before the Dev Derby contest, I’d prepared some demos for Chrome Experiments and for Opera Widgets websites. Then I got a message from John Karahalis, where he mentioned a new Mozilla project for demos especially for new technologies.

    Currently I find the MDN is one of the best resources for JavaScript. All the work done by Mozilla to contribute, prepare and promote new technologies is great and really important for the modern internet. Firefox is one of the most popular web browsers, (and in Poland the most popular!) which I think is the best example that users also appreciate Mozilla’s excellent product.

    One idea of Open Source is really important: even nowadays when almost every concept can be patented, there are still a lot of people who are open to sharing their experience with other developers without any profit. I find that sharing code can be the best way to get feedback about code quality and to get suggestions for other possible (sometimes better) solutions for an application.

  8. The Mozilla Marketplace is now open for app submissions

    The Web IS the Platform!

    Using HTML, CSS and JavaScript, a developer can build an app using responsive design, and that app can offer the same look and feel as a device-native app, without having to rewrite for every desired target platform. One code base – all popular devices!

    Now, developers can build apps and submit them to the Mozilla Marketplace, so that when the consumer side of the marketplace launches later this year, your apps will be listed and consumers will be able to begin installing and using your apps from the first day of business.

    Why use standards-based Web Development for apps?

    Developers and organizations large and small have expressed interested in building apps for the Mozilla Marketplace. These apps are built using HTML5 for app structure; CSS3 for layout, visual aesthetics, and visual behaviors; and JavaScript for logical implementation.

    This combination of the latest standards-based Web development technologies is enjoying unprecedented popularity and is changing the way we build both websites and apps.

    As always, Mozilla is actively participating in the open Web standards processes and leading the community to define the necessary extensions to existing technology that will permit developers to build apps without technical impedance. For more detail, read Brendan Eich’s recent post on Mobile Web API Evolution.

    On the platform side we’re not only working on the standard “Web technology stack,” but also on all of the device APIs that will ultimately make the platform “rock.”

    For right now, we are focused on supporting mobile apps that will run across all modern, HTML5 capable Web browsers.

    The Mozilla Web Apps platform will feature:

    • The Mozilla Marketplace, the first operating system- and device-independent market for apps based on open Web technologies like HTML5, JavaScript and CSS.
    • New Mozilla-proposed APIs that advance the Web as a platform and will be submitted to the W3C for standardization.
    • A new identity system for the Web that puts users in control of their content, tying apps to the user and not the device or platform.

    Why build apps for the Mozilla Marketplace?

    The Web is the world’s largest single marketplace. By exposing apps through Mozilla’s existing communities, an app can launch to a marketplace of nearly half a billion prospective customers. Developers can also offer their apps via their own sites.

    On the Marketplace side, we’ve been working on identity integration with Persona (BrowserID). We’re also developing payments, app sync, backup and recovery, as well as an outstanding online app discovery and acquisition experience, so that both consumers and developers can easily get what they want from the Marketplace experience, on the front side or on the back end.

    What’s in this release?

    The Mozilla Marketplace is now open for developer app submissions. That means you can secure your app’s name and place in the Marketplace in preparation for the consumer launch later this year and familiarize yourself with the developer side of the Marketplace process.

    So, follow these links below to get started building your apps and then submit them to the Mozilla Marketplace!

    Apps on MDN -
    Mozilla Apps Wiki -
    HTML5 Docs -
    Mozilla Persona -

    And, join the discussions: for marketplace specific questions. for general apps questions.