Mozilla Hacks - the Web developer blog » Standards

CSS 3D transformations in Firefox Nightly

Chris Heilmann — Wed, 26 Oct 2011 20:18:42 +0000

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) :

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 form.style) {
      support = true;
      pfx = props[i].replace('Perspective','');
      pfx = pfx.toLowerCase();
      break;
    }
    i++;
  } 
  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;
  document.querySelector('head').appendChild(styles);
}

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 bugzilla.mozilla.org!

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

More details about the WebAPI effort

Jonas Sicking — Mon, 29 Aug 2011 21:19:06 +0000

As we’ve hoped, there has been a lot of interest in the newly announced WebAPI effort. So I figured that I should explain in more detail some of my thinking around what we’re hoping to do and the challenges that are ahead of us.

Goal

The goal of this effort is to create APIs to expand what the Web can do. We don’t want people to end up choosing to develop for a proprietary platform just because the Web is lacking some capability.

The main effort, at least initially, is to enable access to hardware connected to the device, and data which is stored or available to the device. As for hardware, we want to make the full range of hardware that people use available to the web platform. From common hardware like cameras, to more rarely used (but no less awesome) hardware like USB-driven Nerf cannons. We also want to enable communication hardware like Bluetooth and NFC.

For data stored on the device, the most commonly discussed data today is contacts and calendar. This includes the ability to both read and write data. That is, we both want the Web platform to be able to enumerate contacts stored on the device, and read their details, as well as add and remove contacts. In short, we want it to be possible to create a Web page or Web app which lets the user manage his contact list. Same thing for calendar events and other types of data stored on devices.

Security and Privacy

One big reason these types of APIs haven’t been developed for the Web platform yet is because of their security and privacy implications. I would obviously not want every single Web page out there to be able to mess around with my contact list or my calendar. And being able to issue any commands to any USB device that I happen to have plugged in would likely result in everyone’s computer immediately being zombified.

So as we are developing these APIs, we always have to develop a security model to go along with them. In some cases simply asking the user, which is how we currently do Geolocation, might work. In others, where security implications are scarier or where describing the risk to the user is harder, we’ll have to come up with better solutions.

I really want to emphasize that we don’t yet know what the security story is going to be, but that we’re absolutely planning on having a solid security solution before we ship an API to millions of users.

Robert O’Callahan has a really great post about permissions for Web applications.

Standards

Mozilla has always had a strong commitment to Web standards. This is of course not something we’re changing! All of the APIs that we are developing will be developed with the goal of being standardized and implemented across both browsers and devices.

But it’s important to ensure that standards are good standards. This takes experimenting. Especially in areas which are as new to the Web, and as security sensitive, as these are.

Standards organizations aren’t a good place to do research. This is why we want to experiment and do research outside the standards organizations first. But always in the open, and always listening to feedback. We’re also going to clearly prefix any APIs as to indicate that they are experiments and might change once they get standardized.

Once we have a better understanding of what we think makes a good API we will create a proposal and bring to working groups like the Device API group at W3C, WAC and WHATWG.

Throughout this process we will of course be in contact with other interested parties, such as other browser vendors and web developers. This is part of the normal research and making sure that an API is a good API.

Mozilla always has and always will be a good steward of the open Web. We are not interested in creating a Mozilla-specific Web platform. We are interested in moving the open Web platform forward.

High Level vs. Low Level

One thing that often comes up with API design is whether we should do high level or low level APIs. For example, do we provide a low-level USB API, or a high-level API for cameras?

There are pros and cons with both. High level means that we can create more developer-friendly APIs. We can also provide a better security model since we can ensure that the page won’t issue any unexpected USB commands, and we can ensure that no privacy-sensitive access is made without user approval. But high level also means that developers can’t access a type of device until we’ve added support for it. So until we’ve added an API for Nerf cannons, there will be no way to talk to them.

Exposing a low-level USB API on the other hand, means that web pages can talk to any USB device in existence, with no need for us to add an explicit API for them. However it also requires developers to get their hands dirty with the details of the USB protocol and differences between devices.

The approach we’re planning on taking is to do both high-level and low-level APIs, as well as give people the proper incentives to use the one that is best for the user. But a very important point is to provide low-level APIs early to ensure that Mozilla isn’t on the critical path for innovation. Over time, we can add high-level APIs where that makes sense.

How you can join

As with all things Mozilla, we’re planning on doing all our work in the open. In fact, we’ll be relying on your help to make this successful! As to keep discussions focused, we’re going to use the a new mozilla.dev.webapi discussion forum for all communication. This means that you can participate through email, newsgroups, or the web-based google group UI.

You can subscribe to the mailing list at https://lists.mozilla.org/listinfo/dev-webapi

For other methods go to: http://www.mozilla.org/about/forums/#dev-webapi

We also use the #webapi IRC channel on irc.mozilla.org.

We’ll also be tracking progress on the wiki page https://wiki.mozilla.org/WebAPI

Looking forward to hearing from you to help build the next stage for the web platform!

Hiring developers

Edit: Forgot to mention, we are hiring several full time engineers for working on the WebAPI team! Read the job description and apply.

Introducing WebAPI

Robert Nyman — Tue, 23 Aug 2011 10:42:18 +0000

Mozilla would like to introduce WebAPI with the goal to provide a basic HTML5 phone experience within 3 to 6 months.

The current situation

Where we are today, there’s a clear distinction between the Open Web and native APIs and how things have to be built. As many developers are aware of, we need consistent APIs across web browsers, operating systems and devices to be able to build something for the world, not just a specific device or vendor. We need a way to take the web to the next step.

What is WebAPI?

WebAPI is an effort by Mozilla to bridge together the gap, and have consistent APIs that will work in all web browsers, no matter the operating system. Specification drafts and implementation prototypes will be available, and it will be submitted to W3C for standardization. Security is a very important factor here, and it will be a mix of existing security measurements (e.g. asking the user for permission, like Geolocation) or coming up with new alternatives to ensure this.

In the nearest timeframe we are looking into building:

Dialer: Telephony & Messaging API, Contacts API
Address Book: Contacts API
SMS: Telephony & Messaging API, Contacts API
Clock
Camera: Camera API, Filesystem API
Gallery: Filesystem API (could possibly be FileReader & FileWriter in conjunction)
Calculator
Settings: Device Status API, Settings API
Games: Accelerometer API, Mouse Lock API
Maps: Geolocation API, Contacts API

Contribute

We know that there are so many talented people out there with great input, so please contribute through any of these means:

Keep track of the WebAPI project page.
The WebAPI mailing list.
IRC: irc.mozilla.org in the #webapi room.
Start working by going to bug 67392 and look at the dependent bugs to find the ones that need help.

Hiring developers

We are also hiring several full time engineers for working with WebAPI. Read the job description and apply.

Accessibility and web innovation – a constant struggle

Chris Heilmann — Mon, 18 Apr 2011 14:57:32 +0000

I just came back from a small “accessibility tour” giving a talk about accessibility and web innovation in Stockholm, Sweden at Funkas Tillgänglighetsdagar and then in Paris at the W3Cafe meetup.

In essence what I was musing about is that there is still a massive disconnect between accessibility and the development world. Accessibility is not seen as something that is cool and bleeding edge but as a necessary evil. If you ask about accessibility on developer mailing lists that juggle HTML5, Node.js, CSS3 and other cool technologies with ease you are very likely to hear that people are considering as an afterthought or make sure that “the interface degrades gracefully”.

When you ask the accessibility world about cool new technologies you are very likely to hear that they may be interesting in a few years but are not ready yet and certainly will never be accessible in a legal sense.

Having been positioned in between these two parties for a long time I am getting tired of this and I want the two fractions to move closer to each other.

Accessibility is part of everything we do – the physical world has become much better in the last decades because we care for the needs of people with disabilities. Lowered kerbs on sidewalks, OCR Scanning, subtitles and captions on movies and TV programs – these are all things invented for a disability need but we all now benefit from it. The same can and should happen in interface design and web development. If you think about it, the features that make a good mobile interface also cover a lot of needs of different disability groups. So why don’t we work together?

You can see the slides of the talk on Slideshare:

You can get the slide deck on Slideshare:

The audio of the talk is available at archive.org:

There are also extensive notes on the talk available on my blog.

Multimedia on the web and using HTML5 sensibly

Chris Heilmann — Mon, 14 Feb 2011 17:52:41 +0000

Last week I went to the London Ajax User Meetup in London, England to deliver two talks about HTML5. One was a re-run of a talk I gave at MIT about Multimedia on the web and the second was a call to arms to use HTML5 sensibly. You can go over to Skillsmatter web site to see both talks back to back – but be sure to catch the notes to the second talk in this post, too.

In addition to my notes here there is also a great write-up of the evening by Ian Alderson available on the web.

Multimedia on the web

We’ve covered this talk before in the blog post here and you can read the extensive notes for the whole talk with code examples on my blog. The slides of the multimedia talk are on slideshare and here:

You can see “Multimedia on the web” on any HTML5 enabled device here (courtesy of vid.ly) or embedded here:

Download “Multimedia on the web” as MP4

Using HTML5 sensibly

Using HTML5 sensibly was a talk I wanted to give for a long time. Rather than just giving the facts, I wanted to raise some questions every developer should ask themselves, the HTML5 working groups and everyone who cares to listen. We are in the middle of a big change in our development environment and not many people realise that we are breaking a lot of old conventions without fallback.

You can get the slides on Slideshare or see them here:

You can see “Using HTML5 sensibly” on any HTML5 enabled device here (courtesy of vid.ly).

Download “Using HTML5 sensibly” as MP4

Notes on “Using HTML5 sensibly”

I started the talk by telling the story of the Antarctic Snow Cruiser – a marvel of technology built in 1939 to allow a crew to explore Antarctica. The job of the Cruiser was to give the crew all the neccesary creature comforts and allow them to drive through Antarctica, which is both very cold and also features massive cracks that the vehicle somehow needs to get over. The ingenious solution was to have huge wheels that can be retracted into the Cruiser to prevent them from getting brittle over night and to push the vehicle over the cracks. The Cruiser was built in a rush and tested on the way to the port to go down to Antarctica. It was a hit with the press and people delayed the whole trip even more by wanting to have their photo taken with it. Upon arrival the vehicle almost crashed into the sea as the ramp built for its delivery onto the ice was not strong enough. Even worse, once on the ice the Cruiser couldn’t get a grip and the wheels spun uselessly, almost overheating the engine. Despite all the hype, the cruiser was a massive failure.

A few things went wrong with the cruiser:

It was purely engineering driven
It was tested while on the road
It was never tested in the real environment
There was a massive media excitement before it proved its worth

Much like we deal with HTML5 nowadays. A lot of the information about HTML5 is marketing driven and used to sell a certain environment or browser to people. Instead of real applications and day-to-day use web sites we create demo sites to show what “HTML5 can do for you”. The term HTML5 gets washed out as it is used both for implementations of parts of the specification but also for browser-specific code that only works in a certain environment.

This is partly because of the specifications and the different players in the HTML5 world itself. The specs do not only contain definitions of markup but also JavaScript APIs and instructions on how to write a browser that renders HTML5 content. This is great as it takes away the liberty browser vendors had in the past in “creatively” applying the HTML4 specs, but it also means that people can focus on parts of the spec and of course rant about all the other parts. You’ve probably seen one talk about the amazing cool new semantics of HTML5 markup and another about API implementations using completely non-sensical markup back to back. This is what we get right now as the specs are too big and all-encompassing for implementers.

One of the main topics of the HTML5 work is pragmatism – XML and strict HTML just used too many things we simply don’t need. This shows itself a lot in the simplification of a plain HTML document. In HTML4.01 strict this was:


 lang="en">
>
   http-equiv="Content-Type" 
        content="text/html; charset=UTF-8">  
  >HTML - c'est moi!>
   rel="stylesheet" type="text/css"
        href="styles.css">
   type="text/javascript" src="magic.js">
  >
>
>
  >Heading! Everybody duck!>
  >I am content, hear me roar!>
   class="footer">By me!>
>
>

Neither the long DOCTYPE definition nor the http-equiv was ever used by browsers. It is not needed for browsers to do their job. In HTML5 this is a plain Vanilla document:

  
 lang="en">
>
   charset="utf-8">  
  >HTML5, c'est moi, ou HTML...>
   rel="stylesheet" href="styles.css">
   src="magic.js">>
>
>
  >Heading! Everybody duck!>
  >I am content, hear me roar!>
   class="footer">By me!>
>
>

Much simpler and shorter. In addition to that HTML5 also includes new semantic elements:

  
 lang="en">
>
  >HTML5, c'est moi, ou HTML...>
   rel="stylesheet" href="styles.css">
   src="magic.js">>
>
>
  >>Heading! Everybody duck!>>
  >
    >I am content, hear me roar!>
  >
  >>By me!>>
>
>

This gives us handles for styling and tells the browser what the different parts are. The simplification goes further though. As people never seemed to have bothered to write valid XML in HTML it is now also completely OK to mix upper and lower case and omit quotation marks around the attributes (if the attributes have one value, multi value attributes like classes need quotes around them once you add more than one value):

  
 lang=en>
  >HTML5, c'est moi, ou HTML...>
   rel=stylesheet href=styles.css>
   src=magic.js>>
>
  >>Heading! Everybody duck!>>
  >
    >I am content, hear me roar!>
  >
  >>By me!>>
>
>

Browsers are forgiving enough to fix these inconsistencies for us. For example the generated code in Firefox is:

  
 lang="en">>  
  >HTML5, c'est moi, ou HTML...>
   rel="stylesheet" href="styles.css">
   src="magic.js">>
  >>
  >>Heading! Everybody duck!>>
  >
    >I am content, hear me roar!>
 
  >
  >>By me!>>
>>

However, if we were to omit the closing

tag in the

the generated code looks different:


 lang="en">>  
  >HTML5, c'est moi, ou HTML...>
   rel="stylesheet" href="styles.css">
   src="magic.js">>
>>
  >>Heading! Everybody duck!>>
  >
    >I am content, hear me roar!
      >>
    >
    >By me!>
  >
>>

As you can see, the

People of HTML5 – Remy Sharp

Chris Heilmann — Tue, 11 Jan 2011 10:27:25 +0000

HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.

Leggi la traduzione in italiano

Today we are featuring Remy Sharp co-author of Introducing HTML5 and organiser of the Full Frontal conference in Brighton, England.

Remy is one of those ubiquitous people of HTML5. Whenever something needed fixing, there is probably something on GitHub that Remy wrote that helps you. He is also very English and doesn’t mince his words much.

You can find Remy on Twitter as @rem.

The video interview

Your browser does not support the video tag, check the video on YouTube.

Watch the video on YouTube or Download it from Archive.org as MP4 (98 MB), OGG (70 MB) or WebM (68MB)

Ten questions about HTML5 for Remy Sharp

1) Reading “Introducing HTML5″ it seems to me that you were more of the API – focused person and Bruce the markup guy. Is that a fair assumption? What is your background and passion?

That’s spot on. Bruce asked me to join the project as the “JavaScript guy” – which is the slogan I wear under my clothes and frequently reveal in a superman ‘spinning around’ fashion (often at the surprise of clients).

My background has always been coding – even from a young age, my dad had me copying out listings from old spectrum magazines only to result in hours of typing and some random error that I could never debug.

As I got older I graduated to coding in C but those were the days the SDKs were 10Mb downloaded over a 14kb modem, and compile in to some really odd environment. Suffice to say I didn’t get very far.

Then along came JavaScript. A programming language that didn’t require any special development environment. I could write the code in Notepad on my dodgy Window 95 box, and every machine came with the runtime: the browser. Score!

From that point on the idea of instant gratification from the browser meant that I was converted – JavaScript was the way for me.

Since then I’ve worked on backend environments too (yep, I’m a Perl guy, sorry!), but always worked and played in the front end in some way or another. However, since started on my own in 2006, it’s allowed me to move focus almost entirely on the front end, and specialise in JavaScript. Basically, work-wise: I’m a pig in shit [Ed: for our non-native English readers, he means "happy")].

2) From a programmer’s point of view, what are the most exciting bits about the HTML5 standard? What would you say is something every aspiring developer should get their head around first?

For me, the most exciting aspects of HTML5 is the depth of the JavaScript APIs. It’s pretty tricky to explain to Joe Bloggs that actually this newly spec’ed version of HTML isn’t mostly HTML; it’s mostly JavaScript.

I couldn’t put my finger on one single part of the spec, only because it’s like saying which is your favourite part of CSS (the :target selector – okay, so I can, but that’s not the point!). What’s most exciting to me is that HTML5 is saying that the browser is the platform that we can deliver real applications – take this technology seriously.

If an aspiring developer wanted something quick and impressive, I’d say play around with the video API – by no means is this the best API, just an easy one.

If they really wanted to blow people away with something amazing using HTML5, I’d say learn JavaScript (I’m assuming they’re already happy with HTML and CSS). Get a book like JavaScript: The Good Parts and then get JavaScript Patterns and master the language. Maybe, just maybe, then go buy Introducing HTML5, it’s written by two /really/ good looking (naked) guys: http://flic.kr/p/8iyQTE and http://flic.kr/p/8iy6Z1 [Ed: maybe NSFW, definitely disturbing].

3) In your book you wrote a nice step-by-step video player for HTML5 video. What do you think works well with the Video APIs and what are still problems that need solving?

The media API is dirt simple, so it means working with video and audio is a doddle. For me, most of it works really well (so long as you understand the loading process and the events).

Otherwise what’s really quite neat, is the fact I can capture the video frames and mess with them in a canvas element – there’s lots of fun that can be had there (see some of Paul Rouget’s demos for that!).

What sucks, and sucks hard, is the spec asks vendors, ie. browser makers, *not* to implement full screen mode. It uses security concerns as the reason (which I can understand), but Flash solved this long ago – so why not follow their lead on this particular problem? If native video won’t go full screen, it will never be a competitive alternative to Flash for video.

That all said, I do like that the folks behind WebKit went and ignored the spec, and implemented full screen. The specs are just guidelines, and personally, I think browsers should be adding this feature.

4) Let’s talk a bit about non-HTML5 standards, like Geolocation. I understand you did some work with that and found that some parts of the spec work well whilst others less so. Can you give us some insight?

On top of HTML5 specification there’s a bunch more specs that make the browser really, really exciting. If we focus on the browser being released today (IE9 included) there’s a massive amount that can be done that we couldn’t do 10 years ago.

There’s the “non-HTML5″ specs that actually were part of HTML5, but split out for good reason (so they can be better managed), like web storage, 2D canvas API and Web Sockets, but there’s also the /really/ “nothing-to-do-with-HTML5″ APIs (NTDWH5API!) like querySelector, XHR2 and the Device APIs. I’m super keen to try all of these out even if they’re not fully there in all the browsers.

Geolocation is a great example of cherry picking technology. Playing against the idea that the technology isn’t fully implemented. Something I find myself ranting on and on about when it comes to the question of whether a developer should use HTML5. Only 50% of Geolocation is implemented in the browsers supporting it, in that they don’t have altitude, heading or speed – all of which are part of the spec. Does that stop mainstream apps like Google Maps from using the API? (clue: no).

The guys writting the specs have done a pretty amazing job, and in particular there are few cases where the specs have been retrospectively written. XHR is one of these and now we’ve got a stable API being added in new browsers (i.e. IE6 sucks, yes, we all know that). Which leads us to drag and drop. The black sheep of the APIs. In theory a really powerful API that could make our applications rip, but the technical implementation is a shambles. PPK (Peter-Paul Koch) tore the spec a bit of a ‘new one’. It’s usable, but it’s confusing, and lacking.

Generally, I’ve found the “non-HTML5″ specs to be a bit of mixed bag. Some are well supported in new browsers, some not at all. SVG is an oldie and now really viable with the help of JavaScript libraries such as Raphaël.js or SVGWeb (a Flash based solution). All in all, there’s lots of options available in JavaScript API nowadays compared to back in the dark ages.

5) Let’s talk Canvas vs. SVG for a bit. Isn’t Canvas just having another pixel-based rectangle in the page much like Java Applets used to be? SVG, on the other hand is Vector based and thus would be a more natural tool to do something with open standards that we do in Flash now. When would you pick SVG instead of Canvas and vice versa?

Canvas, in a lot of ways is just like the Flash drawing APIs. It’s not accessible and a total black box. The thing is, in the West, there’s a lot of businesses, rightly or wrongly, that want their fancy animation thingy to work on iOS. Since Flash doesn’t work there, canvas is a superb solution.

However, you must, MUST, decide which technology to use. Don’t just use canvas because you saw a Mario Kart demo using it. Look at the pros and cons of each. SVG and the canvas API are not competitive technologies, they’re specially shaped hammers for specific jobs.

Brad Neuberg did a superb job of summarising the pros and cons of each, and I’m constantly referring people to it (here’s the video).

So it really boils down to:

Canvas: pixel manipulation, non-interactive and high animation
SVG: interactive, vector based

Choose wisely young padawan!

6) What about performance? Aren’t large Canvas solutions very slow, especially on mobile devices? Isn’t that a problem for gaming? What can be done to work around that?

Well…yes and no. I’m finishing a project that has a large canvas animation going on, and it’s not slow on mobile devices (not that it was designed for those). The reason it’s not slow is because of the way the canvas animates. It doesn’t need to be constantly updating at 60fps.

Performance depends on your application. Evaluate the environment, the technologies and make a good decision. I personally don’t think using a canvas for a really high performance game on a mobile is quite ready. I don’t think the devices have the ommph to get the job done – but there’s a hidden problem – the browser in the device isn’t quite up to it. Hardware acceleration is going to help, a lot, but today, right now, I don’t think we’ll see games like Angry Birds written in JavaScript.

That said… I’ve seriously considered how you could replicate a game like Canabalt using a mix of canvas, DIVs and CSS. I think it might be doable ::throws gauntlet::

I think our community could actually learn a lot from the Flash community. They’ve been through all of this already. Trying to make old versions of Flash from years back do things that were pushing the boundaries. People like Seb Lee-Delisle (@seb_ly / http://seb.ly) are doing an amazing job of teaching both the Flash and JavaScript community.

7) A feature that used to be HTML5 and is now an own spec is LocalStorage and its derivatives Session Storage or the full-fledged WebSQL and IndexedDB. Another thing is offline storage. There seems to be a huge discussion in developer circles about what to use when and if NoSQL solutions client side are the future or not. What are your thoughts? When can you use what and what are the drawbacks?

Personally I love seeing server-less applications. Looking at the storage solutions I often find it difficult to see why you wouldn’t use WebStorage every time.

In a way it acts like (in my limited experience of) NoSQL, in that you lookup a key and get a result.

Equally, I think SQL in the browser is over the top. Like you’re trying to use the storage method *you* understand and forcing it into the browser. Seems like too much work for too little win.

Offline Apps, API-wise, ie. the application cache is /really/ sexy. Like sexy with chocolate on top sexy. The idea that our applications can run without the web, or switch when it detects it’s offline is really powerful. The only problem is that the events are screwed. The event to say your app is now offline requires the user to intervene via the browser menu, telling the browser to “work in offline mode”. A total failure of experience. What’s worse is that, as far as I know, there’s no plan to make offline event fire properly :-(

That all said, cookies are definitely dead for me. I’ve yet to find a real solution for cookies since I found the Web Storage API – and there’s a good decent number of polyfills for Web Storage – so there’s really no fear of using the API.

8) Changing the track a bit, you’ve built the HTML5shiv to make HTML5elements styleable in IE. This idea sparked quite a lot of other solutions to make IE6 work with the new technologies (or actually simulate them). Where does this end? Do you think it is worth while to write much more code just to have full IE6 support?

There’s two things here:

Supporting IE6 (clue: don’t)
Polyfills

IE6, seriously, and for the umpteenth time, look at your users. Seriously. I know the project manager is going to say they don’t know what the figures are, in that case: find out! Then, once you’ve got the usage stats in hand, you know your audience and you know what technology they support.

If they’re mostly IE6 users, then adding native video with spinning and dancing canvas effect isn’t going to work – not even with shims and polyfills. IE6 is an old dog that just isn’t up to doing the mileage he used to be able to do back in his prime. But enough on this subject – the old ‘do I, or don’t I developer for IE6′ is long in the tooth.

Polyfills – that’s a different matter. They’re not there to support IE6, they’re there to bring browsers up to your expectations as a developer. However, I’d ask that you carefully consider them before pulling them in. The point of these scripts is they plug missing APIs in those older browsers. “Old browsers” doesn’t particularly mean IE6. For example, the Web Sockets API has a polyfill by way of Flash. If native Web Sockets aren’t there, Flash fills the gap, but the API is exposed in exactly the same manner, meaning that you don’t have to fork your code.

I don’t think people should be pulling in scripts just for the hell of it. You should consider what you’re trying to achieve and decide whether X technology is the right fit. If it is, and you know (or expect) your users have browsers that don’t support X technology – should you plug it with JavaScript or perhaps should you consider a different technology?

This exact same argument rings true for when someone adds jQuery just to add or remove a class from an element. It’s simply not worth it – but clearly that particular developer didn’t really understand what they needed to do. So is education the solution? I should hope so.

9) Where would you send people if they want to learn about HTML5? What are tutorials that taught you a lot? Where should interested people hang out?

HTML5 Doctor – fo sho’. :)

I tend to also direct people to my http://html5demos.com simply to encourage viewing source, and hacking away.

Regarding what tutorials taught me – if I’m totally honest, the place I’ve learnt the most from is actually HTML5Doctor.com. There’s some pretty good JavaScript / API tutorials coming from the chaps at http://bocoup.com. Otherwise, I actually spend a lot of time just snooping through the specifications, looking for bits that I’ve not seen before and generally poking them with a stick.

10) You have announced that you are concentrating on building a framework to make Websockets easy to work with. How is that getting on and what do you see Websockets being used for in the future? In other words, why the fascination?

Concentrating is a strong word ;-) but it is true, I’ve started working on a product that abstracts Web Sockets to a service. Not the API alone, since it’s so damn simple, but the server setup: creating sessions, user control flow, waiting for users and more.

The service is called Förbind. Swedish for “connect”, ie. to connect your users. It’s still early days, but I hope to release alpha access to forbind.net this month.

I used to work in finance web sites and real-time was the golden egg: to get that data as soon as it was published. So now that it’s available in a native form in the browser, I’m all over it!

What’s more, I love the idea of anonymous users. I created a bunch of demos where the user can contribute to something without ever really revealing themselves, and when the users come, you start to see how creative people are without really trying. Sure, you get a lot of cocks being drawn, but you also see some impressive ideas – my business 404 page for example allows people to leave a drawing, one of the most impressive is a Super Mario in all his glory. Anonymous users really interest me because as grey as things can seem sometimes, a stranger can easily inspire you.

Do you know anyone I should interview for “People of HTML5″? Tell me on Twitter: @codepo8

A call for quality HTML5 demo markup

Janet Swisher — Sun, 19 Dec 2010 20:32:29 +0000

HTML5 is a necessary evolution to make the web better. Before the HTML5 specs were created we used (and still use) a hacked together bunch of systems meant for describing and linking documents to create applications. We use generic elements to simulate rich interaction modules used in desktop development and we make assumptions as to what the user agent (browser) can do for the end user.

The good thing about this mess is that it taught us over the last few years to be paranoid in our development approach – we realised that in order to deliver working, accessible, maintainable and scalable systems we have to be professional and intelligent in our decisions and especially in our planning and architecting.

The trouble is that with the excitement around the cool new HTML5 things to play with a lot of these principles get lost and discarded as outdated. They aren’t – part of the mess that the web is in is that in 1999 a lot of people discarded everything else and instead worked only on the new hotness that was Internet Explorer 6 and DHTML. Let’s not repeat that mistake.

The two faces of HTML5 enthusiasm

Right now there are two things to get really excited about in HTML5: the richer, more meaningful semantics of new elements and the APIs that give us deep access into the workings of the browser and the operating system. The former allows us to build much richer interfaces and the latter allows us to build much more complex applications.

All of this comes with the awesome of view source (or check in development tools) for debugging. You can advocate HTML5 by writing clean and useful markup. You can kill it by treating the markup as a second class citizen which is only there to serve the script.

The markup enthusiasts are very happy about HTML5 and make it easy for people to upgrade – lots of cool new blog templates and boilerplate HTML templates are being built and polyfills created to allow using the new features and not leave behind outdated browsers.

On the app development side of things it looks much different and that is just sad. My only possible explanation is that people who come from desktop environments now tackle the HTML5 APIs without ever having to care about markup. The pragmatism of HTML5 allows a much more forgiving syntax than XHTML but it shouldn’t mean that we can just re-apply all the bad mistakes that held us back when it comes to maintenance for years.

During my career as a web developer I realised a few things make a lot of sense when building web apps:

If there is an element for a certain task – use that one. It is very likely that the element comes with accessibility and interaction features for free that you would otherwise have to simulate.
Separate CSS, JavaScript and HTML – which means it is easy to refactor your code without having to change all of them. It also means you can work in parallel with others instead of breaking each other’s code
Never rely on markup or content – as sooner or later some editing tool will come into place that messes with everything you created

This means a lot of things:

For starters it means that inline styles are simply evil as they override any settings you have in your style sheets. Only use them when this is exactly what you need to do or when you calculate them dynamically.
The same applies to inline scripting. If you have an onclick="foo()" somewhere in your HTML and foo() changes to bar() you have to rename it in every HTML document (of course nowadays it is one template, but it still means hunting down a reference you might miss)
If instead of using a native HTML element for a certain job you use SPANs and DIVs you’ll have to add classes to make them look and work – and simulate the keyboard accessibility, too.
You can’t rely on the text value of any element. A using the “edit” as the trigger for certain functionality would have to have the JS localised, too when you create the German .

Bla bla bla… C’mon Chris, it isn’t that bad!

The above best practices have been mentioned for years and a lot of people get sick of seeing them repeated. After all, this is intelligent development and standard practice in backend technologies. I came across a lot of “creative” uses lately though when doing a view-source on HTML5 demos – specifically the ones in the HTML5 advent calendar. And here is my yield of what people do.

Simulating a navigation list

One of the first things I encountered was a painting tool that had a gallery of created graphics as a background. Now, to me this would be a simple list:

>
  >
     href="{link}">
       src="{src}" alt="{title}">
    >
  >
  [...]
>

The markup I found though was this:

 id="sky">
   class="skyTile" style="{calculated styles};display:block">
     class="skyThumb" src="{src}" style="{generated styles}">
     src="images/thumb_dropShadow.png" 
         class="skyThumbShadow" 
         style="{generated styles}">
  >
  [...]
>

This, of course is generated by the backend. My first gripe is the dropshadow image, after all this is an HTML5 showcase – just use CSS3. We also have the three instances of generated styles and double classes. Granted, an extra class gives you a handle to all images instead of tiles, so why not. But as there is no real link around the image, the click handler has to read the url from somewhere. There is a lot of unnecessary back and forth between DOM and scripting here which does slow down the whole demo. Seeing that this is also the main navigation from the entry page to the editor this could be a list inside a nav element. A list groups these items together, a bunch of DIVs doesn’t (screen readers for example tell you how many items there are in a list).

Another list I found was supposed to be links to refresh the app and have a hierarchy but instead was a flat list with classes to define hierarchy and group:

 id="mitems">
   class="hedtop">Simple>
   class="mol">{name}>
  [... repeated ...]
   class="hed">{parent name}>
   class="mol">{name}>
  [... repeated ...]
>

This could be OK, granted you also shift keyboard focus, but why not:

>
 id="mitems">
  >{parent name}
    >
      > href="{url}">{name}>>
      [... repeated ...]
    >
  >
  [... repeated ...]
>
>

This would give you styling hooks and functionality for free. Links and buttons are great to trigger functionality – but it seems that is too easy.

Click (probably) here for functionality

If I build a button for an application to trigger a certain functionality this is the markup:

 type="button" class="edit">Edit>

Buttons are what trigger functionality – both a backend script or a JavaScript. They are keyboard accessible, have a disabled state and sensible out-of-the-box styling that nowadays can be completely overwritten. The class can be the definition of what the button should do – instead of the text which will change. You could use an ID but a class allows to repeat buttons (for example on the top and the bottom of a results list).

The buttons I found though were slightly different:

 id="homeButtonPanel">
   class="homeButton" id="drawHomeButton" 
       style="display: block;">
    >Start Drawing>
  >
   class="homeButton" id="viewHomeButton" 
       style="display: block;">
    >View the Mural>
  >
>
 
 id="controlPanel" style="display: block;">
 class="titleButton">>{title}>>
   class="mainMenu">
     class="mainButton mainSelected" id="drawButton">
      >Draw>
       id="inkDisplay">
         id="inkMeter" style="width: 94px;">
        >
      >
    >
     class="menuContainer">
       class="menuButton drawMenuButton" id="behaviorsButton"
           style="display: block; opacity: 1;">
        >Gesture>Behaviors>
      >
    >
     class="menuContainer">
       class="menuButton drawMenuButton" id="artworkButton" 
           style="display: block; opacity: 1;">
        >Artwork>
      >
    >
     class="menuContainer">
       class="menuButton drawMenuButton" id="resetButton" 
           style="display: block; opacity: 1;">
        >Reset>
      >
    >
     class="menuContainer">
       class="menuButton drawMenuButton" id="undoButton" 
           style="display: block; opacity: 1;">
        >Undo>
      >
    >
     class="menuContainer">
       class="menuButton drawMenuButton" id="saveButton" 
           style="display: block; opacity: 1;">
        >Save>
      >
    >
  >
   class="mainMenu">
     class="mainButton" id="viewButton">>View>>
  >
   class="mainMenu">
     class="secondaryButton" id="helpButton">>Help>>
  >
   class="mainMenu">
     class="mainShare shareButtonSmall" id="mainTwitterButton">
       alt="twitter" src="images/twitter_icon.png" 
           style="opacity: 0.6;">
    >
     class="mainShare shareButtonLarge" id="mainFacebookButton">
       alt="facebook" src="images/facebook_icon.png">
    >
     class="mainShare shareButtonSmall" id="mainEmailButton">
       alt="email" src="images/email_icon.png" style="opacity: 0.6;">
    >
  >
>

So instead of using a nested list with classes for each button and the hierarchy in the nesting we have a lot of classes and a hand-rolled DIV construct. Instead of making buttons really disabled we rely on opacity and there is quite a mix of inline images and background images (if all were background images, they could be one sprite!). Keyboard navigation will have to be written for this and if you were to add a button you’d have to come up with another ID.

HTML5 actually has a construct for this. There is a menu element with command child elements. These are in use in Chrome’s side bar for example and should be what we use. If you want to make it work for everyone, a nested list with button elements is what to go for.

The overly complex DIV construct is quite used though – this was another example:

 class="uiScreen" id="startScreen">
   class="panelBackground" id="mainResumeButton" style="display: none;">
     class="largeUIButton" id="resumeButton">Resume Game>
  >
   class="panelBackground" id="mainStartButton">
     class="largeUIButton" id="startButton">Start Game>
  >		
   class="panelBackground" id="mainHelpButton">
     class="largeUIButton" id="helpButton">Help>
  >
   class="panelBackground" id="mainHighscoreButton">
     class="largeUIButton" id="highscoreButton">High Scores>
  >
>

When in doubt – add an ID and class to everything.

Other buttons I encountered were actually links pointing to javascript:// using an inline style to indicate hierarchy:

 class="navlist">
  > id="play" href="javascript://" 
         style="display: inline;">Play>>    
  > id="pause" href="javascript://">Pause>>
   style="padding-left: 2px;">Effects:>
  > id="bw" href="javascript://">Bw>>
  > id="outline" href="javascript://">Outline>>
  > id="color" href="javascript://">Color>>
  > id="invert" href="javascript://">Invert>>
  > id="matrix" href="javascript://">Matrix>>
  > id="old" href="javascript://">Old>>
>

Talking of inline – here’s a great example of a tool generating a lot of code that could be replaced by a single event handler and event delegation:

 id="tools">
   onmouseout="buttonOut(1)" onmouseover="buttonOver(1)"
        onclick="buttonClicked(1)" id="button1" class="button">
     alt="" src="image/button/1.png">
  >
   onmouseout="buttonOut(2)" onmouseover="buttonOver(2)"
        onclick="buttonClicked(2)" id="button2" class="button">
         alt="" src="image/button/2.png">
  >
 
  [...repeated 20 times...]
 
 id="toolsSeparator"> >
   title="" id="toolbarButtonSave" class="toolbarButton"
     href="javascript:saveCanvas()">
     alt="" src="image/save.png">
  >
   title="New" id="toolbarButtonNew" class="toolbarButton"
     href="javascript:newCanvas()">
     alt="New" src="image/new.png">>
  
   id="toolbarButtonMenu" class="toolbarButton"
     onmouseout="closeMenuDelay()" onmouseover="showMenuHover()"
     href="javascript:showMenu()">
     alt=">" src="image/menu.png">
  >
   onmouseout="closeMenuDelay()" onmouseover="overMenu()" id="menu">
     class="saveMenu" onmouseout="closeMenuDelay()" 
       onmouseover="overMenu()" href="javascript:saveCanvas()">
      save normal
    >
     class="saveMenu" onmouseout="closeMenuDelay()" 
       onmouseover="overMenu()" href="javascript:saveCanvasHi()">
      save high quality
       class="footnote">  (rename to *.png)>
    >
     onmouseout="closeMenuDelay()" onmouseover="overMenu()"
       href="javascript:showAbout()">
      about...
    >
     class="lastMenu" target="_top" onmouseout="closeMenuDelay()"
       onmouseover="overMenu()" 
       href="{url}">
       class="footnote">
        >elsewhere: >
      >
      >a sound memory game>
    >
  >
  
>

Notice that if the images for the button couldn’t be loaded for one reason or another (or you can’t see them at all) this application is very confusing indeed – no alternative text for the images and no text content to fall back to. I am also very much sure that the in and out handlers trigger visual effects CSS could handle better.

Reasons and effects

I know there are probably good reasons for all of this, and I am sure I will also do things wrongly when I am rushed or want to get things out quickly. What we have to understand though is that right now we have a responsibility to show the best of breed demos we can.

We cannot preach the open web and technologies and view-source over closed systems and at the same time forget the things we learnt in the last decade. Some of these things I found look like code Frontpage or Dreamweaver could have produced in the 90ies and resulted in a lot of badly performing, hard to maintain products that either still annoy people who have to use them or get replaced every 2 years.

We have a mandate to educate the new developers coming to the web. Unlearning something is much harder than learning it – so let’s not start with bloat and quick fixes that work but forget to advocate clean code and thinking about the impact your product has on the end users (thinking accessibility) and the poor sods that will have to maintain your product when you are gone. We are not here to advocate effects and products, we are here to promote the tools that allow anyone to easily build something cool that is also easy to understand.

HTML5 is about evolving the web as a platform – we also need to evolve with it and take more responsibility. We have app and we have markup enthusiasts. Let’s make them work together to build things that are great functionality and clean semantics.

Delivering the good message of local storage

Chris Heilmann — Tue, 07 Dec 2010 01:21:03 +0000

As you might know there are an incredible amount of advent calendar blogs out at the moment each delivering one cool article for each day of December until Christmas.

Today (6/12/11) two calendar blogs delivered an article of mine talking about the benefits of using local storage in browsers and how to implement it.

You can find the English version on the 24ways.org calendar and a German translation at the Webkrauts calendar.

In essence, the article explains why it is a good idea to use local storage, explains how to use it, how to work around the issue that local storage can only store strings and gives example code on how to speed up web service use by caching information client-side much like you would do it on a server.

Have a read and go speed up your own solutions by using what browsers provide you these days.

Firefox 4: HTML5 Forms

Anthony Ricaud — Thu, 11 Nov 2010 16:00:46 +0000

Firefox 4 will come with better support for HTML5 forms. In the latest beta we are experimenting with a set of new features: more inputs types (email, url, tel, search), new attributes (placeholder, autofocus, list), decoupled forms and different validation mechanisms. This is thanks mostly to the hard work of Mounir Lamouri.

Some examples will work in other browsers, but you’ll need Firefox 4 beta to see all of them.

New input field types

In the same fashion as new HTML5 elements, we have new field types to better express what kind of input we want. The look and feel of many of these elements is the same as a text field, but they carry a different semantic meaning. This means that browsers can optimize the experience for users. For example, a mobile browser can provide a specific keyboard for a field. Or the browser can pre-fill phone number fields based on people in your address book. And extensions may even provide some features based on those types.

In this beta, Firefox comes with four new kind of inputs :

 type="search">
 type="tel">
 type="url">
 type="email">

Of the four new input types, url and email will also validate their content. We’ll talk about that later.

We also have support for a new kind of field:

 for="i1 i2">

You can use this element to represent an area of the page that reacts to the interaction with a form. Think about the total price in a cart after you’ve changed the quantity of items or the shipping options. It won’t compute anything, you’ll need to do that with JavaScript, but it will give hints to accessibility technologies. The for attribute is a list of IDs of the fields that intervene into the calculation.

Text fields have been improved with support. You can easily provide a list of suggestions for a field as the user is typing. You bind the field and the datalist by using the list attribute. It will use every option element inside datalist to populate the list. And for browsers without datalist support, they will display the content of the datalist element. So be sure to provide some valid markup to get a nice fallback.

Enter a city:

or choose one

>Enter a city:  list="cities">>
 id="cities">
  or
  >choose one
    >
       value="Paris">Paris>
       value="London">London>
       value="Berlin">Berlin>
       value="New York">New York>
       value="Tokyo">Tokyo>
       value="Sydney">Sydney>
       value="Johannesburg">Johannesburg>
    >
  >
>

New input attributes

Autofocus

When you add this to a field, it will receive focus as soon as possible. The direct advantage for the user is that all sites will have the same algorithm for autofocus instead of relying on different JavaScript code. And browsers or extensions could disable this behavior if a user is not interested in it.

 autofocus>

Placeholder

The value of this attribute will be displayed inside the form when it is empty and not focused. You can put an example of the kind of expected value.

>Telephone:  placeholder="1-800-555-1234">>
>Comments:  placeholder="Tell us what you think about our service…">>

Decoupled forms

You have more options to define the interaction between fields and forms.

form attribute

elements don’t need to be children of a

element anymore. You can define them anywhere you want and bind them to a form using the new form attribute. It takes the ID of the form it should bind to.

Here’s an example. Let’s say you’re working on a search engine for some blogging software. You want a very simple form for the general use case and some advanced options if the user needs more control.

At the top of the page you could put:

 type="search" name="search_field" form="search_form">

And at the bottom:

 id="search_form" action="search.php" method="post">
  >
    >Advanced options>
     type="checkbox">Private posts
    
  >
>

This will behave as if the search field was part of the form. And you get the freedom of placing it wherever you want in your HTML.

Form options on fields

All the options that can be defined at the form level can be overridden at the field element. All submit fields (

HTML5 Video preload attribute supported in Firefox 4, autobuffer attribute removed

Paul Rouget — Tue, 24 Aug 2010 14:22:49 +0000

This is a re-post from Chris Pearce’s blog. To comply with the HTML5 specification, we replaced the autobuffer attribute with the tri-state preload attribute. We encourage you to update your code. See the documention on MDC.

Late last week I landed support on Firefox trunk for the HTML5 video ‘preload’ attribute. This replaces the ‘autobuffer’ attribute, which we previously supported. If you were previously using the autobuffer attribute on your HTLM5 videos, you need to update to using the preload attribute as well.

The preload attribute provides a hint to the browser as to how much downloading is sensible for a given media. The preload attribute can have three values:

“none” – suggests to the browser that it doesn’t need to load this media at all until the user plays the resource. The browser will delay any network traffic required to load the media until the users tries to play the resource, or explicitly loads the resource. I suggest using this preload value, along with the poster attribute, when it’s unlikely that the user will play the resource. This is probably most useful in a mobile environment, where data can be expensive.
“metadata” – suggests to the browser that it isn’t necessary to load the entire resource in advance. The browser will suspend the load after loading metadata, displaying the first video frame (if there’s no poster image), and ensuring it can play the media. This is the default behaviour, and prevents excess network traffic when the web developer isn’t certain the video will definitely be played. If you don’t specify a preload value, Firefox will automatically do this. This was also the default behaviour in Firefox 3.5 and 3.6 in the absence of the autobuffer attribute. This default behaviour is a suitable compromise between bandwidth saving and user convenience.
“auto” – suggests to the browser that it should load as much of the resource as possible. As long as the browser’s own media cache isn’t full, it will keep on downloading. I suggest this is most useful in the “YouTube” case, when you’ve got a media which the user is almost certainly going to watch, and so having the user download the media is not likely to be wasting server bandwidth. This behaviour is the same as using the autobuffer attribute in Firefox 3.5 and 3.6

Since the autobuffer attribute is no longer present in Firefox 4, and the preload attribute is not present in Firefox 3.5 and 3.6, if you want a media to download completely, you should include both preload=”auto” and autobuffer in the video element, e.g.:

If you want the video to only be downloaded if the user actually plays the video, you should not include either the preload or the autobuffer attribute. The default behaviour in Firefox 3.5, 3.6, and the upcoming Firefox 4 is to only load up to the first frame and then suspend the download.

Firefox 4: An early walk-through of IndexedDB

Arun Ranganathan — Tue, 01 Jun 2010 18:43:26 +0000

Web developers already have localStorage, which is used for client side storage of simple key-value pairs. This alone doesn’t address the needs of many web applications for structured storage and indexed data. Mozilla is working on a structured storage API with indexing support called IndexedDB, and we will have some test builds in the next few weeks. This can be compared to the WebDatabase API implemented by several browsers that uses a subset of the allowable language of SQLite. Mozilla has chosen to not implement WebDatabase for various reasons discussed in this post.

In order to compare IndexedDB and WebDatabase, we are going to show four examples that use most parts of the asynchronous APIs of each specification. The differences between SQL storage with tables (WebDatabase) and JavaScript object storage with indexes (IndexedDB) becomes pretty clear after reading the examples. The synchronous versions of these APIs are only available on worker threads. Since not all browsers currently implement worker threads, the synchronous APIs will not be discussed at this time. The IndexedDB code is based off a proposal that Mozilla has submitted to the W3C WebApps working group that has gotten positive feedback so far. The code for both APIs does not include any error handling (for brevity), but production code should always have it!

These examples are for the storage of a candy store’s sale of candy to customers, which we’ll refer to as kids. Each entry in candySales represents a sale of a specified amount of candy to a kid, specified by an entry in candy and kids respectively.

Example 1 – Opening and Setting Up a Database

This first example demonstrates how to open a database connection and create the tables or object stores if the version number is not correct. Upon opening the database, both examples check the version and create the necessary tables or object stores and then set the correct version number. WebDatabase is a bit stricter in how it handles versions by giving an error if the database version is not what the caller expects (this is specified by the second argument to openDatabase). IndexedDB simply lets the caller handle versioning as they see fit. Note that there is active discussion about how IndexedDB should handle version changes in the working group.

WebDatabase

var db = window.openDatabase("CandyDB", "",
                             "My candy store database",
                             1024);
if (db.version != "1") {
  db.changeVersion(db.version, "1", function(tx) {
    // User's first visit.  Initialize database.
    var tables = [
      { name: "kids", columns: ["id INTEGER PRIMARY KEY",
                                "name TEXT"]},
      { name: "candy", columns: ["id INTEGER PRIMARY KEY",
                                 "name TEXT"]},
      { name: "candySales", columns: ["kidId INTEGER",
                                      "candyId INTEGER",
                                      "date TEXT"]}
    ];
 
    for (var index = 0; index < tables.length; index++) {
      var table = tables[index];
      tx.executeSql("CREATE TABLE " + table.name + "(" +
                    table.columns.join(", ") + ");");
    }
  }, null, function() { loadData(db); });
}
else {
  // User has been here before, no initialization required.
  loadData(db);
}

IndexedDB

var request = window.indexedDB.open("CandyDB",
                                    "My candy store database");
request.onsuccess = function(event) {
  var db = event.result;
  if (db.version != "1") {
    // User's first visit, initialize database.
    var createdObjectStoreCount = 0;
    var objectStores = [
      { name: "kids", keyPath: "id", autoIncrement: true },
      { name: "candy", keyPath: "id", autoIncrement: true },
      { name: "candySales", keyPath: "", autoIncrement: true }
    ];
 
    function objectStoreCreated(event) {
      if (++createdObjectStoreCount == objectStores.length) {
        db.setVersion("1").onsuccess = function(event) {
          loadData(db);
        };
      }
    }
 
    for (var index = 0; index < objectStores.length; index++) {
      var params = objectStores[index];
      request = db.createObjectStore(params.name, params.keyPath,
                                     params.autoIncrement);
      request.onsuccess = objectStoreCreated;
    }
  }
  else {
    // User has been here before, no initialization required.
    loadData(db);
  }
};

Example 2 – Storing Kids in the Database

This example stores several kids into the appropriate table or object store. This example demonstrates one of the risks that have to be dealt with when using WebDatabase: SQL injection attacks. In WebDatabase explicit transactions must be used, but in IndexedDB a transaction is provided automatically if only one object store is accessed. Transaction locking is per-object store in IndexedDB. Additionally, IndexedDB takes a JavaScript object to insert, whereas with WebDatabase callers must bind specific columns. In both cases you get the insertion id in the callback.

WebDatabase

var kids = [
  { name: "Anna" },
  { name: "Betty" },
  { name: "Christine" }
];
 
var db = window.openDatabase("CandyDB", "1",
                             "My candy store database",
                             1024);
db.transaction(function(tx) {
  for (var index = 0; index < kids.length; index++) {
    var kid = kids[index];
    tx.executeSql("INSERT INTO kids (name) VALUES (:name);", [kid],
                  function(tx, results) {
      document.getElementById("display").textContent =
          "Saved record for " + kid.name +
          " with id " + results.insertId;
    });
  }
});

IndexedDB

var kids = [
  { name: "Anna" },
  { name: "Betty" },
  { name: "Christine" }
];
 
var request = window.indexedDB.open("CandyDB",
                                    "My candy store database");
request.onsuccess = function(event) {
  var objectStore = event.result.objectStore("kids");
  for (var index = 0; index < kids.length; index++) {
    var kid = kids[index];
    objectStore.add(kid).onsuccess = function(event) {
      document.getElementById("display").textContent =
        "Saved record for " + kid.name + " with id " + event.result;
    };
  }
};

Example 3 – List All Kids

This example lists all of the kids stored in the kids table or the kids object store. WebDatabase uses a result set object which will be passed to the callback method provided after all rows have been retrieved. IndexedDB, on the other hand, passes a cursor to the event handler as results are retrieved. Results should come back faster, as a result. While not shown in this example, you can also stop iterating data with IndexedDB by simply not calling cursor.continue().

WebDatabase

var db = window.openDatabase("CandyDB", "1",
                             "My candy store database",
                             1024);
db.readTransaction(function(tx) {
  // Enumerate the entire table.
  tx.executeSql("SELECT * FROM kids", function(tx, results) {
    var rows = results.rows;
    for (var index = 0; index < rows.length; index++) {
      var item = rows.item(index);
      var element = document.createElement("div");
      element.textContent = item.name;
      document.getElementById("kidList").appendChild(element);
    }
  });
});

IndexedDB

var request = window.indexedDB.open("CandyDB",
                                    "My candy store database");
request.onsuccess = function(event) {
  // Enumerate the entire object store.
  request = event.result.objectStore("kids").openCursor();
  request.onsuccess = function(event) {
    var cursor = event.result;
    // If cursor is null then we've completed the enumeration.
    if (!cursor) {
      return;
    }
    var element = document.createElement("div");
    element.textContent = cursor.value.name;
    document.getElementById("kidList").appendChild(element);
    cursor.continue();
  };
};

Example 4 – List Kids Who Bought Candy

This example lists all the kids, and how much candy each kid purchased. WebDatabase simply uses a LEFT JOIN query which makes this example very simple. IndexedDB does not currently have an API specified for doing a join between different object stores. As a result, the example opens a cursor to the kids object store and an object cursor on the kidId index on the candySales object store and performs the join manually.

WebDatabase

var db = window.openDatabase("CandyDB", "1",
                             "My candy store database",
                             1024);
db.readTransaction(function(tx) {
  tx.executeSql("SELECT name, COUNT(candySales.kidId) " +
                "FROM kids " +
                "LEFT JOIN candySales " +
                "ON kids.id = candySales.kidId " +
                "GROUP BY kids.id;",
                function(tx, results) {
    var display = document.getElementById("purchaseList");
    var rows = results.rows;
    for (var index = 0; index < rows.length; index++) {
      var item = rows.item(index);
      display.textContent += ", " + item.name + "bought " +
                             item.count + "pieces";
    }
  });
});

IndexedDB

candyEaters = [];
function displayCandyEaters(event) {
  var display = document.getElementById("purchaseList");
  for (var i in candyEaters) {
    display.textContent += ", " + candyEaters[i].name + "bought " +
                           candyEaters[i].count + "pieces";
  }
};
 
var request = window.indexedDB.open("CandyDB",
                                    "My candy store database");
request.onsuccess = function(event) {
  var db = event.result;
  var transaction = db.transaction(["kids", "candySales"]);
  transaction.oncomplete = displayCandyEaters;
 
  var kidCursor;
  var saleCursor;
  var salesLoaded = false;
  var count;
 
  var kidsStore = transaction.objectStore("kids");
  kidsStore.openCursor().onsuccess = function(event) {
    kidCursor = event.result;
    count = 0;
    attemptWalk();
  }
  var salesStore = transaction.objectStore("candySales");
  var kidIndex = salesStore.index("kidId");
  kidIndex.openObjectCursor().onsuccess = function(event) {
    saleCursor = event.result;
    salesLoaded = true;
    attemptWalk();
  }
  function attemptWalk() {
    if (!kidCursor || !salesLoaded)
      return;
 
    if (saleCursor && kidCursor.value.id == saleCursor.kidId) {
      count++;
      saleCursor.continue();
    }
    else {
      candyEaters.push({ name: kidCursor.value.name, count: count });
      kidCursor.continue();
    }
  }
}

IndexedDB generally simplifies the programming model for interacting with databases, and allows for a wide number of use cases. The working group is designing this API so it could be wrapped by JavaScript libraries; for instance, there’s plenty of room for a CouchDB-style API on top of our IndexedDB implementation. It would also be very possible to build a SQL-based API on top of IndexedDB (such as WebDatabase). Mozilla is eager to get developer feedback about IndexedDB, particularly since the specification has not been finalized yet. Feel free to leave a comment here expressing your thoughts or leave anonymous feedback through Rypple.

Beyond HTML5: Database APIs and the Road to IndexedDB

Arun Ranganathan — Tue, 01 Jun 2010 18:43:00 +0000

IndexedDB is an evolving web standard for the storage of significant amounts of structured data in the browser and for high performance searches on this data using indexes. Mozilla has submitted substantial technical feedback on the specification, and we plan to implement it in Firefox 4. We spoke to prominent web developers about evolving an elegant structured storage API for the web. While versions of Safari, Chrome, and Opera support a technology called Web SQL Database, which uses SQL statements as string arguments passed to a JavaScript API, we think developer aesthetics are an important consideration, and that this is a particularly inelegant solution for client-side web applications. We brought developer feedback to the editor of the IndexedDB specification, and also spoke with Microsoft, who agree with us that IndexedDB is a good option for the web. With additional implementations from the Chrome team in the offing, we think it is worth explaining our design choices, and why we think IndexedDB is a better solution for the web than Web SQL Database.

Web applications can already take advantage of localStorage and sessionStorage in IE 8+, Safari 4+, Chrome 4+, Opera 10.5+ and Firefox 2+ to store key-value pairs with a simple JavaScript API. The Web Storage standard (encompassing localStorage and sessionStorage), now widely implemented, is useful for storing smaller amounts of data, but less useful for storing larger amounts of structured data. While many server-side databases use SQL to programmatically store structured data and to meaningfully query it, on the client-side, the use of SQL in a JavaScript API has been contentious.

SQL? Which SQL?

Many web developers certainly are familiar with SQL, since many developers touch just as much server-side code (e.g. PHP and database operations) as client-side code (e.g. JavaScript, CSS, and markup). However, despite the ubiquity that SQL enjoys, there isn’t a single normative SQL standard that defines the technology. In particular, SQLite supports most of SQL-92, with some notable omissions, and is what the WebDatabase API is based on. But SQLite itself isn’t a specification — it’s a release-ready technology! And the best definition of what constitutes the supported subset of SQL that SQLite uses is the SQLite manual. In order to really get Web SQL Database right, we’d have to first start with defining a meaningful subset of SQL for web applications. Why define a whole other language, when more elegant solutions exist within JavaScript itself?

The Benefits and Pitfalls of SQLite

We think SQLite is an extremely useful technology for applications, and make it available for Firefox extensions and trusted code. We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don’t want changes to SQLite to affect the web later, and don’t think harnessing major browser releases (and a web standard) to SQLite is prudent. IndexedDB does not have this problem; even though our underlying implementation of IndexedDB may be based on SQLite, we keep developers insulated from changes to SQLite by exposing an API that isn’t based on SQLite’s supported syntax.

Aesthetics and Web Developers

Last year, we held a summit at the Mozilla campus to discuss storage on the web. We invited web developers to speak to us about a desirable structured storage API on the web. Many did express resigned acceptance of a SQLite-based API, since they had already experimented with releases of Web SQL Database in some browsers, and claimed that something in circulation was better than a collection of ideas. Yet, all voiced enthusiasm for better design choices, and how a simpler model would make life easier for them. We watched as developers whiteboarded a simple BTree API that addressed their application storage needs, and this galvanized us to consider other options. We were resolved that using strings representing SQL commands lacked the elegance of a “web native” JavaScript API, and started looking at alternatives. Along with Microsoft, we sent feedback about the IndexedDB proposal and actively became involved in the standardization effort.

In another article, we compare IndexedDB with Web SQL Database, and note that the former provides much syntactic simplicity over the latter. IndexedDB leaves room for a third-party JavaScript library to straddle the underlying primitives with a BTree API, and we look forward to seeing initiatives like BrowserCouch built on top of IndexedDB. Intrepid web developers can even build a SQL API on top of IndexedDB. We’d particularly welcome an implementation of the Web SQL Database API on top of IndexedDB, since we think that this is technically feasible. Starting with a SQL-based API for use with browser primitives wasn’t the right first step, but certainly there’s room for SQL-based APIs on top of IndexedDB.

We want to continue the discussion with web developers about storage on the web, since that helps us structure our thoughts about product features and future web standards. We look forward to seeing the next generation of web applications with support for high performance searches on indexed data, and to seeing web applications work even more robustly in “airplane mode.”

upcoming changes to the viewport meta tag for firefox mobile

Christopher Blizzard — Thu, 27 May 2010 16:59:03 +0000

This is a guest post by Matt Brubeck who works on the Firefox Mobile team.

The upcoming release of Mobile Firefox (Fennec) 1.1 features improved
support for the tag. Previous version of Fennec supported the width, height, and initial-scale viewport properties, but had problems with some sites designed for iPhone and Android browsers. We now support the same properties Mobile Safari does, and we also changed Fennec to render mobile sites more consistently on screens of different sizes and resolutions.

touch.facebook.com before:

touch.facebook.com after:

You can see these changes for yourself in the latest Fennec 1.1 and trunk nightly builds for Maemo, Android, Windows, Mac, or Linux.

Background

Mobile browers like Fennec render pages in a virtual “window” (the viewport), usually wider than the screen, so they don’t need to squeeze every page layout into a tiny window (which would break many non-mobile-optimized sites). Users can pan and zoom to see different areas of the page.

Mobile Safari introduced the “viewport meta tag” to let web developers control the viewport’s size and scale. Many other mobile browsers now support this tag, although it is not part of any web standard. Apple’s documentation does a good job explaining how web developers can use this tag, but we had to do some detective work to figure out exactly how to implement it in Fennec. For example, Safari’s documentation says the content is a “comma-delimited list,” but existing browsers and web pages use any mix of commas, semicolons, and spaces as separators.

Viewport basics

A typical mobile-optimized site contains something like the following:

<meta name="viewport"
 content="width=device-width, initial-scale=1, maximum-scale=1"/>

The width property controls the size of the viewport. It can be set to a specific number of pixels like width=600 or to the special value device-width value which is the width of the screen in CSS pixels at a scale of 100%. (There are corresponding height and device-height values, which may be useful for pages with elements that change size or position based on the viewport height.)

The initial-scale property controls the zoom level when the page is first loaded. The maximum-scale, minimum-scale, and user-scalable properties control how users are allowed to zoom the page in or out.

A pixel is not a pixel

The iPhone and many popular Android phones have 3- to 4-inch (7–10 cm) screens with 320×480 pixels (~160 dpi). Firefox for Maemo runs on the Nokia N900, which has the same physical size but 480×800 pixels (~240 dpi). Because of this, the last version of Fennec displayed many pages about one third smaller (in actual, physical size) than iPhone or Android. This caused usability and readability problems on many touch-optimized web sites. Peter-Paul Koch wrote about this problem in A pixel is not a pixel.

Fennec 1.1 for Maemo will use 1.5 hardware pixels for each CSS “pixel”, following the lead of Android’s WebKit-based browser. This means a page with initial-scale=1 will render at close to the same physical size in Fennec for Maemo, Mobile Safari for iPhone, and the Android Browser on both HDPI and MDPI phones. This is consistent with the CSS 2.1 specification, which says:

If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length.

For web developers, this means that 320px be full width in portrait mode at scale=1, on all of the above-mentioned handheld devices, and they may size their layouts and images accordingly. But remember that not all mobile devices are the same width; you should also make sure that your pages work well in landscape mode, and on larger devices like the iPad and Android tablets.

On 240-dpi screens, pages with initial-scale=1 will effectively be zoomed to 150% by both Fennec and Android WebKit. Their text will be smooth and crisp, but their bitmap images will probably not take advantage of the full screen resolution. To get sharper images on these screens, web developers may want to design images – or whole layouts – at 150% of their final size (or 200%, to support the rumored 320-dpi iPhone) and then scale them down using CSS or viewport properties.

Right now Fennec uses the same default ratio of 1.5 on all devices. (It’s a hidden preference that can be changed in about:config or by an add-on.) Later we’ll need to change this – as well as many other parts of Fennec’s user interface – to work correctly on screens with different pixel densities. Note that the default ratio of 1.5 is true only when the viewport scale equals 1. Otherwise, the relationship between CSS pixels and device pixels depends on the current zoom level.

Viewport width and screen width

Many sites set their viewport to "width=320, initial-scale=1" to fit precisely onto the iPhone display in portrait mode. As mentioned above, this caused problems when Fennec 1.0 endered these sites, especially in landscape mode. To fix this, Fennec 1.1 will expand the viewport width if necessary to fill the screen at the requested scale. This matches the behavior of Android and Mobile Safari, and is especially useful on large-screen devices like the iPad. (Allen Pike’s Choosing a viewport for iPad sites has a good explanation for web developers.)

For pages that set an initial or maximum scale, this means the width property actually translates into a minimum viewport width. For example, if your layout needs at least 500 pixels of width then you can use the following markup. When the screen is more than 500 pixels wide, the browser will expand the viewport (rather than zoom in) to fit the screen:

<meta name="viewport" content="width=500, initial-scale=1"/>

Fennec 1.1 also adds support for minimum-scale, maximum-scale, and user-scalable, with defaults and limits similar to Safari’s. These properties affect the initial scale and width, as well as limiting changes in zoom level.

Mobile browsers handle orientation changes slightly differently. For example, Mobile Safari often just zooms the page when changing from portrait to landscape, instead of laying out the page as it would if originally loaded in landscape. If web developers want their scale settings to remain consistent when switching orientations on the iPhone, they must add a maximum-scale value to prevent this zooming, which has the sometimes-unwanted side effect of preventing users from zooming in:

 name="viewport" content="initial-scale=1, maximum-scale=1">

This is not necessary in Fennec; when the device changes orientation, Fennec updates the viewport size, the page layout, and JavaScript/CSS properties like device-width, based on its new “window” dimensions.

Standards

There is clearly demand for the viewport meta tag, since it is supported by most popular mobile browsers and used by thousands of web sites. It would be good to have a true standard for web pages to control viewport properties. According to the HTML5 spec, extensions to the meta element should first be registered on the WHATWG wiki and then go through the W3C standards process. If this happens, then we at Mozilla will work to make sure we can implement any changes made during standardization.

Firefox, YouTube and WebM

Christopher Blizzard — Wed, 19 May 2010 16:24:23 +0000

Five important items of note today relating to Mozilla’s support for the VP8 codec:

1. Google will be releasing VP8 under an open source and royalty-free basis. VP8 is a high-quality video codec that Google acquired when they purchased the company On2. The VP8 codec represents a vast improvement in quality-per-bit over Theora and is comparable in quality to H.264.

2. The VP8 codec will be combined with the Vorbis audio codec and a subset of the Matroska container format to build a new standard for Open Video on the web called WebM. You can find out more about the project at its new site: http://www.webmproject.org/.

3. We will include support for WebM in Firefox. You can get super-early WebM builds of Firefox 4 pre-alpha today. WebM will also be included in Google Chrome and Opera.

4. Every video on YouTube will be transcoded into WebM. They have about 1.2 million videos available today and will be working through their back catalog over time. But they have committed to supporting everything.

5. This is something that is supported by many partners, not just Google and others. Content providers like Brightcove have signed up to support WebM as part of a full HTML5 video solution. Hardware companies, encoding providers and other parts of the video stack are all part of the list of companies backing WebM. Even Adobe will be supporting WebM in Flash. Firefox, with its market share and principled leadership and YouTube, with its video reach are the most important partners in this solution, but we are only a small part of the larger ecosystem of video.

We’re extremely excited to see Google joining us to support Open Video. They are making technology available on terms consistent with the Open Web and the W3C Royalty-Free licensing terms. And – most importantly – they are committing to support a full open video stack on the world’s largest video site. This changes the landscape for video and moves the baseline for what other sites have to do to maintain parity and keep up with upcoming advances in video technology, not to mention compatibility with the set of browsers that are growing their userbase and advancing technology on the web.

At Mozilla, we’ve wanted video on the web to move as fast as the rest of the web. That has required a baseline of open technology to build on. Theora was a good start, but VP8 is better. Expect us to start pushing on video innovation with vigor. We’ll innovate like the web has, moving from the edges in, with dozens of small revolutions that add up to something larger than the sum of those parts. VP8 is one of those pieces, HTML5 is another. If you watch this weblog, you can start to see those other pieces starting to emerge as well. The web is creeping into more and more technologies, with Firefox leading the way. We intend to keep leading the web beyond HTML5 to the next place it needs to be.

Today is a day of great change. Tomorrow will be another.

Getting involved with Account Manager

Dan Mills — Thu, 13 May 2010 23:01:23 +0000

It’s been a couple of weeks since we originally posted about Account Manager and we’ve gotten a lot of feedback. We’ve got a few opportunities for people to get more involved with the project, listed below.

Join us at the Account Manager Meet-up or at IIW

We are hosting an Account Manager Meet-up on Friday, May 21st at Mozilla’s Mountain View Headquarters. This meetup will be an excellent opportunity to give your feedback on the draft specification as we prepare to finalize it. So, if you are a web developer, sysadmin, protocol or security expert, RSVP here.

The summit will be from 1PM to 4PM followed by a “cantina” during which you’ll get a chance to meet with other Mozilla developers over informal drinks and snacks.

We’ll also be presenting at the Internet Identity Workshop next week; if you are planning on attending IIW look for the Account Manager talk and come and say hello!

Browser-assisted registration

Another way to help out is to add reigistration support to your site. The latest version of the Account Manager add-on adds support for a basic registration flow, and we’re very interested in finding out what the Web development community thinks about it. Here’s what you need to do:

Add a snippet to the username-password-form profile in your AMCD:

"register": {
    "method": "POST",
    "path": "/register-endpoint",
    "id-type": "email"
}

Then you need to add a method at /register-endpoint which will receive the user id and secret as POST parameters. Your method should return 200 if the id and secret are OK, otherwise return 400 with a snippet of JSON (see the spec for details and examples).

You might need to change your content to accomodate this new model: after you return 200 the expectation is that there is a username+password pair which is valid, even though it might map to a disabled account. For example, if you need to ask for additional information, have the user solve a captcha, or require email verification, simply keep the account disabled until those additional requirements have been met.

Addressing cross-site request forgeries

Based on feedback from the community, we’ve been investigating several possibilities for preventing CSRF attacks with Account Manager. In addition to supporting CSRF tokens, the latest proposal leverages headers to achieve the same goal with fewer requests and without a session cookie. Interested? Join the discussion on our forum.

Join us online

Join our online community, visit the Account Manager feature page to learn more about Account Manager, and to subscribe to our mailing list/forum.

If you add support for Account Manager to your site, please add yourself to the the wiki page for early Account Manager sites.

Firefox 4: the HTML5 parser – inline SVG, speed and more

Christopher Blizzard — Tue, 11 May 2010 15:55:26 +0000

This is a guest post from Henri Sivonen, who has been working on Firefox’s new HTML5 parser. The HTML parser is one of the most complicated and sensitive pieces of a browser. It controls how your HTML source is turned into web pages and as such changes to it are rare and need to be well-tested. While most of Gecko has been rebuilt since its initial inception in the late 90s, the parser was one of the stand-outs as being “original.” This replaces that code with a new parser that’s faster, compliant with the new HTML5 standard and enables a lot of new functionality as well.

A project to replace Gecko’s old HTML parser, dating from 1998, has been ongoing for some time now. The parser was just turned on by default on the trunk, so you can now try it out by simply downloading a nightly build without having to flip any configuration switch.

There are four main things that improve with the new HTML5 parser:

You can now use SVG and MathML inline in HTML5 pages, without XML namespaces.
Parsing is now done off Firefox’s main UI thread, improving overall browser responsiveness.
It’s improved the speed of innerHTML calls by about 20%.
With the landing of the new parser we’ve fixed dozens of long-standing parser related bugs.

Try the demo with a Firefox Nightly or another HTML5-ready browser. It should look like this:

What Is It?

The HTML5 parser in Gecko turns a stream of bytes into a DOM tree according to the HTML5 parsing algorithm.

HTML5 is the first specification that tells implementors, in detail, how parse HTML. Before HTML5, HTML specifications didn’t say how to turn a stream of bytes into a DOM tree. In theory, HTML before HTML5 was supposed to be defined in terms of SGML. This implied a certain relationship between the source of valid HTML documents and the DOM. However, parsing wasn’t well-defined for invalid documents (and Web content most often isn’t valid HTML4) and there are SGML constructs that were in theory part of HTML but that in reality popular browsers didn’t implement.

The lack of a proper specification led to browser developers filling in the blanks on their own and reverse engineering the browser with the largest market share (first Mosaic, then Netscape, then IE) when in doubt about how to get compatible behavior. This led to a lot of unwritten common rules but also to different behavior across browsers.

The HTML5 parsing algorithm standardizes well-defined behavior that browsers and other applications that consume HTML can converge on. By design, the HTML5 parsing algorithm is suitable for processing existing HTML content, so applications don’t need to continue maintaining their legacy parsers for legacy content. Concretely, in the trunk nightlies, the HTML5 parser is used for all text/html content.

How Is It Different?

The HTML5 parsing algorithm has two major parts: tokenization and tree building. Tokenization is the process of splitting the source stream into tags, text, comments and attributes inside tags. The tree building phase takes the tags and the interleaving text and comments and builds the DOM tree. The tokenization part of the HTML5 parsing algorithm is closer to what Internet Explorer does than what Gecko used to do. Internet Explorer has had the majority market share for a while, so sites have generally been tested not to break when subjected to IE’s tokenizer. The tree building part is close to what WebKit does already. Of the major browser engines WebKit had the most reasonable tree building solution prior to HTML5.

Furthermore, the new HTML5 parser parses network streams off the main thread. Traditionally, browsers have performed most tasks on the main thread. Radical changes like off-the-main-thread parsing are made possible by the more maintainable code base of the HTML5 parser compared to Gecko’s old HTML parser.

What’s In It for Web Developers?

The changes mentioned above are mainly of interest to browser developers. A key feature of the HTML5 parser is that you don’t notice that anything has changed.

However, there is one big new Web developer-facing feature, too: inline MathML and SVG. HTML5 parsing liberates MathML and SVG from XML and makes them available in the main file format of the Web.

This means that you can include typographically sophisticated math in your HTML document without having to recast the entire document as XHTML or, more importantly, without having to retrofit the software that powers your site to output well-formed XHTML. For example, you can now include the solution for quadratic equations inline in HTML:

>
  >x>
 
  >=>
  >
    >
      >−>
      >b>
      >±>
      >
        >
 
          >b>
          >2>
        >
        >−>
        >4>
        >⁢>
        >a>
 
        >⁢>
        >c>
      >
    >
    >
      >2>
      >⁢>
      >a>
 
    >
  >
>

Likewise, you can include scalable inline art as SVG without having to recast your HTML as XHTML. As screen sized and pixel densities become more varied, making graphics look crisp at all zoom levels becomes more important. Although it has previously been possible to use SVG graphics in HTML documents by reference (using the object element), putting SVG inline is more convenient in some cases. For example, an icon such as a warning sign can now be included inline instead of including it from an external file.

 height=86 width=90 viewBox='5 9 90 86' style='float: right;'>
   stroke=#F53F0C stroke-width=10 fill=#F5C60C stroke-linejoin=round d='M 10,90 L 90,90 L 50,14 Z'/>
   stroke=black stroke-width=10 stroke-linecap=round x1=50 x2=50 y1=45 y2=75 />
>

Make yourself a page that starts with and put these two pieces of code in it and it should work with a new nightly. In general, if you have a piece of MathML or SVG as XML, you can just copy and paste the XML markup inline into HTML (omitting the XML declaration and the doctype if any). There are two caveats: The markup must not use namespace prefixes for elements (i.e. no svg:svg or math:math) and the namespace prefix for the XLink namespace has to be xlink. In the MathML and SVG snippits above you’ll see that the inline MathML and SVG pieces above are more HTML-like and less crufty than merely XML pasted inline. There are no namespace declarations and unnecessary quotes around attribute values have been omitted. The quote omission works, because the tags are tokenized by the HTML5 tokenizer—not by an XML tokenizer. The namespace declaration omission works, because the HTML5 tree builder doesn’t use attributes looking like namespace declarations to assign MathMLness or SVGness to elements. Instead, establishes a scope of elements that get assigned to the SVG namespace in the DOM and establishes a scope of elements that get assigned to the MathML namespace in the DOM. You’ll also notice that the MathML example uses named character references that previously haven’t been supported in HTML. Here’s a quick summary of inline MathML and SVG parsing for Web authors:

… is assigned to the SVG namespace in the DOM.
… is assigned to the MathML namespace in the DOM.
foreignObject and annotation-xml (an various less important elements) establish a nested HTML scope, so you can nest SVG, MathML and HTML as you’d expect to be able to nest them.
The parser case-corrects markup so works in HTML source.
The DOM methods and CSS selectors behave case-sensitively, so you need to write your DOM calls and CSS selectors using the canonical case, which is camelCase for various parts of SVG such as viewBox.
The syntax opens and immediately closes the foo element if it is a MathML or SVG element (i.e. not an HTML element).
Attributes are tokenized the same way they are tokenized in HTML, so you can omit quotes in the same situations where you can omit quotes in HTML (i.e. when the attribute value is not the empty string and does not contain whitespace, ", ‘, `, <, =, or >).
Warning: the two above features do not combine well due to the reuse of legacy-compatible HTML tokenization. If you omit quotes on the last attribute value, you must have a space before the closing slash. is OK but is not.
Attributes starting with xmlns have absolutely no effect on what namespace elements or attributes end up in, so you don’t need to use attributes starting with xmlns.
Attributes in the XLink namespace must use the prefix xlink (e.g. xlink:href).
Element names must not have prefixes or colons in them.
The content of SVG script elements is tokenized like they are tokenized in XML—not like the content of HTML script elements is tokenized.
When an SVG or MathML element is open …]]> sections work the way they do in XML. You can use this to hide text content from older browsers that don’t support SVG or MathML in text/html.
The MathML named characters are available for use in named character references everywhere in the document (also in HTML content).
To deal with legacy pages where authors have pasted partial SVG fragments into HTML (who knows why) or used a tag for non-MathML purposes, attempts to nest various common HTML elements as children of SVG elements (without foreignObject) will immediately break out of SVG or MathML context. This may make some typos have surprising effects.



Revitalizing Caching
Arun Ranganathan — Mon, 03 May 2010 19:42:51 +0000
Apparently, there are only two hard problems in computer science: cache invalidation and the naming of things (or so Phil Karlton’s dictum goes).  Earlier this month, we invited representatives of Twitter, Facebook, SproutCore, Palm’s webOS, Microsoft’s “Office On The Web”, Yahoo, and Google to talk to us about the former problem (amongst other things), though we also learned something about the latter.
Caching is an important issue to get right on the web, not least of all because of the proliferation of web applications on mobile devices.  The goals of our caching summit were to identify use cases that would help us move forward with caching and with HTTP request efficiency. How desirable was rolling up our sleeves to look at HTTP/1.1 Pipelining in Firefox, for instance?  What else was needed at the HTTP layer?  And was the vaunted HTML5 AppCache, implemented in Firefox 3.5 onwards, actually useful to developers?  What else needed to be exposed to web applications, either within content or via additional headers? 
Developer feedback is invaluable, and is increasingly the basis of how we want to evolve the next integral pieces of the web platform.  Web developers are one of our primary constituencies; going forward, we want them to help us prioritize what we should implement, and what we need to focus on with respect to web standards.  We chose our attendees wisely; if any group of people could talk about web applications at scale, the current performance of the cache, and their wishlist for future browser caching behavior on the web platform, it was this group of people.  And the feedback they gave us was copious and useful — our work is cut-out for us.  Notably, we’ve got a few actions we’re going to follow-up on: 


Increase the default size of our disk and memory caches.  Firefox’s disk cache is currently set at 50MB, a small-ish number given the amount of disk space available on hardware currently (and although this limit can be increased using advanced preferences, few users actually change the default).   This is low-hanging fruit for us to fix.  An interesting open question is whether we should determine disk cache size heuristically, in lieu of choosing a new upper bound.  Steve Souders, who attended our caching summit, blogs about cache sizes, as well as premature cache evictions.  


Conduct a “Mozilla Test-Pilot” project to get more data about how exactly we cache resources currently.  This is part of a larger question about updating our caching algorithm.  Like other browsers, we use an optimization of the Least Recently Used (LRU) caching algorithm, called LRU-SP.  Data that we would want to gather includes determining what the hit rate, mean, variance and distribution of cached resources are.  What’s the average lifetime? How about different modes where our LRU-SP replacement policy doesn’t work well for certain apps, where big resources (such as an essential script file) may get eliminated before smaller ones (such as map tiles)?  We’ll also have to research the role that anti-virus software plays in routinely flushing out the cache, leading to further occurrences of untimely eviction of relevant resources.


Explore prioritization of resources in the cache based on MIME type.  For instance, allowing for JavaScript (text/javascript) to always get higher priority in terms of what gets pruned by our LRU-SP algorithm.  A good follow-up for this would be to get Chrome, IE, Apple, and Opera to discuss this with us, and then document what we come up with as a MIME-type based “naive” prioritization.  We also want to allow developers to set resource priority on their own, perhaps through a header.  This is likely to be an ongoing discussion. 


Really figure out what hampers the adoption of  HTTP/1.1 Pipelining on the web, including data from proxies and how they purge.  While Pipelining is enabled in Mobile Firefox builds (such at that running on the Nokia N900 and on Android devices) by default, we have it turned off in desktop Firefox builds.  We do this for a variety of reasons, not least of all the risk of performance slow downs if one of the pipelined requests slows down the others.  It’s clear from our discussion that many who attended our caching summit think pipelining will help their applications perform much better.  The situation on the web now with respect to pipelining is a kind of hostage’s dilemma: of the main desktop browsers, nobody has turned on pipelining, for fear of a scenario that slows down performance (leading to that particular browser being accused of “being slow”).  The developers who visited us threw down the proverbial gauntlet;  at a minimum we’ve got to figure out what hamstrings the use of pipelining on the web, and determine what we can actually do to remove those obstacles.


Figure out how to evolve the HTML5 AppCache, which frankly hasn’t seen the adoption we initially expected.  While we tend to view parts of HTML5 such as Cache Manifests and window.applicationCache as yet another performance tool (to ensure web applications rapidly load upon subsequent accesses), it is different than the general browser cache.  What’s in a name, and why is naming something amongst the hardest problems in computer science?  The use of the word “cache” to describe the parts of HTML5 that deal with offline web applications has confused some developers.  What we’re calling the HTML5 AppCache was primarily conceived of to enable offline web application use, but many applications (such as those built with SproutCore) treat it as an auxiliary cache, to ensure that applications have a rapid start-up time and generally perform well.  Why, we were asked, should we have two things: a general purpose browser cache, and something else, uniquely for offline usage?  On the one hand, the HTML5 AppCache allows web apps to act like native apps (enabling “rapid-launch icons” on some mobile handsets), perhaps even eventually integrating with native application launchers.  And on the other hand, the HTML5 AppCache’s separateness from the general cache may mean that we coin different APIs to work with the general cache.  In general, simultaneously evolving multiple APIs with “cache” in the name may be confusing.  But that’s why naming is amongst the hard problems, and that’s why we have to architect the next iteration mindful of the potential for both redundancy as well as confusion. 

We’ve got a tracking bug in place with a bold moniker: “Improve HTTP Cache.”  You’ll see the gamut of changes we’d like to introduce here, including benchmarking our cache against Chromium’s (and perhaps just using Chromium’s cache code, if we need to). 
Caching is important, but difficult.  It would be fair to describe most of the near-term evolution of the web that way, whether that is the introduction of an indexable database capability, streaming video, or new layout models within CSS.  These evolutions won’t necessarily happen within a standards body or on a listserv, but rather through rapid prototyping and meaningful feedback.  That’s why we have to talk to web developers to help us do the right thing, and that’s why we’ll keep organizing meet-ups such as the recent caching summit.



WebSockets in Firefox
Christopher Blizzard — Wed, 28 Apr 2010 17:11:19 +0000
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:
Low-complexity
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.
Low-latency
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.



The CSS 3 Flexible Box Model
Paul Rouget — Thu, 22 Apr 2010 16:43:31 +0000
This article about the Flexible Box Layout was written by Jérémie Patonnier, French open Web enthusiast.
The flexible box model
CSS 3 introduces a brand new box model in addition of the traditional box model from CSS 1 and 2. The flexible box model determines the way boxes are distributed inside other boxes and the way they share the available space.
You can see the specification here.
This box model is similar to the one used by XUL (the user interface language used by Firefox). Some others languages use similar box models such as XAML or GladeXML.
Usually the flexible box model is exactly what you need if you want to create fluid layouts which adapt themselves to the size of the browser window or elastic layouts which adapt themselves to the font size.
In this article, all my examples are based on the following HTML code:

<body>
  <div id="box1">1</div>
  <div id="box2">2</div>
  <div id="box3">3</div>
</body>

Distributing boxes: so what?
By default, the traditional CSS box model distributes boxes vertically depending on the HTML flow. With the flexible box model, it’s possible to specify the order explicitly. You can even reverse it. To switch to the flexible box model, set the property display to the value box (or inline-box) on a box which has child boxes.

display: box;

Horizontal or vertical distribution
The box-orient property lets you specify the distribution axis. vertical and horizontal values define how boxes are displayed. Other values (inline-axis and block-axis) have the same effect, but also let you define the baseline alignment itself (basically the boxes are treated like “inline” boxes).

body{
  display: box;
  box-orient: horizontal;
}


Reversed distribution
The property box-direction allows you to set the order in which the boxes appear. By default–when you simply specify the distribution axis–the boxes follow the HTML flow and are distributed from top to bottom if you are using a vertical axis and from left to right if you are using a horizontal axis. By setting box-direction to reverse, you can reverse the boxes’ distribution order. It acts as if you actually reversed the order of the elements in the HTML.
Be careful with this property because it changes the way some other properties work, which can produce some unexpected behavior.

body {
  display: box;
  box-orient: vertical;
  box-direction: reverse;
}


Explicit distribution
The property box-ordinal-group lets you specify the order in which the boxes will be distributed. This is the ultimate customization opportunity, because you can define the order you want, regardless of the HTML flow order. Those groups are defined by a number starting at 1 (which is the default value). So the box model will first distribute those groups, then all the boxes inside each group. The distribution occurs from the lowest value (the group numbered 1) to the highest (the groups numbered 2 and above).

body {
  display: box;
  box-orient: vertical;
  box-direction : reverse;
}
#box1 {
  box-ordinal-group: 2;
}
#box2 {
  box-ordinal-group: 2;
}
#box3 {
  box-ordinal-group: 1;
}


And what about flexibility?
If changing the natural HTML flow order is huge, the real fun begins when you start to deal with the available space.
Box sizing
By default, a box is not flexible. It becomes flexible only if it has the property box-flex with a value of at least 1.
If a box is not flexible, it will be as wide as possible to make its content visible without any overflow. Its size can be forced with the properties width and height (or their min-*, and max-* alternatives).
If a box is flexible, its size will be computed as follows:

The explicit size declarations (width, height, min-* and max-*)
The size of the parent box and all the remaining available inner space.

So, if the boxes haven’t any size declarations, their sizes will fully depend on their parent box’s size. It will work like this: the size of box is equal to the size of its parent multiplied by the value of the its box-flex property divided by the sum of all the box-flex properties values of all boxes included in its parent.
On the other hand, if one or more boxes have an explicit size statements, the size of all those boxes is computed and all the flexible boxes share the remaining available space on the same principle as above.
It probably sounds a bit tricky, but with some examples it will become easier.
All boxes are flexible
In the next example, box 1 is twice the size of box 2 and box 2 has the same size as box 3. It looks the same as using percentages to set the boxes’ sizes. But there is a big difference. If you add a box, you don’t need to recalculate its size. With the flexible box model, each time you add a box, all the others automatically shrink to make room for the new one.

body {
  display: box;
  box-orient: horizontal;
}
#box1 {
  box-flex: 2;
}
#box2 {
  box-flex: 1;
}
#box3 {
  box-flex: 1;
}


Some boxes have a fixed size
In the next example, box 3, which is not flexible, is 160px in width. In this case, there’s 240px of free space available for boxes 1 and 2. So, box 1 will be 160px in width (240px x 2/3) and box 2 will be 80px in width (240px x 1/3). If you wish, you can make box 3 flexible as well. In this case the way the size of this box is computed will be almost the same as with the property min-width.

body {
  display: box;
  box-orient: horizontal;
  width: 400px;
}
#box1 {
  box-flex: 2;
}
#box2 {
  box-flex: 1;
}
#box3 {
  width: 160px;
}


Managing overflow
Because we can mix flexible boxes, inflexible boxes, and flexible boxes which have preset sizes, It’s possible for the sum of all the boxes’ sizes to be larger or smaller than the parent box size. So you can have too much space or not enough.
I have too much space available; what do I do?
The available space gets distributed depending on the properties box-align and box-pack
The property box-pack manages the way the space is distributed on the horizontal axis and can have one of four possible values: start, end, justify, or center

start: All the boxes are on the left side of the parent box and all the remaining space is on the right side.
end: All the boxes are on the right and the remaining space is on the left
justify: The available space is divided evenly in-between each boxes
center: The available space is divided evenly on each side of the parent box

The property box-align manages the way the space is distributed on the vertical axis and can have one of five values: start, end, center, baseline, and stretch

start: The top edge of each box is placed along the top of the parent box and all the remaining space is placed below.
end: The bottom edge of each box is placed along the bottom of the parent box and all the remaining space is placed above.
center: The available space is divided evenly and placed half above and half below.
baseline: All children are placed with their baselines aligned and the remaining space is placed before or after as necessary (This is a simplification about how this value really works, but you see the point).
stretch: The height of each boxes is adjusted to fit the parent box height

A warning about how those properties work: they are strongly influenced by the use of the properties box-orient and box-direction. They can cause some unexpected behavior (for example, the behavior of values start and end could be fully reversed). I hope that once the specification is finalized, we’ll have more information about how those properties work together.

body {
  display: box;
  box-orient: horizontal;
  /* The content of the body is horizontally centered */
  box-pack: center;
  /* and vertically as well ... \o/ */
  box-align: center;
  width: 100%;
  height : 100%;
}


What happens if I don’t have enough space?
Just like with the traditional box model, the overflow property lets you to define the way it’s managed. No surprise here.
However, you must be careful here too. Indeed, the use of the properties box-orient and box-direction can mess it up. For example, you can see elements overflowed to the right instead of the left or to the top instead of the bottom. Take the time to experiment before trying to use it on a big project or you could go mad.
You can also avoid overflow by making the boxes run over multiple lines (or columns, depending on the orientation) by setting the property box-lines to multiple.
Okay, cool, but does it work in real life?
Yes it does! Both Gecko and WebKit have vendor-prefixed implementations of a box model (Note: The current state of the specification does not reflect Mozilla’s or WebKit’s implementation). This means that Firefox, Safari, Chrome, and any browsers that use one of those rendering engines are able to use the features described in this article. If you use one of those awesome browsers, here is a little demo of the flexible box model in action.
If you’re not using a browser implementing a box model, this screenshot shows you what it looks like:

To conclude
You can start to use this box model to layout your HTML documents with modern web browsers. Be careful though, it’s the really first iteration of a W3C Working Draft. There will certainly be some changes. Anyway, the implementations available in Gecko and Webkit are extremely consistent and mature, so if there are changes, they should not be that troublesome.
This box model is a very easy and simple way to solve some usual problems in web design (form layout, page footers, vertical centering, disassociation of visual flow from HTML flow, etc.). I strongly suggest you become familiar with it because it could become a standard tool for web designers in the near future (if Microsoft decides to include it in IE, it could become so very fast).
What is already available is a good start to play with. But at this point, the way the traditional box model and the flexible box model interact is not very clear (for example, it’s impossible to use position:relative with the properties left or top on a box which uses the property box-ordinal-group). This will be improved, but don’t be surprised if your work habits are somewhat undermined. Another tricky point: the way all the properties relative to this new box model interact can be sometimes really confusing. This should remind you of the day you discovered the float property. ;)
For further information

Shawn J. Goff: CSS3 Flexible Box Layout Module
CSS3.info: Introducing the flexible box layout module
W3C: Flexible Box Layout Module




mozilla developer preview 4 ready for testing
Christopher Blizzard — Mon, 12 Apr 2010 18:41:01 +0000
Note: this is a re-post of the entry in the Mozilla Project Development Weblog.  There’s some juicy stuff in here for Web Developers that need testing.  In particular, this is the first build with the CSS history changes.
As part of our ongoing platform development work, we’re happy to announce the fourth pre-release of the Gecko 1.9.3 platform.  Gecko 1.9.3 will form the core of Firefox and other Mozilla project releases.
It’s available for download on Mac, Windows or Linux.
Mozilla expects to release a Developer Preview every 2-3 weeks. If you’ve been running a previous release, you will be automatically updated to the latest version when it is released. 
This preview release contains a lot of interesting stuff that’s worth pointing out, and contains many things that were also in previous releases.  Here are the things of note in this release:
User Interface Changes

Open tabs that match searches in the Awesomebar now show up as “Switch to Tab.”
This is the first preview release to contain resizable text areas by default.

Web Developer Changes

This is the first preview release to contain changes to CSS :visited that prevent a large class of history sniffing attacks.  You can find more information about the details of why this change is important over on the hacks post on the topic and on the Mozilla Security Weblog.  Note that this change is likely to break some web sites and requires early testing – please test if you can.

SVG Attributes which are mapped to CSS properties can now be animated with SMIL.  See the bug or a demo.


Plugins


Out of process plugins support for Windows and Linux continues to improve.  This release contains many bug fixes vs. our previous developer preview releases.  (In fact, it’s good enough that we’ve ported this code back to the 3.6 branch and have pushed that to beta for a later 3.6.x release.)
This is the first release that contains support for out of process plugins for the Mac.  If you are running OSX 10.6 and you’re running the latest Flash beta, Flash should run out of process

Performance

One area where people complained about performance was restart performance when applying an update.  It turns out that a lot of what made that experience poor wasn’t startup time, it was browser shutdown time.  We’ve made a fix since the last preview release that made a whopping 97% improvement in shutdown time.  (That’s not a typo, it’s basically free now.)
Our work to reduce the amount of I/O on the main thread continues unabated.  This preview release will feel much snappier than previous snapshots, and feel much faster than Firefox 3.6.
We continue to add hardware acceleration support.  If you’re on Windows and you’ve got decent OpenGL 2 drivers, open video will use hardware to scale the video when you’re in full screen mode.  For large HD videos this can make a huge difference in the smoothness of the experience and how much power + CPU are used.  We’ll be adding OSX and Linux support at some point in the future as well, but we’re starting with Windows.
We continue to make improvements and bug fixes to our support for Direct2D.  (Not enabled by default.  If you want to turn it on see Bas’ post.)  If you’re running Alpha 4 on Windows Vista or Windows 7, and you’ve turned on D2D, try running this stress test example in Alpha 4 vs. Firefox 3.6.  The difference is pretty amazing.  You can also see what this looks like compared to other browsers in this this video.  (Thanks to Hans Schmucker for the video and demo.)


Platform


JS-ctypes, our new easy-to-use system for extension authors who want to call into native code now has support for complex types: structures, pointers, and arrays.  For more information on this, and how easy it can make calling into native code from JavaScript, see Dan Witte’s post.
Mozilla is now sporting an infallible allocator.  What is this odd-sounding thing, you ask?  It’s basically an allocator that when memory can’t be allocated it aborts instead of returning NULL.  This reduces the surface area for an entire class of security bugs related to checking NULL pointers, and also allows us to vastly simplify a huge amount of Gecko’s source code.

Mozilla Hacks - the Web developer blog » Standards

CSS 3D transformations in Firefox Nightly

More details about the WebAPI effort

Goal

Security and Privacy

Standards

High Level vs. Low Level

How you can join

Hiring developers

Introducing WebAPI

The current situation

What is WebAPI?

Contribute

Hiring developers

Accessibility and web innovation – a constant struggle

Multimedia on the web and using HTML5 sensibly

Multimedia on the web

Using HTML5 sensibly

Notes on “Using HTML5 sensibly”

People of HTML5 – Remy Sharp

The video interview

Ten questions about HTML5 for Remy Sharp

1) Reading “Introducing HTML5″ it seems to me that you were more of the API – focused person and Bruce the markup guy. Is that a fair assumption? What is your background and passion?

2) From a programmer’s point of view, what are the most exciting bits about the HTML5 standard? What would you say is something every aspiring developer should get their head around first?

3) In your book you wrote a nice step-by-step video player for HTML5 video. What do you think works well with the Video APIs and what are still problems that need solving?

4) Let’s talk a bit about non-HTML5 standards, like Geolocation. I understand you did some work with that and found that some parts of the spec work well whilst others less so. Can you give us some insight?

6) What about performance? Aren’t large Canvas solutions very slow, especially on mobile devices? Isn’t that a problem for gaming? What can be done to work around that?

9) Where would you send people if they want to learn about HTML5? What are tutorials that taught you a lot? Where should interested people hang out?

10) You have announced that you are concentrating on building a framework to make Websockets easy to work with. How is that getting on and what do you see Websockets being used for in the future? In other words, why the fascination?

A call for quality HTML5 demo markup

The two faces of HTML5 enthusiasm

Bla bla bla… C’mon Chris, it isn’t that bad!

Simulating a navigation list

Click (probably) here for functionality

Reasons and effects

Delivering the good message of local storage

Firefox 4: HTML5 Forms

New input field types

New input attributes

Autofocus

Placeholder

Decoupled forms

form attribute

Form options on fields

Validation mechanisms

required

url

email

pattern

The constraint validation API

New CSS selectors

:required, :optional

:valid, :invalid

:-moz-placeholder

Conclusion

HTML5 Video preload attribute supported in Firefox 4, autobuffer attribute removed

Firefox 4: An early walk-through of IndexedDB

Example 1 – Opening and Setting Up a Database

Example 2 – Storing Kids in the Database

Example 3 – List All Kids

Example 4 – List Kids Who Bought Candy

Beyond HTML5: Database APIs and the Road to IndexedDB

SQL? Which SQL?

The Benefits and Pitfalls of SQLite

Aesthetics and Web Developers

Links

upcoming changes to the viewport meta tag for firefox mobile

Background

Viewport basics

A pixel is not a pixel

Viewport width and screen width

Standards

Firefox, YouTube and WebM

Getting involved with Account Manager

Firefox 4: the HTML5 parser – inline SVG, speed and more

Revitalizing Caching

WebSockets in Firefox

The CSS 3 Flexible Box Model

The flexible box model

Distributing boxes: so what?

`:required`, `:optional`

`:valid`, `:invalid`

`:-moz-placeholder`