Mozilla

Found 443 results for “html5”

Sort by:

View:

  1. Video, Mobile, and the Open Web

    [Also posted at brendaneich.com.]

    I wrote The Open Web and Its Adversaries just over five years ago, based on the first SXSW Browser Wars panel (we just had our fifth, it was great — thanks to all who came).

    Some history

    The little slideshow I presented is in part quaint. WPF/E and Adobe Apollo, remember those? (Either the code names, or the extant renamed products?) The Web has come a long way since 2007.

    But other parts of my slideshow are still relevant, in particular the part where Mozilla and Opera committed to an unencumbered <video> element for HTML5:

    • Working with Opera via WHATWG on <video>
      • Unencumbered Ogg Theora decoder in all browsers
      • Ogg Vorbis for <audio>
      • Other formats possible
      • DHTML player controls

    We did what we said we would. We fought against the odds. We carried the unencumbered HTML5 <video> torch even when it burned our hands.

    We were called naive (no) idealists (yes). We were told that we were rolling a large stone up a tall hill (and how!). We were told that we could never overcome the momentum behind H.264 (possibly true, but Mozilla was not about to give up and pay off the patent rentiers).

    Then in 2009 Google announced that it would acquire On2 (completed in 2010), and Opera and Mozilla had a White Knight.

    At Google I/O in May 2010, Adobe announced that it would include VP8 (but not all of WebM?) support in an upcoming Flash release.

    On January 11, 2011, Mike Jazayeri of Google blogged:

    … we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

    These changes will occur in the next couple months….

    A followup post three days later confirmed that Chrome would rely on Flash fallback to play H.264 video.

    Where we are today

    It is now March 2012 and the changes promised by Google and Adobe have not been made.

    What’s more, any such changes are irrelevant if made only on desktop Chrome — not on Google’s mobile browsers for Android — because authors typically do not encode twice (once in H.264, once in WebM), they instead write Flash fallback in an <object> tag nested inside the <video> tag. Here’s an example adapted from an Opera developer document:

    <video controls poster="video.jpg" width="854" height="480">
     <source src="video.mp4" type="video/mp4">
     <object type="application/x-shockwave-flash" data="player.swf"
             width="854" height="504">
      <param name="allowfullscreen" value="true">
      <param name="allowscriptaccess" value="always">
      <param name="flashvars" value="file=video.mp4">
      <!--[if IE]><param name="movie" value="player.swf"><![endif]-->
      <img src="video.jpg" width="854" height="480" alt="Video">
      <p>Your browser can't play HTML5 video.
     </object>
    </video>
    

    The Opera doc nicely carried the unencumbered video torch by including

     <source src="video.webm" type="video/webm">
    

    after the first <source> child in the <video> container (after the first, because of an iOS WebKit bug, the Opera doc said), but most authors do not encode twice and host two versions of their video (yes, you who do are to be commended; please don’t spam my blog with comments, you’re not typical — and YouTube is neither typical nor yet completely transcoded [1]).

    Of course the ultimate fallback content could be a link to a video to download and view in a helper app, but that’s not “HTML5 video” and it is user-hostile (profoundly so on mobile). Flash fallback does manage to blend in with HTML5, modulo the loss of expressiveness afforded by DHTML playback controls.

    Now, consider carefully where we are today.

    Firefox supports only unencumbered formats from Gecko’s <video> implementation. We rely on Flash fallback that authors invariably write, as shown above. Let that sink in: we, Mozilla, rely on Flash to implement H.264 for Firefox users.

    Adobe has announced that it will not develop Flash on mobile devices.

    In spite of the early 2011 Google blog post, desktop Chrome still supports H.264 from <video>. Even if it were to drop that support, desktop Chrome has a custom patched Flash embedding, so the fallback shown above will work well for almost all users.

    Mobile matters most

    Android stock browsers (all Android versions), and Chrome on Android 4, all support H.264 from <video>. Given the devices that Android has targeted over its existence, where H.264 hardware decoding is by far the most power-efficient way to decode, how could this be otherwise? Google has to compete with Apple on mobile.

    Steve Jobs may have dealt the death-blow to Flash on mobile, but he also championed and invested in H.264, and asserted that “[a]ll video codecs are covered by patents”. Apple sells a lot of H.264-supporting hardware. That hardware in general, and specifically in video playback quality, is the gold standard.

    Google is in my opinion not going to ship mobile browsers this year or next that fail to play H.264 content that Apple plays perfectly. Whatever happens in the very long run, Mozilla can’t wait for such an event. Don’t ask Google why they bought On2 but failed to push WebM to the exclusion of H.264 on Android. The question answers itself.

    So even if desktop Chrome drops H.264 support, Chrome users almost to a person won’t notice, thanks to Flash fallback. And Apple and Google, along with Microsoft and whomever else might try to gain mobile market share, will continue to ship H.264 support on all their mobile OSes and devices — hardware-implemented H.264, because that uses far less battery than alternative decoders.

    Here is a chart of H.264 video in HTML5 content on the Web from MeFeedia:

    MeFeedia.com, December 2011

    And here are some charts showing the rise of mobile over desktop from The Economist:

    The Economist, October 2011

    These charts show Bell’s Law of Computer Classes in action. Bell’s Law predicts that the new class of computing devices will replace older ones.

    In the face of this shift, Mozilla must advance its mission to serve users above all other agendas, and to keep the Web — including the “Mobile Web” — open, interoperable, and evolving.

    What Mozilla is doing

    We have successfully launched Boot to Gecko (B2G) and we’re preparing to release a new and improved Firefox for Android, to carry our mission to mobile users.

    What should we do about H.264?

    Andreas Gal proposes to use OS- and hardware-based H.264 decoding capabilities on Android and B2G. That thread has run to over 240 messages, and spawned some online media coverage.

    Some say we should hold out longer for someone (Google? Adobe?) to change something to advance WebM over H.264.

    MozillaMemes.tumblr.com/post/19415247873

    Remember, dropping H.264 from <video> only on desktop and not on mobile doesn’t matter, because of Flash fallback.

    Others say we should hold out indefinitely and by ourselves, rather than integrate OS decoders for encumbered video.

    I’ve heard people blame software patents. I hate software patents too, but software isn’t even the issue on mobile. Fairly dedicated DSP hardware takes in bits and puts out pixels. H.264 decoding lives completely in hardware now.

    Yes, some hardware also supports WebM decoding, or will soon. Too little, too late for HTML5 <video> as deployed and consumed this year or (for shipping devices) next.

    As I wrote in the newsgroup thread, Mozilla has never ignored users or market share. We do not care only about market share, but ignoring usability and market share can easily lead to extinction. Without users our mission is meaningless and our ability to affect the evolution of open standards goes to zero.

    Clearly we have principles that prohibit us from abusing users for any end (e.g., by putting ads in Firefox’s user interface to make money to sustain ourselves). But we have never rejected encumbered formats handled by plugins, and OS-dependent H.264 decoding is not different in kind from Flash-dependent H.264 decoding in my view.

    We will not require anyone to pay for Firefox. We will not burden our downstream source redistributors with royalty fees. We may have to continue to fall back on Flash on some desktop OSes. I’ll write more when I know more about desktop H.264, specifically on Windows XP.

    What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile.

    Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance. So I am fully in favor of Andreas’s proposal.

    Our mission continues

    Our mission, to promote openness, innovation, and opportunity on the Web, matters more than ever. As I said at SXSW in 2007, it obligates us to develop and promote unencumbered video. We lost one battle, but the war goes on. We will always push for open, unencumbered standards first and foremost.

    In particular we must fight to keep WebRTC unencumbered. Mozilla and Opera also lost the earlier skirmish to mandate an unencumbered default format for HTML5 <video>, but WebRTC is a new front in the long war for an open and unencumbered Web.

    We are researching downloadable JS decoders via Broadway.js, but fully utilizing parallel and dedicated hardware from JS for battery-friendly decoding is a ways off.

    Can we win the long war? I don’t know if we’ll see a final victory, but we must fight on. Patents expire (remember the LZW patent?). They can be invalidated. (Netscape paid to do this to certain obnoxious patents, based on prior art.) They can be worked around. And patent law can be reformed.

    Mozilla is here for the long haul. We will never give up, never surrender.

    /be

    [1] Some points about WebM on YouTube vs. H.264:

    • Google has at best transcoded only about half the videos into WebM. E.g., this YouTube search for “cat” gives ~1.8M results, while the same one for WebM videos gives 704K results.
    • WebM on YouTube is presented only for videos that lack ads, which is a shrinking number on YouTube. Anything monetizable (i.e., popular) has ads and therefore is served as H.264.
    • All this is moot when you consider mobile, since there is no Flash on mobile, and as of yet no WebM hardware, and Apple’s market-leading position.

  2. Announcing the January Dev Derby Winners

    HTML5 orientation allows web developers to read the motion and orientation data of devices to create more engaging and more interactive web experiences.

    Recently, creative developers from around the world demonstrated just how powerful orientation can be in the January Dev Derby. After careful consideration, our three new judges—Remy Sharp, Chris Coyier, and Chris Heilmann—are proud to announce that they have decided on three winners and two runners-up. Please join us in congratulating these contributors!

    First Place: Help UFO by michal.b
    Second Place:
    Pinball Maze by CarsonMcDonald
    Third Place:
    Orientation Tetris by nestoralvaro

    Runners Up
    Exploration by seva
    Street Orientation by nestoralvaro

    And let’s not forget about our other exceptional contributors. Each and every one of these participants is is pushing the web forward and deserves a great deal of praise as a result.

    Want to see your name here next month? We are now accepting demos related to CSS 3D Transforms (March), HTML5 audio (April), and Websockets (May). Get an early start by submitting today!

  3. Developing a simple HTML5 space shooter

    Experimenting with modern web technologies is always fun. For my latest project, I came up with the following requirements:

    • Not a complex game, rather a proof-of-concept
    • Space shooter theme
    • Canvas-based rendering, but no WebGL
    • Re-use of existing sprites (I am no artist)
    • Rudimentary audio support
    • AI/Bots
    • Working network multiplayer

    I worked on this project only in my spare time; after approx. two weeks, the work was done: Just Spaceships! This article describes some decisions and approaches I took during the development. If you are interested in the code, you can check the relevant Google Code project.

    Animation & timing

    There are two basic ways to maintain an animation: requestAnimationFrame and setTimeout/setInterval. What are their strengths and weaknesses?

    • requestAnimationFrame instructs the browser to execute a callback function when it is a good time (for animation). In most browsers this means 60fps, but other values are used as well (30fps on certain tablets). Deciding the correct timing is up to the browser; the developer has no control over it. When the page is in background (user switches to another tab), animation can be automatically slowed down or even completely stopped. This approach is well suited for fluent animation tasks.
    • setTimeout instructs the browser to execute your next (animation) step after a given time has passed; the browser will try to fulfill this request as precisely as possible. No slowdowns are performed when the page is in background, which means that this approach is well suited for physics simulation.

    To solve animation-related stuff, I created a HTML5 Animation Framework (HAF), which combines both approaches together. Two independent loops are used: one for simulation, the second one for rendering. Our objects (actors in HAF terminology) must implement two basic methods:

    /* simulation: this is called in a setTimeout-based loop */
    Ship.prototype.tick = function(dt) {
    	var oldPosition = this._position;
    	this._position += dt * this._velocity;
    	return (oldPosition != this._position);
    }
     
    /* animation: this is called in a requestAnimationFrame loop */
    Ship.prototype.draw = function(context) {
    	context.drawImage(this._image, this._position);
    }

    Note that the tick method returns a boolean value: it corresponds to the fact that a (visual) position of an object might (or might not) change during the simulation. HAF takes care of this – when it comes to rendering, it redraws only those actors that returned true in their tick method.

    Rendering

    Just Spaceships makes extensive use of sprites; pre-rendered images which are drawn to canvas using its drawImage method. I created a benchmarking page which you can try online; it turns out that using sprites is way faster than drawing stuff via beginPath or putImageData.

    Most sprites are animated: their source images contain all animation frames (such as in CSS sprites) and only one frame (rectangular part of the full source image) is drawn at a time. Therefore, the core drawing part for an animated sprite looks like this:

    Ship.prototype.draw = function(context) {
    	var fps = 10;          /* frames per second */
    	var totalFrames = 100; /* how many frames the whole animation has? */
    	var currentFrame = Math.floor(this._currentTime * fps) % totalFrames;
     
    	var size = 16; /* size of one sprite frame */
     
    	context.drawImage(
    		/* HTML &lt;img&gt; or another canvas */
    		this._image,
     
    		/* position and size within source sprite */
    		0, currentFrame * size, size, size,
     
    		/* position and size within target canvas */
    		this._x, this._y, size, size
    	);
    }

    By the way: the sprites for Just Spaceships! have been taken from Space Rangers 2, my favourite game.

    The golden rule of rendering is intuitive: redraw only those parts of the screen which actually changed. While it sounds pretty simple, following it might turn out to be rather challenging. In Just Spaceships, I took two different approaches for re-drawing sprites:

    • Ships, lasers and explosions use technique known as “dirty rectangles”; when an object changes (moves, animates, …), we redraw (clearRect + drawImage) only the area covered by its bounding box. Some deeper bounding box analysis must be performed, because bounding boxes of multiple objects can overlap; in this case, all overlapping objects must be redrawn.
    • Starfield background has its own layer (canvas), positioned below other objects. The full background image is first pre-rendered into a large (3000×3000px) hidden canvas; when the viewport changes, a subset of this large canvas is drawn into background’s layer.

    Sound

    Using HTML5 audio is a piece of cake – at least for desktop browsers. There were only two issues that needed to be taken care of:

    1. File format – the format war is far from being over; the most universal approach is to offer both MP3 and OGG versions.
    2. Performance issues on certain slower configurations when playing multiple sounds simultaneously. More particularly, my Linux box exhibited some slowdowns; it would be best to offer an option to turn the whole audio off (not implemented yet).

    At the end of the day, the audio code looks basically like this:

    /* detection */
    var supported = !!window.Audio &amp;&amp; !audio_disabled_for_performance_reasons;
     
    /* format */
    var format = new Audio().canPlayType("audio/ogg") ? "ogg" : "mp3";
     
    /* playback */
    if (supported) { new Audio(file + "." + format).play(); }

    Multiplayer & networking model

    Choosing a proper networking model is crucial for user experience. For a realtime game, I decided to go with a client-server architecture. Every client maintains a WebSocket connection to central server, which controls the game flow.

    In an ideal world, clients would send just keystrokes and the server would repeat them to other clients. Unfortunately, this is not possible (due to latency); to maintain consistency and synchronicity between players, it is necessary to run the full simulation at server and periodically notify clients about various physical attributes of ships and other entities. This approach is known as an authoritative server.

    Finally, clients cannot just wait for server packets to update their state; players need the game to work even between periodical server messages. This means that browsers run their version of the simulation as well – and correct their internal state by data sent by server. This is known as a client-side prediction. A sample implementation of these principles looks like this:

    /* physical simulation step - client-side prediction */
    Ship.prototype.tick = function(dt) {
    	/*
    		assume only these physical properties:
    			acceleration, velocity and position
    	*/
    	this._position += dt * this._velocity;
    	this._velocity += dt * this._acceleration;
    }
     
    /* "onmessage" event handler for a WebSocket data connection;
    	used to override our physical attributes by server-sent values */
    Ship.prototype.onMessage = function(e) {
    	var data = JSON.parse(e.data);
     
    	this._position = data.position;
    	this._velocity = data.velocity;
    	this._acceleration = data.acceleration;
    }

    You can find very useful reading about this at Glenn Fiedler’s site.

    Multiplayer & server

    Choosing a server-side solution was very easy: I decided to go with v8cgi, a multi-purpose server-side javascripting environment, based on V8. Not only it is older than Node, but (most importantly) it was created and maintained by myself ;-).

    The advantage of using server-side JavaScript is obvious: game’s server runs the identical code that is executed in browser. Even HAF works server-side; I just turned off its rendering loop and the simulation works as expected. This is a cool demonstration of client-server code sharing; something we will probably see more and more in the upcoming years.

    Modulus

    In order to make the game more interesting and challenging, I decided that the whole playing area should wrap around – think of the game universe as of a large toroidal surface. When a spaceship flies far to the left, it will appear from the right; the same holds for other directions as well. How do we implement this? Let’s have a look at a typical simulation time step:

    /* Variant #1 - no wrapping */
    Ship.prototype.tick = function(dt) {
    	this._position += dt * this._velocity;
    }

    To create an illusion of a wrapped surface, we need the ship to remain in a fixed area of a given size. A modulus operator comes to help:

    /* Variant #2 - wrapping using modulus operator */
    Ship.prototype.tick = function(dt) {
    	var universe_size = 3000; // some large constant number
    	this._position += (dt * this._velocity) % universe_size;
    }

    However, there is a glitch. To see it, we have to solve this (elementary school) formula:

    (-7) % 5 = ?

    JavaScript’s answer is -2; Python says 3. Who is the winner? The correctness of the result depends on the definition, but for my purpose, the positive value is certainly more useful. A simple trick was necessary to correct JavaScript’s behavior:

    /* Returned value is always &gt;= 0 &amp;&amp; &lt; n */
    Number.prototype.mod = function(n) {
    	return ((this % n) + n) % n;
    }
     
    /* Variant #3 - wrapping using custom modulus method */
    Ship.prototype.tick = function(dt) {
    	var universe_size = 3000; // some large constant number
    	this._position += (dt * this._velocity).mod(universe_size);
    }

    Lessons learned

    Here is a short summary of general tips & hints I gathered when developing JS games in general, but mostly during Just Spaceships development:

    • Know the language! It is very difficult to create anything without properly understanding the programming language.
    • Lack of art (sprites, music, sfx, …) should not stop you from developing. There are tons of resources for getting these assets; the need for original art is relevant only it later stages of the project.
    • Use the paper, Luke! You know what my favorite development tools are? A pen and a sheet of squared paper.
    • If you are not 100% sure about the whole game architecture, start with smaller (working) parts. Refactoring them later to form a larger project is natural, useful and easy.
    • Collect feedback as soon as possible – at the end of the day, it is the users’ opinion that matters the most.

    TODO

    As stated before, Just Spaceships is not a complete project. There is definitely room for improvements, most notably:

    • Optimize the network protocol by reducing the amount of data sent.
    • Offer more options to optimize canvas performance (decrease simulation FPS, turn off background, turn off audio, …).
    • Improve the AI by implementing different behavior models.

    Even with these unfinished issues, I think the game reached a playable state. We had quite a lot of fun testing its multiplayer component; I hope you will enjoy playing it!

     

  4. Mozilla at SXSW 2012

    Building on the momentum generated by Mozilla at Mobile World Congress last week, this week we’re rolling into Austin, Texas for South by Southwest. If you’re attending SXSW, please join us at events and sessions.

    Reminder: Daylight Savings Time starts on Sunday, March 11 at 2am. Clocks move forward one hour. Sunday sessions are earlier than you expect them to be.

    Events

    Mozilla is partnering with Samsung Mobile and Twitter to present FEED at Austin Museum of Art—Arthouse at the Jones Center, 700 Congress Avenue. Mozilla is sponsoring events Friday to Monday. Please join us on Saturday and Sunday nights for drinks and music on the rooftop deck. Or, if you’re looking for a quiet place during the day to have a conversation or recharge away from the crowds, please stop by, and see an installation using Collusion. Art hackers Beak Labs will also be creating a Popcorn.js installation live on site. The space is open from 10am to 6pm, and 9pm to 2am.

    We’re also participating in the Knight Foundation’s Media Innovation Fair at Brush Square Park on Saturday and sponsoring the Austin JavaScript riverboat cruise on Sunday evening.

    Sessions

    Look for these Mozillians appearing at SXSW sessions (Interactive Festival, unless noted):

    Day Time Who Title
    Saturday 9:30-10:30am Joe Stagner Brendan Eich The State of Browser Developer Tools
    11am-noon Gary Kovacs (CEO) SOPA/PIPA: Why the Open Internet Needs Us
    11am-noon David Bolter Accessible HTML5 Canvas? Really? How?
    3:30-4:30pm Tantek Çelik The Rise of the Indie Web
    5-6pm Brendan Eich Browser Wars V: The Angry Birds Era
    Sunday 11am-noon CDT David Baron Fast CSS: How Browsers Lay Out Web Pages
    12:30-1:30pm Elika Etemad, Boris Zbarsky CSS.next: Current Experiments, CSS4 and the Future
    12:30-1:30pm Brett Gaylor Does HTML5 Offer a Montage Moment for Web Cinema? (Film)
    3:30-4:30pm Dan Sinker Open Web, Open News: Reporters & Developers Remix
    Monday 9:30-10:30am Ben Moscowitz HTML5 for Film: Leading Edge or Bleeding Edge? (Film)

    SXSW is a long event, especially if you stay for the film and music festivals. Pace yourself, hydrate, and before you go to sleep, remember to plug in all the devices.

  5. Ask your HTML5 Browser Tools Questions for SXSW Panel.

    At this years “South by Southwest” (SXSW) Interactive event I’m joining Paul Irish from Google, Mike Taylor from Opera, Brandon Satron from Telerik and Javascript Developer and author Garann Means in a panel on “The State of Browser Developer Tools

    The group has a Google Moderator page where you can ask your questions in advance. Please do so.

    Not able to attend the panel at SXSW? No problem. I’ll post a collection of the questions and answer right here on Hacks sometime after the event.

  6. 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.

    Alternatives

    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.

  7. 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!