Feature Articles

Sort by:


  1. 1st ever MDN Hack Day in NYC

    stickers, swag, rockets!

    So what’s an MDN Hack Day, you ask?

    The intention is to host a day of talks, hacks and demos that first introduces the participants to Mozilla and our various open web projects, then invite attendees to shift into participant mode and start hacking. Another way I like to think of it is that we are enshrining the ‘hallway track’ from your favourite tech conference into its own space, giving people the chance to hang out, hack and exchange ideas without feeling guilty that they should be in a room watching a talk.

    We wanted to try this out, so last week(end) an epic number of Mozillians from the Developer Engagement and MDN Webdev teams converged on New York for an epic 2 days of meetings, strategy and demos in Brooklyn. On the third day we headed into Manhattan to stage the first-ever MDN Hack Day hosted at the excellent New Work City co-working space.


  2. Announcing Firefox Aurora 10

    We’re happy to announce the availability of Aurora 10.
    (Download and Test Aurora 10)

    In additional to the normal improvements that you’ve come to expect like performance, security and bug fixes, Aurora 10 focuses in HTML5 enhancements.

    New additions

    Developer Tools

    Aurora 10 also implements incremental enhancements like IndexedDB setVersion API changes. Ongoing detailed attention to evolving specifications help to keep Firefox at the front of the Web revolution. (Read more about IndexedDB on MDN.)


    • We now fire a “load” event on stylesheet linking when the sheet load finishes or “error” if the load fails.
    • We turn the POSTDATA prompt into an information page (when navigating in session history).
    • We only forward event attributes on body/frameset to the window if we also forward the corresponding on* property.
    • We no longer allow more than one call to when we allow popups.
    • We fixed a bug where a success callback never fired when a position update is triggered after getCurrentPosition().
    • We removed replaceWholeText().
    • We fixed an error with createPattern(zero-size canvas).
    • We now handle putImageData(nonfinite) correctly.
    • We now throw INVALID_STATE_ERR when dispatching uninitialized events.
    • We’ve made Document.documentURI readonly.
    • We fixed document.importNode to comply with optional argument omitted.

    Web workers

    • We now allow data URLs.
    • We implemented event.stopImmediatePropagation in workers.
    • We made XHR2 response/responseType work in Web Workers.


    • We implement the WebGL OES_standard_derivatives extension.
    • We implement minimal-capabilities WebGL mode.


    • The function caller property no longer skips over eval frames.
    • We fixed E4X syntax so that it is not accepted in ES5 strict mode.
    • weakmap.set no longer returns itself instead of undefined.
    • We implemented the battery API.

    Offline: IndexedDB enhancements

    • IndexedDB setVersion API changes
    • Added support for IDBObjectStore/IDBIndex.count
    • Various methods accept both keys and KeyRanges.
    • Added support for IDBCursor.advance.
    • Implemented deleteDatabase.
    • objectStoreNames are no longer updated on closed databases when another connection adds or removes object stores
    • IDBObjectStore.delete and IDBCursor.delete now return undefined.
    • No longer throws an error if there are unknown properties in the options objects to createObjectStore/createIndex.
    • We now the errorCode to “ABORT_ERR” for all pending requests when IDBTransaction.abort() is called.
    • Fixed the sort order for indexes.


    • We have updated the current rule for handling malformed media queries.
    • We now support the HTML5 <bdi> element and CSS property unicode-bidi: isolate.
    • The CSS3 implementation now supports unicode-bidi: plaintext.


    • Implemented Document.mozFullScreenEnabled.
    • Enabled the DOM full-screen API on desktop Firefox by default.
  3. CSS 3D transformations in Firefox Nightly

    When the first 3D transformations in CSS got support on Webkit browsers people got incredibly excited about them. Now that they have matured we also support 3D CSS in Firefox. To see it for yourself, check out one of the latest nightly builds.

    You can see them in action in this demo of a rotating HTML5 logo and the screencast below:

    This means now that we need your support in trying out CSS 3D examples in Firefox and add other extensions than -webkit- to your CSS 3D products and demos. To show that this is possible, we took the well-known webkit-only “poster circle” demo and made it work with Firefox nightly by adding the -moz- (and of course the other prefixes and one set of instructions without browser prefixes). Here is a slight excerpt:

    -webkit-transform-style: preserve-3d;
    -moz-transform-style: preserve-3d;
    -o-transform-style: preserve-3d;
    -ms-transform-style: preserve-3d;
    transform-style: preserve-3d;

    You can see this in action in the screencast below alongside Chrome and you try the demo out yourself. The slight jerkiness is actually my MacBook Air impersonating a starting jet every time I use ScreenFlow and not the browser.

    To celebrate the release and to show how CSS 3D can be applied as subtle effect, have a game of pairs using your favourite browsers (and a cat) :

    browser pairs

    Oleg Romashin also spent some time to convert a few CSS 3D demos to work with Mozilla and you can check the 3D city for more “wow”.

    If you are new to CSS 3D transformations here’s a good beginner course and a tool to create them.

    The rotating HTML5 logo demo also shows how you can check if the currently used browser supports 3D transforms. Instead of repeating the animation frames for all the prefixes we test in JavaScript and create the CSS on the fly:

    function checksupport() {
      var props = ['perspectiveProperty', 'WebkitPerspective',
                   'MozPerspective', 'OPerspective', 'msPerspective'],
          i = 0,
          support = false;
      while (props[i]) {
        if (props[i] in {
          support = true;
          pfx = props[i].replace('Perspective','');
          pfx = pfx.toLowerCase();
      return support;
    if (checksupport()) {
      var s = '';
      styles = document.createElement('style');
      s += '#stage{-'+ pfx +'-perspective: 300px;}'+
           '#logo{-'+ pfx +'-transform-style: preserve-3d;position:relative;}'+  
           '#logo.spin{-'+ pfx +'-animation: spin 3s infinite linear;}'+
           '@-'+ pfx +'-keyframes spin {'+  
           '0% {'+ 
           '-'+ pfx +'-transform: rotateX(0deg) rotateY(0deg) rotateZ(0deg);'+   
           '100% {'+   
           '-'+ pfx +'-transform: rotateX(0deg) rotateY(360deg)'+
           ' rotateZ(360deg);'+ 
      styles.innerHTML = s;

    For more information on creating your own pages that use 3D transformations, take a look at the draft specification

    As always, If you find any bugs, please report them at!

    So please reward our hard work bringing the third dimension to Firefox’s CSS engine by supporting and testing. Cheers!

  4. Ben Adida on BrowserID and identity

    This is the second installment of Mission:Mozilla, a series of interviews that link Mozillians, the technology they produce and the Mozilla mission. Today Ben Adida is in the hot seat to discuss BrowserID, Mozilla’s identity initiative.

    Tristan Nitot – Hi Ben, can you briefly introduce yourself?

    Ben Adida – I’ve been hacking since high school and, since college, I’ve been fascinated with cryptography, security, and controlling my data. I built my first DB-backed web site before cookies. I ran my own IMAP mail server starting in 1997 because no one else was doing it the way I wanted it. I started an open-source web dev shop in 2000, went back to grad school in 2003 to work on secure voting, explored security and privacy of health data at Harvard Med for a few years, and joined Mozilla in March 2011. I’m now Tech Lead on Identity and User Data, and I’m having a blast.

    TN – Oh my… running your own IMAP server in 1997? That’s the kind of thing that gives instant nerd credibility ;-)

    BA – Oh yes, big nerd and proud of it!

    TN – So you’re now with Mozilla, focusing on Identity and User data. Can you update us on what’s Mozilla is doing on these fronts?

    BA – Everyone I talk to within Mozilla realizes that the Open Web depends on more than just the Firefox web browser. People are storing massive quantities of their personal data online, using dozens of services, and an open browser is not enough to ensure that they have true choice, true control, that they can shape the Web to their liking. So we need to be working towards providing user choice in web-based services, too. The first piece of the puzzle is a usable, federated, and distributed identity system. That’s what we’re doing with BrowserID.

    TN – “federated, distributed”, with users having control… Sounds like the original pillars of the Web, right? I mean, as opposed to what we tend to see these days, with identity being concentrated into the hands of very large commercial organizations… How do you plan to achieve this?

    BA – That’s right, distributed/federated *is* the way of the Web, but when you look at today’s identity solutions, most are incredibly centralized, and those that are more distributed in terms of protocol tend to become centralized in implementation because of the so-called NASCAR problem: you get to log in with Google or Yahoo, and if you’re *really* knowledgeable then maybe you can log in with your own Identity Provider. We think we can do better for users and developers in terms of ease of use and adoption.

    TN – And what about privacy?

    BA – We’ve specifically designed BrowserID to reduce the amount of private data that changes hands to the bare minimum required for authentication. For example, in every other web-based identity system today, the site you log into phones home to your identity provider. In the real world, the equivalent is: you check into a hotel, present your ID to confirm your name, and the receptionist calls the issuing government agency and says “Hi, this is the Hyatt San Francisco, Tristan is checking in just now, is that okay?” Why does the government agency or, in the case of a privately issued identifier, the commercial entity, need to know where and when you’re checking in? In the real world, the receptionist just checks the seal on the ID without phoning anyone. BrowserID recreates this more restrained, more privacy-protecting data flow for web logins.

    TN – So how do you manage to get the best of both worlds: user experience and user control?

    BA – First we’re making the browser an important part of the protocol. After all, the browser is the User’s Agent. Isn’t it a little bit silly on today’s Web that you typically have a tab open to your gmail, and then another site asks you to log in with Google or Yahoo? Why can’t the browser help coordinate those two tabs? You’re logged into gmail, of course you have a gmail email address you can use to authenticate! And in the enterprise setting, you’re logged into your company webmail, of course you can authenticate using that enterprise identity! The browser can help reduce user complexity significantly.

    TN – But I could want to use another email address, than the one I use for my Webmail…

    BA – Right, so we’re always going to give users a choice. Users can choose exactly which persona they want to present. And one major BrowserID design point is simply that users understand email addresses as personas. They typically have home and work email addresses, and they don’t use them the same way. If they have a moonlighting job, they often have a separate email address for that. So BrowserID is based on this concept users already understand: logging in is simply delivering an email address to a web site in a way that the web site can easily verify.

    TN – Cool. Say I’m a Web developer that wants to use BrowserID on my site. How hard is that? How much do I have to relinquish control of my users to Mozilla?

    BA – It takes about 5 lines of JavaScript and 10 lines of backend code to integrate BrowserID, and it works today. It’s by far the easiest of the available identity solutions. In the short term, it means you’re relying on Mozilla servers to provide the BrowserID interface and verify users’ email addresses. That said, this is only temporary scaffolding for our distributed system.

    TN – But as BrowserID becomes native in browsers and identity providers appear, this will change?

    BA – We’ve taken great care to design the system so that, as browsers begin to support the BrowserID APIs natively, we can remove our scaffolding and leave standing a truly distributed protocol. Best of all, web sites don’t have to change a line of code for that to happen: as the identity providers and browsers start supporting BrowserID, our scaffolding automatically fades away. And let’s say you’re a web developer and you want to stop using BrowserID for whatever reason: just send your users an email with their new password, and you’re done. No other identity system minimizes lock-in this much, for both users and web developers.

    TN – So minimizing lock-in is part of the BrowserID design goals?

    BA – Absolutely! This is part of our mission and manifesto. We don’t want to own users, we want to empower them. Mozilla is in a unique position to build this kind of identity system because, as we all like to say, Mozilla answers only to users, and we can leverage Firefox to deploy these pro-user designs.

    TN – Fantastic! What would you recommend to Websites who want to do a test-run on their site? And for users who want to experience BrowserID right away?

    BA – Web developers can check out our documentation. Users can check out, a very promising distributed photo storage system shepherded by WebFWD that chose BrowserID. Just click the distinctive BrowserID login button to get a taste of the user experience.

    TN – I’m sure our readers will try it right away! Thanks a lot Ben for your time. Long live BrowserID!

  5. Lights, Camera, Action! July Dev Derby is all about HTML5 Video!

    Show off your coolest video hack in July’s Mozilla Dev Derby!

    Moving pictures have always fascinated people. From the first zoetropes to the multi million dollar blockbusters of today – seeing things move grabs our attention as humans much better than any clever copy or imagery could. Video was alien to the web for a long time. Well, not alien, but we needed plugins to make them play. With newer browsers and HTML5, we now have the <video> element to natively embed video in a web page. This allows us to, amongst other things:

    • Style video elements with CSS and SVG
    • Make the video interact with other elements of the document and vice versa
    • Use Canvas to grab frames from videos and manipulate them
    • Create accessible video as the controls can be used with a keyboard without us having to write that functionality

    Using this arsenal, you can do pretty cool things. You can:

    ..and many more things.

    Now it is your turn to show us what you can do with HTML5 video! We don’t expect you to build another Wilderness Downtown or 3 Dreams of Black, but we are very excited to offer you the chance to shine in July’s Mozilla Dev Derby.

    Why not use CSS3 and Canvas to redesign the Outer Limits intro? Why not make the video do the things Diana Ross talks about in Upside down? Why not build a video cropping tool in Canvas? How about you have a crack at making closed captioning and subtitling work with HTML5 video? There are many ideas floating about – it just needs a bit of drive and a text editor to go for it. So, show us what you can do!

    There are a lot of tools out there to make your life easier with HTML5 video. makes it easy to convert videos, Popcorn.js is a library to sync page content and video and there are many tutorials on video available.

    To get you into the mood and see some examples in action, we are running an HTML5 video webinar on the 14th of July and you can ask some questions you have upfront using Google Moderator.

    Bring the web screen alive, I dare you! I am off to watch Cinema Paradiso again.

  6. Firefox 4 Demos: Awesome CSS3 Planetarium

    O hai pixel lovers! Check out this gorgeous CSS3 demo: Planetarium, by the LittleWorkshop team (@glecollinet & @whatthefranck).



    Youtube link.

    Gorgeous Animations

    The principal feature show-cased in this demo is CSS3 Transitions. The animation between the welcome-screen and the planet-screen, and the animation between the different planets are powered by transitions. But there are many little effects in this demo. Take a look at the Twitter button, the ruler, the credit page or the back button. These effects are CSS3 Transitions too.

    Another interesting detail. Next to the planet, you have some different animations. The way the animations is played depends on if you’re coming from the left, the right or from the home screen.

    Try it yourself: Click on the planet Earth, from the home screen. See the text “falling” from the top? Now, go to Mars, and come back to Earth. Now the text is “flying” from the right. Designers will love that :)

    Beautiful fonts

    @font-face allows you to use your own font for creative design. Combined with text-shadow and font-feature-settings, you can accurately forge and style your typographic content.

    Your turn!

    These are features you can use today.
    This demo works perfectly in Firefox 4, Safari and Chrome. Also, Transitions and font-face are easily degradable. Go. Check out the source code, read the documention, and if you’re proud of your code, feel free to submit a demo!

  7. Firefox 4 Beta 2 is here – Welcome CSS3 transitions

    As we have explained before, Mozilla is now making more frequent updates to our beta program. So here it is, Firefox Beta 2 has just been released, 3 weeks after Beta 1.

    Firefox 4 Beta 1 already brought a large amount of new features (see the Beta 1 feature list). So what’s new for web developers in this beta?

    Performance & CSS3 Transitions

    The two major features for web developers with this release are Performance improvements and CSS3 Transitions on CSS3 Transforms.

    This video is hosted by Youtube and uses the HTML5 video tag if you have enabled it (see here). Youtube video here.

    Performance: In this new Beta, Firefox comes with a new page building mechanism: Retained Layers. This mechanism provides noticeable faster speed for web pages with dynamic content, and scrolling is much smoother. Also, we’re still experimenting with hardware acceleration: using the GPU to render and build some parts of the web page.

    CSS3 Transitions on transforms: The major change for web developers is probably CSS3 Transitions on CSS3 Transformations.

    CSS3 Transitions provide a way to animate changes to CSS properties, instead of having the changes take effect instantly. See the documentation for details.

    This feature was available in Firefox 4 Beta 1, but in this new Beta, you can use Transitions on Transformation.

    A CSS3 Transformation allows you to define a Transformation (scale, translate, skew) on any HTML element. And you can animate this transformation with the transitions.

    See this box? Move your mouse over it, and its position transform: rotate(5deg); will transform transform: rotate(350deg) scale(1.4) rotate(-30deg); through a smooth animation.
    #victim {
      background-color: yellow;
      color: black;
      transition-duration: 1s;
      transform: rotate(10deg);
      /* Prefixes */
      -moz-transition-duration: 1s;
      -moz-transform: rotate(5deg);
      -webkit-transition-duration: 1s;
      -webkit-transform: rotate(10deg);
      -o-transition-duration: 1s;
      -o-transform: rotate(10deg);
    #victim:hover {
      background-color: red;
      color: white;
      transform:  rotate(350deg) scale(1.4) rotate(-30deg);
      /* Prefixes */
      -moz-transform:  rotate(350deg) scale(1.4) rotate(-30deg);
      -webkit-transform:  rotate(350deg) scale(1.4) rotate(-30deg);
      -o-transform:  rotate(350deg) scale(1.4) rotate(-30deg);

    CSS 3 Transitions are supported by Webkit-based browsers (Safari and Chrome), Opera and now Firefox as well. Degradation (if not supported) is graceful (no animation, but the style is still applied). Therefore, you can start using it right away.


    I’ve written a couple of demos to show both CSS3 Transitions on Transforms and hardware acceleration (See the video above for screencasts).

    This demo shows 5 videos. The videos are Black&White in the thumbnails (using a SVG Filter) and colorful when real size (click on them). The “whirly” effect is done with CSS Transitions. Move you mouse over the video, you’ll see a question mark (?) button. Click on it to have the details about the video and to see another SVG Filter applied (feGaussianBlur).
    This page shows 2 videos. The top left video is a round video (thanks to SVG clip-path) with SVG controls. The main video is clickable (magnifies the video). The text on top of the video is clickable as well, to send it to the background using CSS Transitions.
    This page is a simple list of images, video and canvas elements. Clicking on an element will apply a CSS Transform to the page itself with a transition. White elements are clickable (play video or bring a WebGL object). I encourage you to use a hardware accelerated and a WebGL capable browser. For Firefox on Windows, you should enable Direct2D.


    Creative Commons videos:

    The multicolor cloud effect (MIT License)

  8. Firefox 4: -moz-any() selector grouping

    This is a re-post from David Baron’s blog. This feature has landed in Mozilla Central (trunk) and only available with a Firefox Nightly Build for the time being.

    Last night I landed support for :-moz-any() selector grouping. This allows providing alternatives between combinators, rather than having to repeat the entire selector for once piece that’s different. For example, it allowed replacing this rule in our user-agent style sheet:

    /* 3 deep (or more) unordered lists use a square */
    ol ol ul,     ol ul ul,     ol menu ul,     ol dir ul,
    ol ol menu,   ol ul menu,   ol menu menu,   ol dir menu,
    ol ol dir,    ol ul dir,    ol menu dir,    ol dir dir,
    ul ol ul,     ul ul ul,     ul menu ul,     ul dir ul,
    ul ol menu,   ul ul menu,   ul menu menu,   ul dir menu,
    ul ol dir,    ul ul dir,    ul menu dir,    ul dir dir,
    menu ol ul,   menu ul ul,   menu menu ul,   menu dir ul,
    menu ol menu, menu ul menu, menu menu menu, menu dir menu,
    menu ol dir,  menu ul dir,  menu menu dir,  menu dir dir,
    dir ol ul,    dir ul ul,    dir menu ul,    dir dir ul,
    dir ol menu,  dir ul menu,  dir menu menu,  dir dir menu,
    dir ol dir,   dir ul dir,   dir menu dir,   dir dir dir {
      list-style-type: square;

    with this one:

    /* 3 deep (or more) unordered lists use a square */
    :-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) ul,
    :-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) menu,
    :-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) dir {
      list-style-type: square;

    In theory, I could even have used:

    /* 3 deep (or more) unordered lists use a square */
    :-moz-any(ol, ul, menu, dir) :-moz-any(ol, ul, menu, dir) :-moz-any(ul, menu, dir) {
      list-style-type: square;

    but this would have been slower since it no longer falls into the tag bucket. (If :-moz-any() turns out to be popular, we could add extra code so it’s just as fast, but I haven’t done so yet.)

    :-moz-any() is allowed to contain selectors with multiple simple selectors (using the css3-selectors definition of simple selectors, not the CSS 2.1 definition), but it is not allowed to contain combinators or pseudo-elements. So you can write :-moz-any(, p.error, div#topnotice) or :-moz-any(:link, :visited).external:-moz-any(:active, :focus), but you can’t put “div p” or “div > p or “:first-letter” inside :-moz-any().

    This has a -moz- prefix for two reasons. First, it’s just a proposal, and hasn’t made its way into any specification. And second, it isn’t quite ready for prime-time, though, since it doesn’t yet handle specificity correctly.

    Note: This will be extremely valuable in an HTML5 context when it comes to sections and headings. Since section, article, aside, and nav can be nested, doing something like styling all h1 elements at different depths could be extremely complex.

    /* Level 0 */
    h1 {
      font-size: 30px;
    /* Level 1 */
    section h1, article h1, aside h1, nav h1 {
      font-size: 25px;
    /* Level 2 */
    section section h1, section article h1, section aside h1, section nav h1,
    article section h1, article article h1, article aside h1, article nav h1,
    aside section h1, aside article h1, aside aside h1, aside nav h1,
    nav section h1, nav article h1, nav aside h1, nav nav h1, {
      font-size: 20px;
    /* Level 3 */
    /* ... don't even think about it*/

    With -moz-any():

    /* Level 0 */
    h1 {
      font-size: 30px;
    /* Level 1 */
    -moz-any(section, article, aside, nav) h1 {
      font-size: 25px;
    /* Level 2 */
    -moz-any(section, article, aside, nav)
    -moz-any(section, article, aside, nav) h1 {
      font-size: 20px;
    /* Level 3 */
    -moz-any(section, article, aside, nav)
    -moz-any(section, article, aside, nav)
    -moz-any(section, article, aside, nav) h1 {
      font-size: 15px;
  9. WebSockets in Firefox

    Here’s the pitch for WebSockets: a low-complexity, low-latency, bi-directional communication system that has a pretty simple API for web developers. Let’s break that down, and then talk about if and when we’re going to include it in Firefox:


    The WebSocket protocol, which is started via an HTTP-like handshake, has a relatively simple model for sending text packets back and forth. The complexity of the protocol is quite low. There’s no multiplexing, no support for binary data, and once the data connection is set up, the actual transport is quite cheap.

    Note that there are people who feel – possibly correctly – that support for multiplexing and binary data should be added. That would obviously increase the complexity but in some cases might be worth the cost. But more on that later.

    Bi-directional Communication

    One of the key aspects of WebSocket is its support for simple bi-directional communication. Servers can easily send updates to clients and clients can send updates to servers. Many of the comet-style applications that people have built will be much simpler and faster with this model because the protocol and API support it directly.

    While allowing for bi-directional communication it also is bound by the HTTP same-origin model. That is, it’s doesn’t give the browser the ability to connect to any site on any port it wants to.

    So WebSocket is really TCP with the HTTP security model.


    This is actually the primary value in WebSockets. The key thing is that the cost of sending a small amount of data is also very small. It’s possible to do bi-directional communication today with comet-style applications, but small amounts of data often require a huge amount of overhead to do so.

    A second-hand story to give you a sense of scale: Google Wave, which tries to do real-time communication with keystrokes has a several-kilobyte overhead for just about every keystroke because of the TCP startup, teardown and HTTP message headers involved with what should be only a few bytes sent over the wire.

    I haven’t tried, but I’m going to guess that if you built Quake on top of HTTP comet that the interactive experience would be poor. So this is where WebSockets really shine.

    Simple API

    The actual API that a developer sees for WebSocket is relatively simple. You can send messages, you can get messages, you get events when sockets open, close or there’s an error. Additional complexity, which I’m sure others will develop, will happen in JavaScript and backend libraries.

    (While this might seem like punting on the issue of complexity, this is actually the model for success we’ve seen for other browser standards: build something relatively simple that others can experiment with. When we understand what’s slow or what’s preventing progress, iterate and improve.)

    When will it be in Firefox?

    We really really want to support WebSockets in the next version of Firefox. And a lot of other people want us to include support too.

    The first set of test patches, written by the wonderful Wellington Fernando de Macedo (one of our most excellent contributors!) was first submitted in April of 2009. Since then we’ve been iterating both on the patches themselves and following the spec as it’s changed.

    Unfortunately, the spec itself is still under revision. WebSockets did ship in Chrome with version 4 and I’m told by Chrome developers that it’s going to be included in Chrome 5, without changes. Unfortunately, the version that Google included in Chrome doesn’t reflect the current draft. The handshake for how to start a WebSocket connection has changed, largely to improve security on servers. There’s also a lot of ongoing discussion on the role of integrated compression, direct support for binary data (instead of encoding binary data as strings), whether or not the protocol should support multiplexing and a number of other issues.

    Since WebSocket isn’t used widely yet, and that Chrome has an uptake rate that’s similar to Firefox, the hope is that once a more recent draft makes it through the process that both Chrome and Firefox can include a more recent version at around the same time.

    So in short: we want to ship it because the promise of WebSockets is great, but we’ll have to see if it’s stable and safe enough to do so. Code isn’t the issue – we’ve had that for a while. It’s whether or not there’s consensus on if the protocol is “done enough” to ship it to a few hundred million people.