Standards Articles

Sort by:


  1. experimenting with HTML5 video at the BBC

    The BBC has a post up describing an experiment that they have put together that uses HTML5 video that works in Firefox 3.5 and Safari.

    BBC HTML5 Video Experiment

    The demo uses jQuery and drives a simple carousel that shows the current chapter as the video plays. It also shows subtitles as the video plays.

    One really great, and somewhat subtle thing about this experiment? You can select the subtitles. They are just text.

  2. taming long words with word-wrap

    This post is from Les Orchard, who works on Mozilla’s web development team.

    Web browsers have a long history of sharing features between them. The word-wrap CSS property is a feature that originally came from Microsoft and is included in CSS3.

    Now available in Firefox 3.5, this CSS property allows the browser to arbitrarily break up long words or strings of characters to fit within a given element.

    How is this helpful? Well, have you ever had to display an extremely long URL or block of data on a page? Sure, URL shortening services have helped, but the basic layout issue still remained.

    Consider the following URL using the data scheme:

    Presented in a <textarea>, this huge URL behaves well enough to at least not break the layout of this page. But, it’s not really handled all that gracefully beyond that. Most browsers don’t quite know what to do with the scrollbar, styling is a pain, and presenting the URL in an editable field isn’t really the intent here.

    Alternatively, you could stuff the URL into a <div> and slap an overflow: hidden style on it, like so:

    Again, the page layout isn’t broken, but now the URL is cut off. So, why not try an overflow: auto style instead?

    This will give you a scrollbar, at least:


    But now, visitors to your page have to scroll to see the whole
    thing, and highlighting the text for copy & paste can be

    So, finally, here’s the word-wrap: break-word payoff:


    See the difference for yourself: Use the radio buttons above to switch between the values normal (the default) and break-word. The normal value will cause the URL to spill out of the containing <div>, possibly breaking the layout of this page.

    On the other hand, using word-wrap: break-word will allow the browser to coerce the text into the confines of the <div>, thus preserving your page layout and quite possibly your sanity.

  3. Multimedia on the web and using HTML5 sensibly

    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 or embedded here:

    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

    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:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "">
    <html lang="en">
      <meta http-equiv="Content-Type" 
            content="text/html; charset=UTF-8">  
      <title>HTML - c'est moi!</title>
      <link rel="stylesheet" type="text/css"
      <script type="text/javascript" src="magic.js">
      <h1>Heading! Everybody duck!</h1>
      <p>I am content, hear me roar!</p>
      <p class="footer">By me!</p>

    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:

    <!DOCTYPE html>  
    <html lang="en">
      <meta charset="utf-8">  
      <title>HTML5, c'est moi, ou HTML...</title>
      <link rel="stylesheet" href="styles.css">
      <script src="magic.js"></script>
      <h1>Heading! Everybody duck!</h1>
      <p>I am content, hear me roar!</p>
      <p class="footer">By me!</p>

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

    <!DOCTYPE html>  
    <html lang="en">
      <title>HTML5, c'est moi, ou HTML...</title>
      <link rel="stylesheet" href="styles.css">
      <script src="magic.js"></script>
      <header><h1>Heading! Everybody duck!</h1></header>
        <p>I am content, hear me roar!</p>
      <footer><p>By me!</p></footer>

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

    <!DOCTYPE html>  
    <html lang=en>
      <TITLE>HTML5, c'est moi, ou HTML...</title>
      <LINK rel=stylesheet href=styles.css>
      <script src=magic.js></SCRIPT>
      <HEADER><h1>Heading! Everybody duck!</h1></header>
        <p>I am content, hear me roar!</p>
      <footer><p>By me!</p></FOOTER>

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

    <!DOCTYPE html>  
    <html lang="en"><head>  
      <title>HTML5, c'est moi, ou HTML...</title>
      <link rel="stylesheet" href="styles.css">
      <script src="magic.js"></script>
      <header><h1>Heading! Everybody duck!</h1></header>
        <p>I am content, hear me roar!</p>
      <footer><p>By me!</p></footer>

    However, if we were to omit the closing </p> tag in the <section> the generated code looks different:

    <!DOCTYPE html>
    <html lang="en"><head>  
      <title>HTML5, c'est moi, ou HTML...</title>
      <link rel="stylesheet" href="styles.css">
      <script src="magic.js"></script>
      <header><h1>Heading! Everybody duck!</h1></header>
        <p>I am content, hear me roar!
        <p>By me!</p>

    As you can see, the <footer> got moved into the paragraph inside the section. Why? Who knows? The issue is that we ask a browser to make an educated guess for us and as a browser doesn’t understand semantics, this is what we get.

    Which leads me to a few questions we need to ask and find the answer to:

    • Can innovation be based on “people never did this correctly anyways”?
    • Is it HTML or BML? (HyperText Markup Language or Browser Markup Language)
    • Should HTML be there only for browsers? What about conversion Services? Search bots? Content scrapers?

    The next issue I wanted to discuss is legacy browsers which seems to be a euphemism for IE6. The issue with IE6 is that when you use the new semantic HTML elements exclusively then they can’t be styled in this browser. By using the correct new syntax that should bring us a lot of benefits you condemn older browser users to see unstyled documents.

    There are a few ways around this. The first one requires JavaScript – if you create the element using the DOM first you can style it in IE:

    <!DOCTYPE html>
    <html lang="en">
      <meta charset="utf-8">

    This technique has been wrapped up nicely in a script called HTML5 shiv by Remy Sharp. Of course, this means that you make markup dependent on JavaScript to work which is not what markup is about, according to purists of the web. You can work around that dependency in a few ways. You can write HTML5 as XHTML, you can use conditional comments or a namespace or you can use both the new semantic elements and DIVs with a class around them to please all browsers:

    <!DOCTYPE html>
    <html lang="en">
      <head><meta charset="utf-8">
        <title>HTML5, c'est moi, ou HTML...</title>
        <link rel="stylesheet" href="styles.css">
        <script src="magic.js"></script>
        <style type="text/css" media="screen">
      <div class="header"><header>
        <h1>Heading! Everybody duck!</h1>
      <div class="section"><section>
        <p>I am content, hear me roar!</p>
      <div class="footer"><footer>
        <p>By me!</p>

    This seems to be the most pragmatic solution but is a lot of extra effort.

    The main issue is that not only legacy browsers are failing to support HTML5 properly which is why people tend to use a library like Modernizr to check for HTML5 support before applying it. Modernizr adds classes to the HTML element after checking what the current browser supports and thus gives you handles to use in progressive enhancement. All the hacks and fixes are also bundled in HTML5 Boilerplate, including server settings and ways to make legacy browsers behave. In essence, the much smaller Vanilla HTML5 markup becomes a lot of code again if you test it in the real world.

    If you also want to use all the cool new JavaScript APIs you can use Polyfills to make legacy browsers do something with the code you write.

    Which leads to more questions we need to answer:

    • Should we shoe-horn new technology into legacy browsers?
    • Do patches add complexity as we need to test their performance? (there is no point in giving an old browser functionality that simply looks bad or grinds it down to a halt)
    • How about moving IE fixes to the server side? Padding with DIVs with classes in PHP/Ruby/Python after checking the browser and no JS for IE?

    The last feature of HTML5 I want to talk about is Video and Audio. Again, there is much more complexity than meets the eye:

    Tecnically, embedding an HTML5 video should be as simple as this:

    <video src="interview.ogv" controls>
      <a href="interview.ogv">Download the video</a>

    Once you consider all the different formats needed for different browsers though it becomes a lot more work:

    <video controls>
      <source src="interview.mp4" type="video/mp4">
      <source src="interview.webm" type="video/webm">
      <source src="interview.ogv" type="video/ogg">
      <p>Download the 
        <a href="interview.mp4">video in MP4 format</a>.

    The reason is intellectual property, legal codec battles and implementation of video in different browsers and platforms. In essence, you need to provide the video in three formats. Of course when there is a need then some company will come up with a solution. is a service by that provides you with a single URL that sends the video in the right format to the device you use. All in all they create 28 different formats for you to cater for all kind of mobiles and browsers.

    The other big issue with HTML5 video is that there is no protection from downloading the videos. This is as intended but a big problem when it comes to premium content on the web. As discussed in the comments of this post by Adobe publishers want to have a way to stop people from downloading and reusing their videos but instead just want their audience to watch them in a closed environment.

    All in all there are a few questions to answer when it comes to HTML5 video:

    • Can we expect content creators to create video in many formats to support an open technology?
    • Can a service like be trusted for content creation and storage?
    • Is HTML5 not applicable for premium content?

    In the end, I want every developer and designer out there to take a stand and demand answers to these questions. There is no point in just saying “that’s how it is”. When we keep our technologies closed and when we rely on scripting to make web sites work we do break the web in the long run. The current debate about hashbangs for links shows this.

    Everybody can take part in the HTML5 working group and add documentation to MDN – time to get to work.

  4. css transforms: styling the web in two dimensions

    One feature that Firefox 3.5 adds to its CSS implementation is transform functions. These let you manipulate elements in two dimensional space by rotating, skewing, scaling, and translating them to alter their appearance.

    I’ve put together a demo that shows how some of these functions work.

    There are four animating objects in this demo. Let’s take a look at each of them.

    Rotating the Firefox logo

    On the left, we see the Firefox logo in a nice box, happily spinning in place. This is done by periodically setting the rotation value of the image object, whose ID is logoimg, like this:

      var logo = document.getElementById("logoimg");
      logoAngle = logoAngle + 2;
      if (logoAngle >= 360) {
        logoAngle = logoAngle - 360;
      var style = "-moz-transform: rotate(" + logoAngle + "deg)";
      logo.setAttribute("style", style);

    Every time the animation function is run, we rotate it by 2° around its origin by constructing a style string of the form -moz-transform: rotate(Ndeg).

    By default, all elements’ origins are at their centers (that is, 50% along each axis). The origin can be changed using the -moz-transform-origin attribute.

    Skewing text

    We have two examples of skewing in this demo; the first skews horizontally, which causes the text to “lean” back and forth along the X axis. The second skews vertically, which causes the baseline to pivot along the Y axis.

    In both cases, the code to accomplish this animation is essentially identical, so let’s just look at the code for skewing horizontally:

      text1SkewAngle = text1SkewAngle + text1SkewOffset;
      if (text1SkewAngle > 45) {
        text1SkewAngle = 45;
        text1SkewOffset = -2;
      } else if (text1SkewAngle < -45) {
        text1SkewAngle = -45;
        text1SkewOffset = 2;
   = "skewx(" + text1SkewAngle + "deg)";

    This code updates the current amount by which the text is skewed, starting at zero degrees and moving back and forth between -45° and 45° at a rate of 2° each time the animation function is called. Positive values skew the element to the right and negative values to the left.

    Then the element’s transform style is updated, setting the transform function to be of the form skewx(Ndeg), then setting the element’s style.MozTransform property to that value.

    Scaling elements

    The last of the examples included in the demo shows how to scale an element using the scale transform function:

      text3Scale = text3Scale + text3ScaleOffset;
      if (text3Scale > 6) {
        text3Scale = 6;
        text3ScaleOffset = -0.1;
        text3.innerHTML = "It's going away so fast!" = "blue";
      } else if (text3Scale < 1) {
        text3Scale = 1;
        text3ScaleOffset = 0.1;
        text3.innerHTML = "It's coming right at us!"; = "red";
   = "scale(" + text3Scale + ")";

    This code scales the element up and down between its original size (a scale factor of 1) and a scale factor of 6, moving by 0.1 units each frame. This is done by building a transform of the form scale(N), then setting the element’s style.MozTransform property to that value.

    In addition, just for fun, we’re also changing the text and the color of the text in the block as we switch scaling directions, by setting the value of the block’s innerHTML property to the new contents.

    Final notes

    Three more tidbits to take away from this:

    First, note that as the scaling text grows wider, the document’s width changes to fit it, getting wider as the text grows so that its right edge passes the edge of the document, then narrower as it shrinks again. You can see this by watching the scroll bar at the bottom of the Firefox browser window.

    Second, note that you can actually select and copy the text not only while the elements are transformed, but the selection remains intact while the text continues to transform (although when we change the contents of the scaling example, the selection goes away).

    Third, I didn’t cover all the possible transforms here. For example, I skipped over the translate transform function, which lets you translate an object horizontally or vertically (basically, shifting its position by an offset). You can get a full list of the supported transforms on the Mozilla Developer Center web site.

    Obviously this demo is somewhat frivolous (as demos are prone to be). However, there are genuinely useful things you can do with these when designing interfaces; for example, you can draw text rotated by 90° along the Y axis of a table in order to fit row labels in a narrow but tall space.

  5. mozilla developer preview 4 ready for testing

    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.


    • 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


    • 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.)


    • 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.
  6. (r)evolution number 5

    We’ve just launched Firefox 3.5, and we’re incredibly proud. Naturally, we have engaged in plentiful Mozilla advocacy — this site is, amongst other things, a vehicle for showcasing the latest browser’s new capabilities. We like to think about this release as an upgrade for the whole World Wide Web, because of the new developer-facing features that have just been introduced into the web platform. When talking about some of the next generation standards, the appearance of the number “5” is almost uncanny — consider HTML5 and ECMAScript 5 (PDF). The recent (and very welcome) hype around HTML5 in the press is what motivates this article. Let’s take a step back, and consider some of Mozilla’s web advocacy in the context of events leading up to the release of Firefox 3.5.

    Standardization of many of these features often came after much spirited discussion, and we’re pleased to see the prominent placement of HTML5 as a key strategic initiative by major web development companies. Indeed, exciting new web applications hold a great deal of promise, and really showcase what the future of the web platform holds in store for aspiring developers. Many herald the triumphant arrival of the browser as the computer, an old theme that gets bolstered with the arrival of attractive HTML5 platform features that are implemented across Safari, Chrome, Opera, and of course, Firefox (with IE8 getting an honorable mention for having both some HTML5 features and some ECMAScript, 5th Edition features).

    Call it what you will — Web 5.0, Open Web 5th Generation (wince!), or, (R)evolution # 5, the future is now. But lest anyone forget, HTML5 is not a completed standard yet, as the W3C was quick to point out. The editor doesn’t anticipate completion till 2010. The path taken from the start of what is now called HTML5 to the present-day era of (very welcome) hype has been a long one, and Mozilla has been part of the journey from the very beginning.

    For one thing, we were there to point out, in no uncertain terms, that the W3C had perhaps lost its way. Exactly 5 summers ago (again, with that magic number!), it became evident that the W3C was no longer able to serve as sole custodian of the standards governing the open web of browser-based applications, so Mozilla, along with Opera, started the WHATWG. Of course, back then, we didn’t call it HTML5, and while Firefox itself made a splash in 2004, the steps taken towards standardization were definitive but tentative. Soon, other browser vendors joined us, and by the time the reconciliation with W3C occurred two years later, the innovations introduced into the web platform via the movement initiated by Mozilla had gained substantial momentum.

    The net result is a specification that is not yet complete called “HTML5″ which is implemented piecemeal by most modern browsers. The features we choose to implement as an industry are in response to developers, and our modus operandi is (for the most part) in the open. Mozilla funds the HTML5 Validator, producing the first real HTML5 parser, which now drives W3C’s markup validation for HTML5. That parser has made its way back into Firefox. It’s important to note that capabilities that are of greatest interest (many of which are showcased on this blog) are not only developed within the HTML5 specification, but also as part of the W3C Geolocation WG, the Web Apps WG, and the CSS WG.

    The release of Firefox 3.5, along with updates to other modern browsers, seems to declare that HTML5 has arrived. But with the foresight that comes with having been around this for a while, we also know that we have a lot of work ahead of us. For one thing, we’ve got to finish HTML5, or at least publish a subset of it that we all agree is ready for implementation, soon. We’ve also got to ensure that accessibility serves as an important design principle in the emerging web platform, and resolve sticky differences here. Also, an open standard does not an open platform make, as debates about web fonts and audio/video codecs show. We’ve got a lot of work ahead of us, but for now, 5 years after the summer we started the ball rolling, we’re enjoying the hype around (R)evolution Number 5.

  7. WebGL Draft Released Today

    Even without a draft specification of WebGL in circulation, we’ve seen some promising 3D content using WebGL appear on the web, put together mainly through developer ingenuity and the fact that Firefox, Chromium, and WebKit are open source projects with early support for the technology. Today, the WebGL Working Group at Khronos released a provisional public draft of the WebGL specification, and we are very excited for what this means for the web.

    For one thing, it means more developers can get involved in the evolution of WebGL. There’s a public mailing list set up, so that you can engage directly with members of the WebGL Working Group, as well as a web forum. It’s important to note that the specification is not yet finalized. Participation from the web community is essential towards finalizing the specification, which we hope to do in the first quarter of 2010.

    It also means that there are implementations of the draft specification that you can begin to test. You can obtain a Firefox nightly that implements the WebGL draft specification, and can turn on WebGL support in that build by following these steps:

    • Type “about:config” in your browser’s URL bar
    • Do a search for “webgl” in the Filter field
    • Double-click the “enabled_for_all_sites” preference to change it to “true

    Other browsers that support the draft WebGL specification are listed on the WebGL Wiki.

    Now of course, this is hardware-accelerated 3D graphics in an early beta, and for now requires an OpenGL 2.0-capable GPU and drivers. In particular, most flavors of Intel’s integrated GPUs will not work straight out of the box (such as the GMA900/GMA950 often found in laptops). Developers who build nightly builds of the browser can induce software rendering using Mesa, and should check out Vlad’s blog post for doing this on Windows. Caveat emptor: building software rendering using Mesa into a Firefox nightly is likely to yield slower performance, and is only for the intrepid.

    WebGL is a royalty-free, cross-platform API that brings OpenGL ES 2.0 to the web as a 3D drawing context within HTML5’s Canvas element, exposed as low-level interfaces within the Document Object Model.

    Developers familiar with the Canvas 2D context will recognize that WebGL is another context for Canvas:

    // get the canvas element in the DOM
    var canvas = document.getElementById("canvas3D");
    var gl = canvas.getContext("experimental-webgl");

    Note that till the specification is finalized, the context is called experimental-webgl.

    WebGL uses the OpenGL shading language, GLSL ES, and can be cleanly combined with other web content that is layered on top or underneath the 3D content. It is an emerging web standard, and is designed to be used with other parts of the web platform. The release of the draft specification is one step in bringing about a plugin free 3D API to the web, usable straight out of the box. People have already begun using it to create compelling libraries. Check out X3DOM, which is a JavaScript library using WebGL that allows users to author content in X3D. We expect developer ingenuity to surprise and awe us, as it always has.


  8. Getting involved with Account Manager

    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.

  9. upcoming changes to the viewport meta tag for firefox mobile

    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 <meta name="viewport"> 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. before: 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.


    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:

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


    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.

  10. mitigating attacks with content security policy

    Firefox support for Content Security Policy (CSP) has been in the news and is now available in test builds for web developers to try. Support for CSP isn’t slated for Firefox 3.6 but is likely to be included in the release after 3.6, mostly likely called 3.7.

    This post is targeted at web developers and gives a quick overview of the three kinds of attacks that CSP helps to mitigate and also gives some quick examples so developers can get a sense of how it will work for them.

    In case you don’t know what our Content Security Policy code is – and based on anecdotal evidence a lot of people don’t – it’s a set of easy to use tools that allow a web site owner to tell the browser where it should or should not load resources from. In particular it aims to prevent three different classes of common attacks we see on the web today: cross-site scripting, clickjacking and packet sniffing attacks.

    Cross-site scripting attacks are largely the result of a mistake made on backend web servers where someone fails to escape data that’s submitted by users. When that happens it’s possible to inject a tag to load JavaScript code from another web site. That code could be harmless but it could also contain something dangerous, like malware. What CSP does is make it possible for a web site author, via HTTP headers, to specify what types of scripts can be loaded and from where. For developers who are setting a policy, it adds a layer of protection where even if they make a mistake it is likely to be mitigated by this additional layer of policy.

    Clickjacking attacks are where someone embeds a page into a transparent iframe and “steals” user clicks to activate something dangerous. One particular attack allows a browser to be turned into a remote surveillance device. CSP includes the ability for a page to tell the browser that it never wants to be ever included in an iframe.

    And last is the ability for a web site to tell the browser that it never wants resources from that page to be loaded over unencrypted HTTP. Banking and other commerce sites will find this particularly useful.

    CSP is very powerful and flexible, allowing you to specify whether or not you want to load different kinds of media, different kinds of script methods, css, can be used to set up loading only from specific other hosts and a large number of other things. It’s meant to be very easy to set up for simple cases but will scale up to pretty complex infrastructure where different resources might be spread out over a large number of machines.

    Here are four examples that show common use cases. Each of these examples is a header that’s delivered as a header over HTTP and it affects how the page is rendered.

    A site wants all of its content to come from its own domain:

    X-Content-Security-Policy: allow 'self'

    Example 2: An auction site wants to be able to load images from anywhere, plugin content from a list of trusted media providers and a CDN network and scripts only from its server hosting sanitized JavaScript:

    X-Content-Security-Policy: allow 'self'; img-src *; \
                               object-src *; \

    Example 3: Server administrators want to deny all third-party scripts for the site, and a given project group also wants to disallow media from other sites (header provided by sysadmins and header provided by project group are both present):

    X-Content-Security-Policy: allow *; script-src 'self'
    X-Content-Security-Policy: allow *; script-src 'self'; media-src 'self';

    Example 4: An online payments site wants to ensure that all of the content in its page is loaded over SSL to prevent attackers from eavesdropping on requests for insecure content:

    X-Content-Security-Policy: allow https://*:443

    The implementation isn’t quite complete yet, but it’s pretty close. There’s more information on the demo page for CSP, read the overview or read the spec itself.