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!

Weekly links September 22th 2011

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 mean.
The picks this week are:

Christian Heilmann

Responsive web design from the future is a very cool presentation talking about the need for responsive data interfaces.

If you want to read more tips or discuss the web with Christian, he’s available on Twitter as @codepo8.

Havi Hoffman

The work of data journalism: Find, clean, analyze, create … repeat – An interview with Simon Rogers, The Guardian’s pioneering data journalist, on effective and accurate data-driven storytelling.

Havi can be found on Twitter as @freshelectrons

Janet Swisher

If you like Jacob Gube’s article 7 Best Practices for Improving Your Website’s Usability, you’ll love Ginny Redish’s book Letting Go of the Words: Writing Web Content that Works.

If you want to read more tips or discuss the web with Janet, she’s available on Twitter as @jmswisher.

Jeff Griffiths

Migrations Map A slick data-driven map of worldwide immigration patterns, including a nice offline feature, and source hosted on github.

If you want to read more tips or discuss the web with Jeff, he’s available on Twitter as @canuckistani.

Joe Stagner

Central to HTML concepts is the ability to design and build a Web app with an off-line experience. Here is a quick introduction to HTML5 caching, a core concept to building a standards based Web Application with disconnected support.

If you want to read more tips or discuss the web with Joe, he’s available on Twitter as @MisfitGeek.

Rob Hawkes

WebGL and HTML5 Challenges For The Future is an interesting look at some of the important features that need to be supported for HTML5 and JavaScript games to really take hold.

If you want to read more tips or discuss the web with Rob, he’s available on Twitter as @robhawkes.

Robert Nyman

BrowserID demo from the Mozilla All-Hands – Identity on the web At the Mozilla All Hands last week, BrowserID was demoed and described in more detail, and the goals and ideas for it.

If you want to read more tips or discuss the web with Robert, he’s available on Twitter as @robertnyman.

Compiling an existing speech synthesis engine to JavaScript is a good way to avoid writing a complicated project like eSpeak from scratch. Once compiled, the eSpeak code in speak.js doesn’t know it’s running on the web: speak.js uses the Emscripten emulated filesystem to ‘fake’ the normal file reading and writing calls that the eSpeak C++ code has (fopen, fread, etc.). This allows the normal eSpeak datafiles to be used (either through an xhr, or by converting them to JSON and bundling them with the script file). The result of running the compiled eSpeak code is that it ‘writes’ a .wav file with the generated audio to the emulated filesystem. speak.js then takes that data, encodes it using base64, and creates a data URL. That URL is then loaded in an HTML5 audio element, letting the browser handle playback. (Note that while that is a very simple way to do things, it isn’t the most efficient. speak.js has not yet focused on speed, but with some additional work it could be much faster, if that turns out to be an issue.)

Why would you want TTS in JavaScript? Well, with speak.js you can bundle a single .js file in your website, and then generating speech is about as simple as writing

speak("hello world")

(see the speak.js website for instructions). The generated speech will be exactly the same on all platforms, unlike if your users each did TTS in their own way (using an OS capability, or a separate program). speak.js can also be used to build browser addons in a straightforward way, since it’s pure JavaScript – no need for platform dependent binaries, and the addon will work the same on all OSes.

A few more comments:

• JavaScript is getting more and more capable all the time. The development versions of the top JavaScript engines today can run code compiled from C++ only 3-5X slower than a fast C++ compiler, and getting even better. As a consequence, expanding the capabilities of the web platform can in many cases be done in JavaScript or by compiling to JavaScript, instead of adding new code to the browsers themselves, which inevitably takes longer – especially if you wait for all browsers to implement a particular feature.
• While speak.js uses only standards-based APIs, due to browser limitations it can’t work everywhere yet. It won’t work in IE, Safari or Opera since they don’t support typed arrays, nor in Chrome since it doesn’t support WAV data URLs. So currently speak.js only works properly in Firefox. However, the missing features just mentioned are not huge and hopefully those browser makers will implement them soon. It is also possible to implement workarounds in speak.js for these issues (see next comment).
• Help with improving speak.js is very welcome! One important thing we need is to implement workarounds for the issues that prevent speak.js from running on the browsers it currently can’t run on. Another goal is to build browser addons using speak.js. Please get in touch on github if you want to help out.
• eSpeak supports multiple languages so speak.js can too. You do need to include the additional language files though. Here is an experimental build where you can switch between English and French support (note that it is an unoptimized build, so it will run slower).

Firefox offers users complete control over the look and functionality of their Web browser with a gallery of hundreds of thousands of add-ons. With the launch of Add-on SDK and Add-on Builder Beta, web developers  need only knowledge of HTML, JavaScript and CSS to create great add-ons for Firefox that are restartless by default.

The Add-on SDK enables local development of add-ons through a command line interface, while the Firefox Add-on Builder Beta provides a hosted online build environment.

To find out more, head over to the Add-ons blog or the new Add-on SDK & Add-on Builder page.

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

JavaScript

Thanks to Dave Herman and BYK for their contributions last week.

• Proxy
• Shell global objects

SpiderMonkey

Thanks to Dave Herman for his contributions last week.

• Shell global objects
• JS_IsExceptionPending

Developing Mozilla

• Displaying Places information using views
• Running automated tests
• Using the Gecko SDK

Extensions

• Using the Gecko SDK
• XPCOM category image-sniffing-services
• Post data to window

XUL

• Examples
• Introduction to XUL
• Troubleshooting preference windows

XPCOM

• nsIPrintingPrompt
• nsIPrompt
• nsIWindowsRegKey

Interfaces

Thanks to David Bienvenu, Neil, and Trevor Hobson for their contributions.

• nsILoadGroup
• IAccessible2
• nsIAboutModule

Plugins

• PluginArray

As usual, we still need someone to update the NPAPI plugin documentation to cover the new Cocoa event model.

CSS

• -moz-column-count
• marks
• orphans

SVG

• style
• accumulate
• r

HTML

• li
• Drawing text using a canvas
• Focus management in HTML

DOM

Thanks to Neil for his contributions last week.

• Gecko DOM Reference
• document.cookie
• DOM Events

Recently I landed support for the HTML5 video ‘buffered’ property in Firefox. This is cool because we can now accurately determine which time-segments of a video we can play and seek into without needing to pause playback to download more data. Previously you could only get the byte position the download had reached, which often doesn’t map to the time ranges which are playable very well, especially in a variable bit rate video. This also can’t tell you if there are chunks which we skipped downloading before the downloaded byte position. Once the video controls UI is updated, users will be able to know exactly which segments of their video are downloaded and playable and can be seeked into without pausing playback to download more data.

To see this in action, download a current Firefox nightly build , and point your browser at my video ‘buffered’ property demo. You’ll see something like the screenshot below, including an extra progress bar (implemented using canvas) showing the time ranges which are buffered.

I’ve implemented the ‘buffered’ property for the Ogg and WAV backends. Support for the ‘buffered’ property for WebM is being worked on by Matthew Gregan, and is well underway. At the moment we return empty ranges for the ‘buffered’ property on video elements playing WebM and raw video.

My checkin just missed the cutoff for Firefox 4 Beta 3, so the first beta release that the video ‘buffered’ property will appear in is Firefox 4 Beta 4.

Removing the media element ‘load’ event.

Yesterday I checked in a patch that removes support for the ‘load’ event on <video> and <audio> elements. We simply never fire it. Also, the networkState attribute is now never NETWORK_LOADED. When we’ve read to the end of the media resource, networkState changes to NETWORK_IDLE. We plan to ship this change for Firefox 3.6.

This API has been removed based on consensus from everyone who are doing HTML5 video implementations and there are lots of other options for events that Robert goes over in his post.

Changing our CSS Gradient Syntax

We landed support for a form of CSS gradients on trunk a while ago, but we got considerable feedback that our syntax — which was an incremental improvement of Webkit’s syntax, which basically exposes a standard gradient API in the most direct possible way — sucked. A bunch of people on www-style got talking and Tab Atkins produced a much better proposal. Since we haven’t shipped our syntax anywhere yet, dropping it and implementing Tab’s syntax instead was a no-brainer. So Zack Weinberg, David Baron and I did that (using a -moz prefix of course), and today it landed on trunk. It should land on the Firefox 3.6 branch shortly. It’s unfortunate to land something new like this after the last beta, but in this case, it seems like the right thing to do instead of shipping CSS gradient syntax that we know nobody wants.

We’ve never shipped the “bad” CSS gradient syntax in a final release, but it is in our first beta. We’ll be updating it before we make our final release of 3.6. Stay turned for the new syntax on hacks.

what’s your single favorite thing about hacks.mozilla.org?

The survey is totally anonymous and takes 20 seconds or so. It’s limited, much like twitter, to a very short response. If you have ideas on improvement there’s room for that as well so please, respond away! If we get enough good feedback we’ll post results here as well.

Thanks!

XMLHttpRequests (XHR) can be either synchronous or asynchronous. Although most people use asynchronous requests there are instances where you might want to use a synchronous request. That is, wait until the XMLHttpRequest call completes to continue executing JavaScript. In Firefox 3 and earlier the browser would still fire timer events and respond to input events during a synchronous XHR request. In Firefox 3.5 and later input events such as mouse moves and timeouts will be suspended until the synchronous request completes. This allows the synchronous request to block.

For example:

function hello() {
     alert(“hello”);
}
 
setTimeout(hello, 20);
 
var req = new XMLHttpRequest();
req.open('GET', 'http://www.mozilla.org/', false);
req.send(null);

Prior to Firefox 3.5, it was impossible to determine if the “hello” function would be invoked during or after the XHR request. This led to all sorts of timing issues in web applications that used synchronous XHR requests.

The solution to this problem has been to delay input events and timeouts until after “req.send” returns.

For more information see the two bugs on the issue.