Recently, creative developers from around the world demonstrated just how powerful IndexedDB can be in the December Dev Derby. Please join us in congratulating the top three demos as chosen by our judges.

1st Place: eLibri by mar.castelluccio
2nd Place: FileSystemDB by mar.castelluccio
3rd Place: IndexedDB Editor by twolfson

Runners up:
Vurkout Buddy by wcheung
Locate It IndexedDB by nestoralvaro

Congratulations to our winners and to everyone who submitted to the December Dev Derby.

Do you want to see your name here next month? We are now accepting demos related to Touch Events (February), CSS 3D Transforms (March), and HTML5 audio (April). Get an early start by submitting today!

Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help!

JavaScript

• Details of the object model
• yield
• Inheritance and the prototype chain

SpiderMonkey

• JS_ExecuteRegExp
• JS_GetOwnPropertyDescriptor
• JS_FlattenString

Developing Mozilla

• Mozilla Development Strategies
• Layout debugger
• Profiling with Xperf

Extensions

• Working with windows in chrome code
• Bootstrapped extensions
• Adding the structure

XUL

• Writing efficient CSS for use in the Mozilla UI
• Creating a Windows Inno Setup installer for XULRunner applications
• Using the Editor from XUL

XPCOM

• xpcshell
• Using nsIDirectoryService
• Setting up the Gecko SDK

Interfaces

• nsIDOMFontFace
• nsIWebSocketListener
• nsIDragSession

Plugins

• Scripting plugins
• NPN_GetURL
• NPRegion

CSS

• transform
• box-orient
• word-spacing

SVG

• x2
• lighting-color
• SVGFontElement

HTML

• Drawing DOM objects into a canvas
• frameset
• Input.setSelectionRange

DOM

• Browser Detection and Cross Browser Support
• Using server-sent events
• HTMLCollection

Accessing the battery

First, it’s a matter of accessing the battery object:

var battery = navigator.mozBattery;

Properties

There are a few properties offered to detect the charging level of the battery in the device:

Battery level

Check the currenty battery level. Returns a value between 0 and 1.

Battery charging

A boolean, returning if the device/computer is currently being charged.

Battery chargingTime

Time left in seconds until it is fully charged. Available when charging.

Battery dischargingTime

Time left in seconds until it is discharged. Available when not charging.

// Get battery level in percentage
var batteryLevel = battery.level * 100 + "%";

// Time until the device is discharged
var batteryDischarged = battery.dischargingTime;


Events

There are four events available for detecting changes to the battery’s status:

levelchange

If the battery level changes.

chargingchange

Detect if the device went from being charged to unplugged, or vice versa.

chargingtimechange

When the device’s charging time changes (when plugged in)

dischargingtimechange

When the device’s discharging time changed (when unplugged)

battery.addEventLister("levelchange", function () {
    // Device's battery level changed
}, false);

battery.addEventListener("chargingchange", function () {
    // Device got plugged in to power, or unplugged
}, false);

battery.addEventListener("chargingtimechange", function () {
    // Device's charging time changed
}, false);

battery.addEventListener("dischargingtimechange", function () {
    // Device's discharging time changed
}, false);

Device support

Battery API is supported in Firefox Beta on:

• Android (Firefox Aurora only, for now)
• Windows
• Linux (for those distros that have UPower installed – bundled with most nowadays)

Right now we don’t have anyone working on the Mac OS X implemementation, so if you have the skills, we’d love to see you contribute!

Demo and code

I’ve put together a basic demo of the Battery API and code is also available in the Battery API repository on GitHub.

If you don’t experience the expected results on your device, please file a bug and we can look into it. This feature is experimental at this time, and may not be ready for production use just yet.

Tristan – Hi Tantek, could you introduce yourself? (I could point our reader to your Wikipedia page, but it seems a bit out of date).

Tantek – I’ve been passionate about web standards since being inspired at the level of collaboration among different companies, cultures, individuals at my first W3C CSS&PF WG meeting May 1998 in Paris. My interest in standards as building blocks started much earlier with many childhood hours spent building things with LEGOs.

Tristan – Ah, LEGOs! I have fond memories of them, particularly LEGO technic! They’ve inspired so many geeks that they somehow should be credited for their work in W3C specs, don’t you think? ;-)

Tantek – Indeed I think LEGOs have inspired many an engineer. Simple pieces that could be combined in numerous ways and built into amazing unique and creative structures.

Tristan – Sounds like a good description of Web technologies to me! Who was your employer back then?

Tantek – I was working for Microsoft at the time, having joined the Macintosh Internet Products Group in 1997. I started work on Macintosh Internet Explorer (MacIE) in mid 1997 with mostly bug fixes and improvements in CSS support which incrementally made their way into MacIE 4. It was soon clear though that we needed a fairly big overhaul to implement better CSS support. Soon after I joined standards discussions in the W3C.

Tristan – It’s a little known fact, but IE Mac was really raising the bar when it came to CSS compliance. It was a time where few people cared about Web standards. I was at Netscape back then, and you at Microsoft. It was amazing to see a team trying to push Web standards on the other side of the fence!

Tantek – When I was made the developer lead for the MacIE rendering engine, it wasn’t immediately obvious to me what we should focus on, so I decided to interview web design firms in San Francisco and just ask: “Hi I’m with the Microsoft MacIE team. What would you like to see in terms of standards / rendering support in the next version of MacIE?” The answers were loud and clear: dependable standards support! In particular: reliable and ideally complete CSS support, “XML support” (whatever that meant), and better Javascript/DOM support. A few specifically asked for PNG support. Those interviews drove the priorities of what became Tasman, the new rendering engine for MacIE5 which itself in the process got renamed to Internet Explorer 5 for Macintosh (IE5/Mac). Little did I know at the time that such a focus on getting web standards right would come as a surprise to others.

Tristan – And now, a few years down the road, we’ve seen how Web standards have made the Web what it is today, but they’re also something that Web browser vendors are heavily investing on! What do you do for Mozilla today? Why should Web developers care?

Tantek – I joined Mozilla in May 2010 as Web Standards Lead and I’m excited to be working with so many people passionate about standards. In an organization with numerous talented web standards contributors, in addition to editing/iterating specifications, my role is often more of coordination and collaboration, making sure that folks who care about particular standards find each other and work together. One key thing I’ve created and driven in Mozilla is the open documentation of our standards participation, in a public place where not only we (Mozillians) can find each other, but web developers in general can see how much effort Mozilla and individual Mozillians put into web standards.

Tristan – I have the impression that Mozilla does not get the share of credit we deserve when it comes to our work on standards. Don’t you agree?

Tantek – As someone who’s been involved with web standards for over a decade, I’ve had a deep respect for Mozilla’s involvement with web standards for quite some time. However I do think that recognition can easily be forgotten outside of standards circles. I think the web community as a whole greatly underestimates the longevity, depth, and dedication of Mozilla’s contributions to web standards.

Tristan – Where do you think Mozilla particularly shines?

Tantek – One thing that’s always impressed me about Mozilla’s commitment to web standards is the level of quality and thoroughness that Mozilla places into implementations. In my experience, historically Firefox has had the highest fidelity handling of various CSS properties for example, focusing more on getting things precisely right rather than shipping quick implementations that may only cover common or 80% cases.

Second, Mozilla works far more in the open, early and often, than any other organization. For example, we do nearly all our project work on open wiki pages on wiki.mozilla.org. I even keep my own Mozilla projects list on an open Mozilla wiki page. It makes it really easy to answer when people ask me what am I working on these days.

Tristan – I agree with you. I sense that Mozilla tends to do the right thing, rather than the thing that makes us look good. Can you give an example why do Web standards matter?

Tantek – The browser compatibility tax. When the Web Standards Project started in 1998, they raised the real and painful issue of the “browser compatibility tax” that developers had to pay when developing web sites. No matter what standard a web author would use, they’d have to spend potentially 50-75% of their time purely on making their code work in multiple browsers, sometimes having to write multiple versions of their markup and style sheets and then use fragile user-agent string tests to serve different content (a bad habit that still persists to this day). Much of this was due to the abysmal standards support in 1990s browsers.

Web standards are an agreement between authors and browsers: if the author writes valid code (whether HTML, CSS, or JS), the browsers agree to render and execute it predictably and according to the standards. Without standards, web authors end up wasting their time coding for one browser at a time (typically focusing on whatever is the popular browser that year), and browsers developers end up wasting their time writing code fixing one site at a time.

Tristan – And if we want the Web to be the platform of choice for all kind of developers and all kinds of applications, from desktop to mobile, we need to remove this “browser compatibility tax”.

Tantek – Yes. It’s up to all of us as browser implementers to provide strictly correct implementations of web standards for authors to use, and for implementers to openly propose and test innovations in web standards.

Tristan – what’s your biggest concern about Web standards?

Tantek – My biggest concern about web standards can be summed up in four words: “Best Viewed In [...]“ where the fourth word can be filled in with a different browser nearly every year. Anything that encourages web authors to focus on a single browser (or browser engine) to the expense of other browsers hurts the web. It’s also short-sighted – next year all the browsers will change and what was “best” last year is not the same this year, even newer versions of the same browser!

Worst of all is when browser vendors themselves either encourage or outright publish “best viewed in” content themselves, thus setting a bad example for web authors.

Judge for yourself – whenever you see a site purporting to show-off or demonstrate web standards, if the site ever gives you an excuse like “Please use browser X to view this” then they’re misbehaving. Standards demonstrations should simply state the standards they require, and then link to test suites (developed in standards bodies) for you to check your own browser.

And “Best Viewed In” is just one of several concerns.

There are many difficult challenges to open web standards that we must acknowledge and continue fighting hard to overcome. Challenges like patents that may hurt Touch Events, devices that only effectively support a single browser engine, and when one or a small number of companies decide to dictate de-facto standards through “delayed open” tactics.

Tristan – What’s the most exciting thing going on in the world of Web standards these days?

Tantek – So many things to choose from! I think the most exciting thing about web standards these days is the unprecedented level of intense interest and collaboration across numerous companies on the open web platform built on web standards. There’s a rising culture of placing importance on the open web, and I think we have Mozilla to thank for keeping that flame alive for so long and setting an ever higher bar for how to best work openly on open web standards.

The Mozilla Manifesto provides an excellent set of principles for how to do so. I think what’s particularly important is to keep evolving openness, and Mozilla encourages community members to contribute their own views on how and why to work openly. Here is some more on the subject:

• http://paulrouget.com/e/openness/
• http://tantek.com/2010/281/b1/what-is-the-open-web
• http://tantek.com/2011/168/b1/practices-good-open-web-standards-development

Tristan – Thank you very much for your time Tantek, and keep up the good (and open) work!

This past weekend I have been in Brussels at FOSDEM, and absolutely massive free event for the open source software community. I hear there were over 5,000 people there this weekend, that’s a lot of people.

Mozilla had a great presence there this year and hosted two full days of talks in the Mozilla DevRoom.

The Developer Engagement team also had a presence this weekend and put on a variety of talks ranging from hacking the Web with Jetpack, to Mozilla’s new perspectives for 2012, to creating open Web documentation.

All in all, FOSDEM is a pretty awesome event absolutely crammed full of developers who care immensely about open software. It is very much a Linux-fest but the talks on Web technologies seemed to go down well. And aside from a few cases of anti-Apple/Microsoft/HTML5 sentiment the event was very successful and well-behaved.

Open Web Apps and the Mozilla Labs Apps project

The first talk that I had the opportunity to give at FOSDEM was on open Web apps and the Mozilla Labs Apps project. It’s a very interesting topic that has been encouraging developers to think beyond the concept of Web apps being something that is just in the browser.

Open Web Games with HTML5 & JavaScript

The second talk that I gave was on open Web game development with HTML5 & JavaScript. During this talk I highlighted a selection of recent events within the HTML5 game industry as well as the key technologies that are involved. I also demoed the Gamepad API working in Firefox with a wireless xBox 360 controller.

Highlights

A few of the improvements that stand out a little more:

ECMAScript Harmony’s Simple Map and Set builtins

For testing purposes, we have implemented ECMAScript Harmony’s Simple Map and Set builtins. This is only in Aurora and will be disabled when it goes to beta, so plase test it out now and give feedback! There is also MDN documentation on Set and MDN documentation on Map if you want to learn more.

If you are more interested in Harmony progress, read up on our implementation work for ECMAScript 6

Support multitouch on Android

We’re happy to now have implemented multitouch for Firefox on Android!

Let authors put line breaks (newlines) in tooltips (title attribute)

It might seem like a small thing, but have been discussed quite some time. You can now use newlines for tooltips!

XMLHttpRequest should allow to specify a network timeout in ms (for async requests)

Instead of timeouts and similar, this offers a way to speficy a network timeout for XMLHttpRequests using the timeout attribute.

List of improvements

Here are all the improvements we’ve made complete with links to each bug listing for those who want to read up more on respective implementation.

DOM

• When JavaScript is disabled, alternate content provided within the canvas element is not rendered and the canvas element still is rendered
• Support multitouch on Android
• Implement text/html for @mozilla.org/xmlextras/domparser
• Implement DOMError as defined in DOM 4
• Let authors put line breaks (newlines) in tooltips (title attribute)

JavaScript

• Implement Harmony simple Map and Set builtins
• Implement ArrayBuffer.slice
• Removed support for sharp variables

Layout

• There is no Bidi/Joining algorithm on Arabic/Persian texts in MathML
• Implement border-image revisions in latest css3-background
• Implement column-fill property of CSS3 spec
• remove handling of percentages as intrinsic widths/heights (SVG height=”100%” width=”100%” defaults)
• getBoundingClientRect needs to take transforms into account
• Adjust MathML text integration point treatment to comply with spec changes
• Remove a pop loop from <rp> and <rt> handling, because the loop has been removed from the spec long ago
• (munderover-align) [MathML3] munder, mover, munderover: add support for the align attribute
• Implement CSS3 text-align-last
• Add a ‘length’ property to DOMSVGStringList
• SVGTests interface is not implemented

Media

• Implement crossOrigin attribute for <video> element (for webgl)

Network

• Return correct websocket close code when browser navigates away from page
• Allow XHR to data URL
• XMLHttpRequest should allow to specify a network timeout in ms (for async requests)

Tools

• Log messages to console explaining media load algorithm failure

Developer Tools

There has been a total of 89 improvements to Web Console, Scratchpad, Style Editor, Page Inspector, Style Inspector, HTML view and Page Inspector 3D view (Tilt). Here are the highlights:

• Errors and messages that were logged before the Web Console was opened are displayed when the console is opened up to a queue size limit
• Scratchpad now includes Find and uses the standard platform key binding (ctrl-F/cmd-F)
• Scratchpad now includes Jump to Line and uses the standard platform key binding ctrl/cmd-J
• Style Editor now includes transitions
• Style Editor adds in a closing brace for new rules to avoid disrupting the rest of the CSS
• You can now remove nodes from the Page Inspector 3D view by pressing ‘x’. This makes it easier to visually select the node you want.
• Normal close window keybinding works for Style Editor
• Page Inspector highlighter now updates its position as the page changes

The most important goal of SPDY is to transport web content using fewer TCP connections. It does this by multiplexing large numbers of transactions onto one TLS connection. This has much better latency properties than native HTTP/1. When using SPDY a web request practically never has to wait in the browser due to connection limits being exhausted (e.g. the limit of 6 parallel HTTP/1 connections to the same host name). The request is simply multiplexed onto an existing connection.

Many web pages are full of small icons and script references. The speed of those transfers is limited by network delay instead of bandwidth. SPDY ramps up the parallelism which in turn removes the serialized delays experienced by HTTP/1 and the end result is faster page load time. By using fewer connections, SPDY also saves the time and CPU needed to establish those connections.

The page-load waterfall diagram below tells the story well. Note the large number of object requests that all hit the network at the same time. All of their individual load times are comprised exclusively of network delay and by executing them in parallel the total page load time is reduced to a single round trip.

Generally speaking, web pages on high latency connections with high numbers of embedded objects will see the biggest benefit from SPDY. That’s great because its where the web should be going. High latency mobile is a bigger part of the Internet every day, and as the Internet spreads to parts of the world where it isn’t yet common you can count on the fact that the growth will be mobile driven. Designs with large numbers of objects are also proving to be a very popular paradigm. Facebook, G+, Twitter and any avatar driven forum are clear examples of this. Rather than relying on optimization hacks such as sprites and data urls that are hard to develop and harder to maintain we can let the transport protocol do its job better.

Beyond better page load time, there is good reason to think this approach is good for the web’s foundation. The way HTTP/1 uses large numbers of small and parallel active connections creates a giant networking congestion problem. This inhibits the deployment of real time applications like WebRTC, VOIP, and some highly interactive games. SPDY’s small number of busier connections fit the congestion control model of the Internet much better and enables the transport of classic web content to cooperate better with these real time applications. Web browsers have only managed to keep the congestion problem in check with HTTP/1 through arbitrary limits on its parallelism. With SPDY we can have our parallel-cake and eat it in low latency conditions too. This property is what I find most promising about SPDY, and I’ve written about it extensively in the past.

There is a great transition path onto SPDY. It is a new protocol, but it uses the old https:// protocol scheme in URIs. No changes to markup are needed to use SPDY. Generally SPDY servers support both SPDYand HTTP/1 for use with browsers that are not SPDY capable. The protocol used is silently negotiated through a TLS extension called Next Protocol Negotiation. The great news here is that upgrading to SPDY is just a matter of an administrative server upgrade. No changes to content are needed and things like REST APIs continue to work unmodified. Indeed, a SPDY site is not visually different in any way from an HTTP/1 site.

Google did a lot of work to launch this technology and to evolve it in the open, but it isn’t a Google only project any more. Since the implementations in Chrome and various Google web services were introduced we have seen either code or commitments regarding SPDY from many other products and groups including Amazon’s tablet, node.js, an Apache module, curl, nginx, and even a couple CDNs along with Mozilla. In my opinion, that kind of reaction is because engineers have looked at this and decided that it is solves several serious problems with HTTP’s connection handling and that this is a technology well positioned for us all to cooperate on. There is also discussion and preliminary movement in all the right standardization forums such as the W3C TAG and the IETF. Open standardization of the protocol is a key condition of Mozilla’s interest in it, but it is not a precondition to using it. Gathering operational experience instead of just engineering on whiteboards, is a valuable part of how the best protocols are made. The details of SPDY can be iterated based on that experience and the standardization process. The protocol is well suited to that evolution at this stage.

SPDY needs to be explicitly enabled through about:config in Firefox 11. Go to that URL and search for network.http.spdy.enabled and set it to true. Future revisions hope to have it enabled by default.

At the end of this blog post, you also have all the Developer Engagement team members and what they work on, if you are interested in discussing more, contributing or taking part of our work.

Weekly links

If there is anything you think we should read or know about, don’t hesitate to post a comment, contact us on Twitter or through any other means.
The picks this week are:

• Layout paint flashing in Firefox – Detect when a region of the web browser requires repainting.
• James Long shows just how simple it is to use a Wii controller and CSS transitions to change web sites in Firefox.
• The Case for Browser ID – A thoroughly clueful analysis supporting BrowserID as a pragmatic solution for identity on the Web, including key ingredients and current issues.
• Slide decks are little by little moving from dedicated Powerpoint-like applications to the web. Among the numerous slide engines around, impress.js is really visually appealing, but, beware!, you need a browser supporting CSS3 Transforms, both 2D and 3D, and Transitions (For Firefox, it is from Firefox 10 or later…)
• Comb looks like a nice toolbox of utilities for creating node.js applications, including helpers for logging, collections and flow control.
• Peter Lubbers HTML Offline Web Apps Presentation. HTML5 “Off line”" can be as tricky as it is powerful. Check out this great introduction!
• If you use Sublime Text 2 for programming then you’ll love this huge list of packages that extend the code editor in various ways.
• This article is not directly to Web development, but to something close to our hearts and even closer to our wallets: monetization. Everything for free, always: how Facebook ads show us the sad state of the Internet. In short, close to one billion people are willing to leave a large organization know everything about them in order to access a service that costs roughly 3 dollars a year. It says a lot about the monetization issue on the Web. Aiming to fix this, Mozilla’s working on Mozilla Labs Apps Preview, which could also become useful for games!
• 10 Usability Crimes You Really Shouldn’t Commit – A collection of ten simple but important usability tips for web developers young and old.

The Developer Engagement team

Mozilla’s Developer Engagement team work with writing articles, documentation – such as MDN (Mozilla Developer Network) – public speaking and generally helping and informing about open technologies and Mozilla products. If you are interested in following our work, here are the team members:

Infrastructure woes

We had a snafu for a few days last week when a server crashed in the middle of a move of the DOM reference hierarchy, causing many DOM reference pages to apparently disappear. That situation has now been fixed.

We have a recurring issue with the wiki software, where the syntax highlighting extension fails to load, causing an error message to appear in place of code examples. While we wait for a patch to be backported by the vendor, we have a script in place that detects this situation and corrects it. While you might still occasionally see those error messages, they should be less frequent and persistent than previously.

Web standards docs

• Eric Bidelman updated the Mouse Lock API.
• Luke Crouch added an Apache example to Server-side access control.
• fusionchess added a compatibility workaround for the JavaScript JSON global object.
• Has Hillen expanded the ARIA technique article on Using the dialog role.
• Burak Yigit Kaya added a JSFiddle example to HTML in XMLHttpRequest.
• Gijs Kruitbosch added a compatibility table to window.frameElement.
• Jeremie Patonnier updated DOMParser to cover parsing HTML fragments.
• Eric Shepherd documented the DOM console and related objects.
• yyss translated a number of pages into Japanese, related to JavaScript typed arrays, full-screen mode, WebGL, and writing forward-compatible websites.

Mozilla-specific docs

• Wolfgang Germund updated nsIZioReader and nsIZipReaderCache.
• Sam Hanes updated Document Loading – From Load Start to Finding a Handler. The diagram in this article still needs to be updated.
• Anthony Hughes documented Merging the ESR branch.
• Nickolay Ponomarev added a list of mouse gesture events to Gecko-specific DOM events.
• Colby Russell expanded DOM Inspector internals.
• Eric Shepherd beefed up the coverage of the Web console.
• Sid0 update the article on Windows SDK versions.

The final code is available on GitHub and you can see an online demo here. There is also a screencast available on YouTube:

Step 1: Getting the files into the browser

The first step to resize images in the browser is to somehow get them. For this, we can just add an element in the page and assign drag and drop event handlers to it:

s.addEventListener( 'dragover', function ( evt ) {
  evt.preventDefault();
}, false );
s.addEventListener( 'drop', getfiles, false );

Notice that we only prevent the default behaviour when we drag things over the element. This is to prevent the browser from just showing the images when we drag them in.

The getfiles() function then does the hard work of reading all the files in and sending them on to the functions that do the resizing and image generation:

function getfiles( ev ) {
  var files = ev.dataTransfer.files;
  if ( files.length > 0 ) {
    var i = files.length;
    while ( i-- ) {
      var file = files[ i ];
      if ( file.type.indexOf( 'image' ) === -1 ) { continue; }
      var reader = new FileReader();
      reader.readAsDataURL( file );
      reader.onload = function ( ev ) {
        var img = new Image();
        img.src = ev.target.result;
        img.onload = function() {
        imagetocanvas( this, thumbwidth, thumbheight, crop, background );
        };
      };
    }
  }
  ev.preventDefault();
};

The drop event gives us a property called dataTransfer which contains a list of all the files that have been dropped. We make sure that there was at least one file in the drop and then iterate over them.

If the file type was not an image (or in other words the type property of the file does not contain the string “image”) we don’t do anything with the file and continue the loop.

If the file is an image we instantiate a new FileReader and tell it to read the file as a Data URL. When the reader successfully loaded the file it fires its onload handler.

In this handler we create a new image and set its src attribute to the result of the file transfer. We then send this image to the imagetocanvas() function with the parameters to resize (in the demo these come from the form):

function imagetocanvas( img, thumbwidth, thumbheight, crop, background ) {
  c.width = thumbwidth;
  c.height = thumbheight;
  var dimensions = resize( img.width, img.height, thumbwidth, thumbheight );
  if ( crop ) {
    c.width = dimensions.w;
    c.height = dimensions.h;
    dimensions.x = 0;
    dimensions.y = 0;
  }
  if ( background !== 'transparent' ) {
    cx.fillStyle = background;
    cx.fillRect ( 0, 0, thumbwidth, thumbheight );
  }
  cx.drawImage( 
    img, dimensions.x, dimensions.y, dimensions.w, dimensions.h 
  );
  addtothumbslist( jpeg, quality );
};

This function gets the desired thumbnail size and resizes the canvas to these dimensions. This has the added benefit of wiping the canvas so that no old image data would be added to our thumbnail. We then resize the image to fit into the thumbnail using a resize() function. You can see for yourself what this one does in the source code, it just means the image gets resized to fit. The function returns an object with the width and the height of the new image and the x and y position where it should be positioned onto the canvas.

If we don’t want the full-size thumbnail but instead crop it we resize the canvas accordingly and reset x and y to 0.

If the user requested a background we fill the canvas with the colour. After that we put the image on the canvas with the x and y coordinates and the new width and height.

This takes care of creating a new thumbnail on the canvas, but we haven’t got it as an image in the document yet. To this end, we call addtothumbslist():

function addtothumbslist( jpeg, quality ) {
  var thumb = new Image(),
      url = jpeg ? c.toDataURL( 'image/jpeg' , quality ) : c.toDataURL();
  thumb.src = url;
  thumb.title = Math.round( url.length / 1000 * 100 ) / 100 + ' KB';
  o.appendChild( thumb );
};

This one creates a new image and checks if the users wanted a JPG or PNG image to be created. PNG images tend to be better quality but also bigger in file size. If a JPG was requested we call the canvas’ toDataURL() method with two parameters: the requested JPEG mime type and the quality of the image (ranging between 0 and 1 with 1 being best quality). If a PNG is wanted, we can just call toDataURL() without any parameters as this is the default.

We set the src of the image to the generated url string and add a title showing the size of the image in KB (rounded to two decimals). All that is left then is to add the thumb to the output element on the page.

That’s it, you can now drag and drop images into the browser to generate thumbnails. Right now, we can only save them one at a time (or if you have some download add-ons all at once). Would be fun to add Zip.js to the mix to offer them as a zip. I dare you! :)

More reading:

• Drag and Drop on MDN
• FileReader on MDN
• Canvas on MDN

I really wanted my demo to stand out from the crowd, so it had to possess a singular feature that would impress. Since my passion is game development, I decided to implement game controller support in whatever game I would build for the Derby. I built Bouncy to be a twin-stick shooter which would stand out as a demo for the Mozilla Gamepad API as well as Canvas.

Usually, I tend to stay away from violence in my games, so it was a bit difficult at first (a ‘shooter’ without any violence!)

Incidentally, it was the Mozilla mascots that inspired me to draw Bouncy (the spikes in the hair were directly from the brown dude with the hat!):

How did you get started coding and hacking?

Funnily enough, it started in Microsoft PowerPoint, where I realized I could ‘hyperlink’ from a slide to any other one. I then created a quiz game, not unlike the TV show ‘Who wants to be a Millionaire?.’ From that, I moved onto Visual Basic (in which I became Microsoft-Certified in 2008) C# and XNA, and eventually began learning JavaScript (after playing around with the Processing language).

What was your first computer?

I don’t really remember much about my first computer, except the fact it had a Pentium II, which was not powerful enough to run some of the new games I wanted to play.

What games do you play the most these days?

On the console, I prefer racing games like F1 2011 and Gran Turismo. On the PC, I like to play indie games like Super Crate Box and Jamestown. I also love Valve games like Portal.

Are you working on another demo or any other cool projects you want to share?

I’m currently participating in the Pokki 1UP game development competition, with a friend. We are building a 2D/3D arcade game called BLASTR:ARENA. It uses WebGL for 3D graphics and Canvas for the 2D fallback.

You mentioned that you recently graduated from high school? What’s next for you?

I have just enrolled in the Bachelor of Engineering (Software) course at the University of New South Wales. During my degree, I will also be developing games part-time, hopefully for a chance at breaking into the gamedev industry.

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

As my game clearly demonstrates, HTML5 and other web technologies provide the browser the ability to render other traditional applications obsolete, replacing them with a unified system which can serve as the basis for anything from games to word processors.

As I’m most interested in game development, the introduction of the Fullscreen and Gamepad APIs, as well as performance increases in WebGL and Canvas give the Web a greater chance of overthrowing consoles as an effective game platform.

Anybody else who helped you with Bouncy and the Apple whom you’d like to give a shout out to?

My aunt, who had come over for a holiday, was a fantastic source of inspiration and ideas, so it was a great feeling to finally play the finished game with her on the big screen. I’d also like to thank my parents for letting me stick to my plans, even if I skipped dinner and stayed up until 1AM on some nights. I’m also grateful to my brother for putting up with my endless repeating game music.

You mentioned that you’re a big fan of Mozilla’s work on the Open Web. Can you say something more about why you think that’s important?

I think Mozilla is a fantastic, one-of-a-kind organisation since it works and innovates solely with the well-being of the Web and its users in mind. With such an open and direct goal, it means everyone, from the users to the developers, benefit from the development of Mozilla products and technologies.
Also, Mozilla’s work on HTML, CSS, Javascript and other web technology is for the mutual benefit of all, fostering the advancement of the open Web as a mainstream platform of the present and future generations.

The question people asked was about the relation between Mozilla WebAPI and W3C DAP, what our stance on DAP is and if we were just creating another standards body. From the get go, we declared our commitment and intent to contribute to existing standards.

Mozilla has a long history working with W3C and continues to be a member in several W3C working groups. However, at the time we had concerns about some of the work happening in DAP. Since then, DAP has focused their efforts on technologies appropriate for implementation in web browsers and so we’ve have decided that it’s worth joining that working group. Our developers Jonas Sicking and Mounir Lamouri have now joined DAP to ease the collaboration and contribution.

What this means in practice is that we test and develop things, and when we feel that it is ready, or even suitable, to become a standard and continue to evolve, we submit it to W3C. Like most companies, we need to evaluate, examine and prototype different ideas all the time, but what might be different about us is that our process is open to the world to see, ask about and also contribute to.

Even before this, we have submitted the Battery API and the Vibration API to DAP, which are both pretty far along in standardization. We look forward to continue to do so with APIs as they get mature enough.

If you are interested in following or taking part of the work with our different APIs, feel more than welcome to follow any of these channels:

• WebAPI project page.
• The WebAPI mailing list.
• IRC: irc.mozilla.org in the #webapi room.

Please also ask any questions you might have in the comments here, and we’ll do our best to reply to them.

Remember when web sites gave you instructions how to configure your web browser with hiding toolbars and more, just to get a slightly better user experience? Or maybe it’s just me… :-)

Either way, some time ago we got fullscreen support in web browsers where the user could choose to view the current web site in fullscreen. That’s all good and well, but as an extension to that, as web developers we want to be able to trigger that. Either for the entire web site or just a specific element.

And now we can!

Requesting fullscreen

We now have access to a method called requestFullScreen, so far implemented in Firefox, Google Chrome and Safari. Therefore, to make it work at the moment, we need this code:

Please note that the Fullscreen standard in the W3C specification uses a lowercase ‘s’ in all methods, whereas Firefox, Google Chrome and Safari use an uppercase one.

What the code above does is just getting a reference to the documentElement and request for it to be displayed fullscreen. Naturally, you could also make just a certain element fullscreen, for instance, a video, with the same method called for the element you wish.

Cancelling fullscreen

If you want to cancel the fullscreen state, you need to call it on the document element:

Note here that W3C has decided to call it exitFullscreen, but in all existing web browser implementations it’s about cancelling the state.

Detecting fullscreen state change

The user could, for instance, exit fullscreen, something that might be good for you to know. For that we have a fullscreenchange event, that you can apply both to the element that requested fullscreen, but also to the document. Then we just detect the fullscreen state and take act accordingly, like this:

document.addEventListener("webkitfullscreenchange", function () {
fullscreenState.innerHTML = (document.webkitIsFullScreen)? "" : "not ";
}, false);

Styling fullscreen

In CSS, we get a number of pseudo-classes for styling fullscreen elements. The most reliable one is for full-screen and automatically gets triggered when the document/element is in fullscreen mode:

html:fullscreen {
background: red;
}

Notice here that the W3C approach doesn’t use a hyphen between the word ‘full’ and the word ‘screen’.

It should also be added that Firefox is the only web browser that applies a width and height of 100% to the element that is requesting fullscreen, since we believe that is the desired behavior. This can of course be overridden with the above CSS.

Full screen with key input

For security reasons, most keyboard inputs have been blocked in the fullscreen mode. However, in Google Chrome you can request keyboard support by calling the method with a flag:

docElm.webkitRequestFullScreen(Element.ALLOW_KEYBOARD_INPUT);

This does not work in Safari, and the method won’t be called.

With Firefox, we are discussing and looking into various ways of how we we could add keyboard input support without jeopardizing the end user’s security. One suggestion, that no one has implemented yet, is the requestFullscreenWithKeys method, which in turn would trigger certain notifications for the user.

Web browser support

This feature is currently available in Firefox beta, but it’s due to land in the official release of Firefox, version 10, tomorrow! It has also been available in Google Chrome since version 15 and Safari since 5.1.

Play with fullscreen!

I have a Fullscreen API demo available for you to play with, and all the code is available in the Fullscreen repository on GitHub.

• You leave any changes in the look and feel to the CSS
• You avoid having to loop lots of elements as you can allow CSS to do that job for you by assigning a class on a parent element
• You can trigger CSS transitions and avoid having to write your own animation
• And many more…

The issue with classes is that it is not too simple to work with because of their representation in the DOM. When you read out className you get one string and you need to split it and use regex to find if a class was used and all kind of other annoyances. This is also why it is a very common interview questions for web developers to write a function to deal with classes.

Well, you might not be aware of it, but HTML has a very cool new way to deal with classes called classList. This makes it dead easy to add, remove, toggle and check for classes on an element – natively in your browser. You can play with it at JSFiddle:

The methods you have are all you really need:

• element.classList.add('foo') adds the class foo to the element (if it already exists it does nothing)
• element.classList.remove('foo') removes the class foo from the element
• element.classList.toggle('foo') alternatively adds and removes the class foo from the element
• element.classList.contains('foo') returns if the class is applied to the element or not
• element.classList.toString() returns all the classes as a string (same as reading out className)

The browser support is very good with IE being the party pooper. However, there is a polyfill by Eli Grey available for you to use.

The idea with the Vibration API is to be able to give the user a notification, in a game or other use case, by telling the device to vibrate. It accesses the native vibrator and tells it how long it should vibrate.

Examples

The way to do this is quite simple – in this example the parameter is how long it should vibrate, i.e. the number of milliseconds:

navigator.mozVibrate(1000);

Another way of controlling vibration is giving a vibration pattern, switching between vibrating and being still. The odd parameters in the list is vibration time, the even ones are pauses:

navigator.mozVibrate([200, 100, 200, 100]);

And if you want to stop the vibration, you can simply call the mozVibrate method with an argument of 0 or an empty pattern, like this:

navigator.mozVibrate(0);
navigator.mozVibrate([]);

Try it out!

If you want to try this out right now, you can do so in Firefox Aurora, which is planned to become Firefox 11. Currently, it naturally only works on devices that support vibration, which means Firefox on (most) Android phones.

Note: a possbile caveat could be if you have haptic feedback turned on on your Android device, which then might cancel out the vibration.

Demo

I put together a little demo where you can see the code needed and test it in place. Please play around with this and let us know what you think!

Edit: Our temporary implementation name was Vibrator API, but since it gave the wrong impression, we now call it Vibration API – which is also more in line with the W3C Vibration API draft.

Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help!

JavaScript

Thanks to David Bruant, -TNO-, and xkizer for their contributions the last couple of weeks.

• Details of the object model
• JavaScript typed arrays
• Getting Started

SpiderMonkey

• JS_ExecuteRegExp
• JS_GetGCParameterForThread
• JS_CompileUCFunctionForPrincipalsVersion

Developing Mozilla

• Using preferences from application code
• Components.utils.makeObjectPropsNormal
• Mozilla DOM Hacking Guide

Extensions

• Windows
• Adding the structure
• Updating extensions for Firefox 7

XUL

• panel.type
• XUL Overlays
• Using the Editor from XUL

XPCOM

Thanks to Neil Rashbrook for his contributions!

• nsICRLManager
• Using XPCOM in JavaScript without leaking
• nsIDocumentLoader

Interfaces

• IAccessibleRelation
• nsIMsgWindow
• nsIChromeRegistry

Plugins

• Out of process plugins
• NPAnyCallbackStruct
• NPN_ReloadPlugins

CSS

Thanks to McGurk and cgack for their contributions to CSS documentation!

• unicode-bidi
• background-repeat
• -moz-user-modify

SVG

• dur
• SVGPatternElement
• SVGPolylineElement

HTML

Thanks to Jens.B and tw2113 for their contributions since last time.

• Historical artifacts to avoid
• meter
• bdo

DOM

Thanks to cgack for contributing!

• document.mozFullScreenEnabled
• CustomEvent
• Selection

Yes, we mostly had kids getting excited about what can be done with the web and its technologies and for this veteran of many a hack day this was an amazing experience.

The whole day was run as a series of “Popups” as defined by the Hive learning network, NYC. As explained in Mark Surman’s blog post the activities provided were:

• Using Hackasaurus to remix the web
• Creating simple programs with MIT’s Scratch
• Using the Paper-protyping-for-interface-design Firefox add on Domova (build by Keio University and Mozilla Japan)
• Print out a stencil and use colours to make your mark on a wall with Paint ⁿ
• Building your own platform game using the Canvas/HTML5 based Run Jump Build
• Creating your own animation using Mozilla Japan’s Para Para

All of which were a big success with the kids. I especially liked the idea of Para Para, which is why I quickly interviewed Brian Birtles of Mozilla Japan about it:

All in all the second day of the event was a surprise and it showed me that there is a lot of great things to come in the next generation of web makers.

It was very refreshing to see that with some guidance and a share of enthusiasm kids happily create and use the web as a read/write medium instead of just playing games and watching movies. It is up to us to make the web of tomorrow not TV on steroids.

We’re aware of the problem on MDN in which error messages appear in place of code examples (and a few other places). This is due to a bug in the wiki platform software that causes some of its extensions to fail to load when a server restarts. The problem has been diagnosed by the vendor, and we are awaiting a patch to fix it. Sorry for the inconvenience and thanks for your patience!

The year 2012 is off to a great start for the MDN documentation and its community. This past weekend, a bunch of community members gathered virtually for a documentation sprint to write, update, and translate docs. But already in the preceding weeks, a great deal of work had already been accomplished. This post is a recap of those efforts.

Doc sprint results

• Onur Avsar filled in lots of missing information in HTTP response codes, and improved <time> and <frame>.
• Michael Beckwith improved and updated the HTML5 & friends thematic classification, Common CSS questions, and Tips for authoring fast-loading HTML pages.
• Hans Hillen created pages for ARIA guides, ARIA techniques, ARIA technique template and the specific technique Using the alert role.
• Jeremie Patonnier improved SVG Content type and fill-rule and created pages for 7 SVG attributes.
• Rajeev Bharshetty added code examples for embedding audio in Using HTML5 audio and video, for SVG elements text, title, and g and SVG attributes class, script, r, cy, cx, and points.
• Fred Bourgeon restructured and improved CSS opacity and translated a bunch of CSS property pages into French.
• David Bruant did a major rewrite of Inheritance and the prototype chain in the JavaScript Guide, and wrote an article on HTTP cookies.
• Corey Gackenheimer added browser compatibility and an example to DeviceOrientationEvent, and moved some obsolete information from Detecting device orentation to MozOrientation.
• Trevor Hobson added the isURIVisited method to mozIAsyncHistory.
• Burak Yiğit Kaya cleaned up the pages for the instanceof operator, the bind function, window.setTimeout, and element.addEventListener.
• Filipus Klutiero clarified the difference between form.submit and a form submit button.
• Jeremie Patonnier created pages for 5 more SVG attributes and
  SVGCursorElement, and updated the SVG IRI content type.
• Jonathan Protzenko revamped the Thunderbird extensions page.
• Colby Russell wrote an article on DOM Inspector internals.
• Florian Scholz documented two more MathML elements (mlabeledtr and mglyph, created pages for the Battery API and CSS column-fill property, documented the muted and loop properties of HTMLMediaElement, and added Gecko-specific properties to HTMLVideoElement.
• Tom Schuster started a page for ECMAScript 6 in Mozilla and added window.crypto.getRandomValues.
• Marek Stępień created pages for document.head, DOMContentLoaded, and the JavaScript global object Set; documented browser variations in the return value of element.getElementsByTagName; updated several window.navigator properties to match the HTML5 spec and reality; and did a bunch of other clean-ups and updates.
• Andreas Wagner documented and wrote exmaple code for a demo add-on for Thunderbird, and created pages for nsIMsgAccount and nsIMsgIncomingServer.
• Patrick Wied created a page for SVG contentStyleType, added examples to HTMLSelectElement and SVG style attribute, and fixed up links in several pages for SVG-related DOM interfaces.
• Jonathan Wilsson added or updated browser compatibility for 3 HTML elements, 2 DOM elements, and 42 CSS properties and pseudo-classes. He also added content to :focus and :enabled.

Previous activity

Here are some of the significant changes in the weeks prior to the doc sprint.

Web standards docs

• Eric Bidelman added mobile browser compatibility info for document.querySelectorAll and document.querySelector.
• Fred Bourgeon continued what he started during Mercredi Doc by creating French translations for 9 CSS animation-related properties and two SVG attributes.
• Mattias Ekendahl created a page for cssMediaRule.
• Corey Gackenheimer added a browser compatibility table to DeviceOrientationEvent.
• Masayuki created pages for DOM input event and UIEvent, and edited a bunch of pages related to DOM events.
• Timothée Carry-Caignon added some notes to <button> (update 2012-01-24:) and translated Writing forward-compatible websites into French.
• Nickolay Ponomarev updated and improved the pages for DOM document and XMLHttpRequest.
• Florian Scholz updated CanvasRenderingContext2D and added WebKit- and Gecko-specific methods and attributes.
• Rob W added an example to Node.normalize.
• Toji added several new resources to the WebGL page.
• xkizer improved the examples and explanations in the Predefined core objects section of the JavaScript Guide.
• XP1 fixed a bunch of copyediting and style consistency issues in a whole slew of pages.

Mozilla technology docs

• Will Bamberg created a landing page and various articles for BrowserID.
• Axel Grude created pages for two dozen messaging-related XPCOM interfaces.
• Benjamin Smedberg wrote an article on Making cross-thread calls using runnables in XPCOM.

Mozilla project docs

• Jeff Beatty‘s work on the Localization Quick Start Guide is “done” — no longer marked as a draft.
• Mark Côté updated Mozilla automated testing to match current practices.
• Jeff Muizelaar wrote an article on Debugging update problems.
• Jonathan Watt updated Debugging on Mac OS X, added an Installation section to Eclipse , and signficantly updated and rewrote Eclipse CDT and Using NetBeans with Mozilla.
• Jared Wein wrote articles on Getting started with contributing patches to the Firefox preferences and Requesting feedback and ui-review for desktop Firefox front-end changes.

Even if it looks simple, UA parsing has proven to be a headache for numerous script authors. Though the structure of an UA is defined in the HTTP specification, the way relevant information is conveyed varies from one vendor to another. Also, the information you want to extract from it is not always the same: sometimes you want to know the browser (Firefox, SeaMonkey, Safari, Chrome, IE, Opera…), but most of the time you want to know the engine that powers them (Gecko, Webkit, Trident,…). You also need to get the version of the browser or the engine.

Old scripts often made some undue assumptions. Some are assuming that browser version numbers will never reach 10… This is not the case: Opera and Chrome have already crossed this landmark long ago, Firefox will reach it next week and IE soon after.

A few examples of Firefox UAs that your scripts should allow:

• Regular Firefox version: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0
• Nightly and Aurora Firefox versions: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0a1) Gecko/20120122 Firefox/12.0a1
• Chemspill Firefox version (three numbers) Mozilla/5.0 (Windows NT 6.2; rv:10.0.1) Gecko/20100101 Firefox/10.0.1

So, it is the last moment to check your UA-based browser detection code before your site goes havoc!

Last chance to check

Do it right now, in two weeks it would be too late.

What to do?

1. Code inspection: check your code to see if there is some UA-based browser detection code. If so, check if it handles multi-digit versions. (At the same time you could check if it is useful at all. Some old UA-detection code has not worked in ages, or try to go around problems fixed since years in browser…)
2. Library inspection: lots of libraries perform UA-based browser detection. If you are using any of them, check if it still is working with a version of Firefox with 2 digits. If not, notify the author of the lib and open a bug on bugzilla so that we can help others as all their customers are likely to suffer from the same problem.
3. Check if your site is working with the next Firefox version: download the Beta release of Firefox 10 (you can run several versions of Firefox simultaneously) It is always a good idea to use the beta, or even the aurora, version of Firefox if you are maintaining a site: you’ll discover incompatibilities earlier and will get time to fix them before your users start complaining. We are doing our best to prevent problems, but sometimes old code rely on incorrect behavior and stop working even when we are only fixing bugs.
4. Test other sites :-). Use the beta or aurora version of Firefox and surf the web. When you hit a UA-related problem report it with bugzilla. Give us as much info as possible like the importance of the site in your country and if you have conducted any action yourself. That way our evangelism team will be able to prioritize work adequately.

Finally, you should plan to get rid of these UA-based browser detection mechanism. If you can’t — and I know it isn’t always possible — I would be glad to know why: so please let us know in the comments below.

Now it is time to check your sites :-)

Thank you very much for your help.