Standards Articles

Sort by:


  1. Introducing the JavaScript Internationalization API

    Firefox 29 issued half a year ago, so this post is long overdue. Nevertheless I wanted to pause for a second to discuss the Internationalization API first shipped on desktop in that release (and passing all tests!). Norbert Lindenberg wrote most of the implementation, and I reviewed it and now maintain it. (Work by Makoto Kato should bring this to Android soon; b2g may take longer due to some b2g-specific hurdles. Stay tuned.)

    What’s internationalization?

    Internationalization (i18n for short — i, eighteen characters, n) is the process of writing applications in a way that allows them to be easily adapted for audiences from varied places, using varied languages. It’s easy to get this wrong by inadvertently assuming one’s users come from one place and speak one language, especially if you don’t even know you’ve made an assumption.

    function formatDate(d)
      // Everyone uses month/date/year...right?
      var month = d.getMonth() + 1;
      var date = d.getDate();
      var year = d.getFullYear();
      return month + "/" + date + "/" + year;
    function formatMoney(amount)
      // All money is dollars with two fractional digits...right?
      return "$" + amount.toFixed(2);
    function sortNames(names)
      function sortAlphabetically(a, b)
        var left = a.toLowerCase(), right = b.toLowerCase();
        if (left > right)
          return 1;
        if (left === right)
          return 0;
        return -1;
      // Names always sort alphabetically...right?

    JavaScript’s historical i18n support is poor

    i18n-aware formatting in traditional JS uses the various toLocaleString() methods. The resulting strings contained whatever details the implementation chose to provide: no way to pick and choose (did you need a weekday in that formatted date? is the year irrelevant?). Even if the proper details were included, the format might be wrong e.g. decimal when percentage was desired. And you couldn’t choose a locale.

    As for sorting, JS provided almost no useful locale-sensitive text-comparison (collation) functions. localeCompare() existed but with a very awkward interface unsuited for use with sort. And it too didn’t permit choosing a locale or specific sort order.

    These limitations are bad enough that — this surprised me greatly when I learned it! — serious web applications that need i18n capabilities (most commonly, financial sites displaying currencies) will box up the data, send it to a server, have the server perform the operation, and send it back to the client. Server roundtrips just to format amounts of money. Yeesh.

    A new JS Internationalization API

    The new ECMAScript Internationalization API greatly improves JavaScript’s i18n capabilities. It provides all the flourishes one could want for formatting dates and numbers and sorting text. The locale is selectable, with fallback if the requested locale is unsupported. Formatting requests can specify the particular components to include. Custom formats for percentages, significant digits, and currencies are supported. Numerous collation options are exposed for use in sorting text. And if you care about performance, the up-front work to select a locale and process options can now be done once, instead of once every time a locale-dependent operation is performed.

    That said, the API is not a panacea. The API is “best effort” only. Precise outputs are almost always deliberately unspecified. An implementation could legally support only the oj locale, or it could ignore (almost all) provided formatting options. Most implementations will have high-quality support for many locales, but it’s not guaranteed (particularly on resource-constrained systems such as mobile).

    Under the hood, Firefox’s implementation depends upon the International Components for Unicode library (ICU), which in turn depends upon the Unicode Common Locale Data Repository (CLDR) locale data set. Our implementation is self-hosted: most of the implementation atop ICU is written in JavaScript itself. We hit a few bumps along the way (we haven’t self-hosted anything this large before), but nothing major.

    The Intl interface

    The i18n API lives on the global Intl object. Intl contains three constructors: Intl.Collator, Intl.DateTimeFormat, and Intl.NumberFormat. Each constructor creates an object exposing the relevant operation, efficiently caching locale and options for the operation. Creating such an object follows this pattern:

    var ctor = "Collator"; // or the others
    var instance = new Intl[ctor](locales, options);

    locales is a string specifying a single language tag or an arraylike object containing multiple language tags. Language tags are strings like en (English generally), de-AT (German as used in Austria), or zh-Hant-TW (Chinese as used in Taiwan, using the traditional Chinese script). Language tags can also include a “Unicode extension”, of the form -u-key1-value1-key2-value2..., where each key is an “extension key”. The various constructors interpret these specially.

    options is an object whose properties (or their absence, by evaluating to undefined) determine how the formatter or collator behaves. Its exact interpretation is determined by the individual constructor.

    Given locale information and options, the implementation will try to produce the closest behavior it can to the “ideal” behavior. Firefox supports 400+ locales for collation and 600+ locales for date/time and number formatting, so it’s very likely (but not guaranteed) the locales you might care about are supported.

    Intl generally provides no guarantee of particular behavior. If the requested locale is unsupported, Intl allows best-effort behavior. Even if the locale is supported, behavior is not rigidly specified. Never assume that a particular set of options corresponds to a particular format. The phrasing of the overall format (encompassing all requested components) might vary across browsers, or even across browser versions. Individual components’ formats are unspecified: a short-format weekday might be “S”, “Sa”, or “Sat”. The Intl API isn’t intended to expose exactly specified behavior.

    Date/time formatting


    The primary options properties for date/time formatting are as follows:

    weekday, era
    "narrow", "short", or "long". (era refers to typically longer-than-year divisions in a calendar system: BC/AD, the current Japanese emperor’s reign, or others.)
    "2-digit", "numeric", "narrow", "short", or "long"
    hour, minute, second
    "2-digit" or "numeric"
    "short" or "long"
    Case-insensitive "UTC" will format with respect to UTC. Values like "CEST" and "America/New_York" don’t have to be supported, and they don’t currently work in Firefox.

    The values don’t map to particular formats: remember, the Intl API almost never specifies exact behavior. But the intent is that "narrow", "short", and "long" produce output of corresponding size — “S” or “Sa”, “Sat”, and “Saturday”, for example. (Output may be ambiguous: Saturday and Sunday both could produce “S”.) "2-digit" and "numeric" map to two-digit number strings or full-length numeric strings: “70” and “1970”, for example.

    The final used options are largely the requested options. However, if you don’t specifically request any weekday/year/month/day/hour/minute/second, then year/month/day will be added to your provided options.

    Beyond these basic options are a few special options:

    Specifies whether hours will be in 12-hour or 24-hour format. The default is typically locale-dependent. (Details such as whether midnight is zero-based or twelve-based and whether leading zeroes are present are also locale-dependent.)

    There are also two special properties, localeMatcher (taking either "lookup" or "best fit") and formatMatcher (taking either "basic" or "best fit"), each defaulting to "best fit". These affect how the right locale and format are selected. The use cases for these are somewhat esoteric, so you should probably ignore them.

    Locale-centric options

    DateTimeFormat also allows formatting using customized calendaring and numbering systems. These details are effectively part of the locale, so they’re specified in the Unicode extension in the language tag.

    For example, Thai as spoken in Thailand has the language tag th-TH. Recall that a Unicode extension has the format -u-key1-value1-key2-value2.... The calendaring system key is ca, and the numbering system key is nu. The Thai numbering system has the value thai, and the Chinese calendaring system has the value chinese. Thus to format dates in this overall manner, we tack a Unicode extension containing both these key/value pairs onto the end of the language tag: th-TH-u-ca-chinese-nu-thai.

    For more information on the various calendaring and numbering systems, see the full DateTimeFormat documentation.


    After creating a DateTimeFormat object, the next step is to use it to format dates via the handy format() function. Conveniently, this function is a bound function: you don’t have to call it on the DateTimeFormat directly. Then provide it a timestamp or Date object.

    Putting it all together, here are some examples of how to create DateTimeFormat options for particular uses, with current behavior in Firefox.

    var msPerDay = 24 * 60 * 60 * 1000;
    // July 17, 2014 00:00:00 UTC.
    var july172014 = new Date(msPerDay * (44 * 365 + 11 + 197));

    Let’s format a date for English as used in the United States. Let’s include two-digit month/day/year, plus two-digit hours/minutes, and a short time zone to clarify that time. (The result would obviously be different in another time zone.)

    var options =
      { year: "2-digit", month: "2-digit", day: "2-digit",
        hour: "2-digit", minute: "2-digit",
        timeZoneName: "short" };
    var americanDateTime =
      new Intl.DateTimeFormat("en-US", options).format;
    print(americanDateTime(july172014)); // 07/16/14, 5:00 PM PDT

    Or let’s do something similar for Portuguese — ideally as used in Brazil, but in a pinch Portugal works. Let’s go for a little longer format, with full year and spelled-out month, but make it UTC for portability.

    var options =
      { year: "numeric", month: "long", day: "numeric",
        hour: "2-digit", minute: "2-digit",
        timeZoneName: "short", timeZone: "UTC" };
    var portugueseTime =
      new Intl.DateTimeFormat(["pt-BR", "pt-PT"], options);
    // 17 de julho de 2014 00:00 GMT

    How about a compact, UTC-formatted weekly Swiss train schedule? We’ll try the official languages from most to least popular to choose the one that’s most likely to be readable.

    var swissLocales = ["de-CH", "fr-CH", "it-CH", "rm-CH"];
    var options =
      { weekday: "short",
        hour: "numeric", minute: "numeric",
        timeZone: "UTC", timeZoneName: "short" };
    var swissTime =
      new Intl.DateTimeFormat(swissLocales, options).format;
    print(swissTime(july172014)); // Do. 00:00 GMT

    Or let’s try a date in descriptive text by a painting in a Japanese museum, using the Japanese calendar with year and era:

    var jpYearEra =
      new Intl.DateTimeFormat("ja-JP-u-ca-japanese",
                              { year: "numeric", era: "long" });
    print(jpYearEra.format(july172014)); // 平成26年

    And for something completely different, a longer date for use in Thai as used in Thailand — but using the Thai numbering system and Chinese calendar. (Quality implementations such as Firefox’s would treat plain th-TH as th-TH-u-ca-buddhist-nu-latn, imputing Thailand’s typical Buddhist calendar system and Latin 0-9 numerals.)

    var options =
      { year: "numeric", month: "long", day: "numeric" };
    var thaiDate =
      new Intl.DateTimeFormat("th-TH-u-nu-thai-ca-chinese", options);
    print(thaiDate.format(july172014)); // ๒๐ 6 ๓๑

    Calendar and numbering system bits aside, it’s relatively simple. Just pick your components and their lengths.

    Number formatting


    The primary options properties for number formatting are as follows:

    "currency", "percent", or "decimal" (the default) to format a value of that kind.
    A three-letter currency code, e.g. USD or CHF. Required if style is "currency", otherwise meaningless.
    "code", "symbol", or "name", defaulting to "symbol". "code" will use the three-letter currency code in the formatted string. "symbol" will use a currency symbol such as $ or £. "name" typically uses some sort of spelled-out version of the currency. (Firefox currently only supports "symbol", but this will be fixed soon.)
    An integer from 1 to 21 (inclusive), defaulting to 1. The resulting string is front-padded with zeroes until its integer component contains at least this many digits. (For example, if this value were 2, formatting 3 might produce “03”.)
    minimumFractionDigits, maximumFractionDigits
    Integers from 0 to 20 (inclusive). The resulting string will have at least minimumFractionDigits, and no more than maximumFractionDigits, fractional digits. The default minimum is currency-dependent (usually 2, rarely 0 or 3) if style is "currency", otherwise 0. The default maximum is 0 for percents, 3 for decimals, and currency-dependent for currencies.
    minimumSignificantDigits, maximumSignificantDigits
    Integers from 1 to 21 (inclusive). If present, these override the integer/fraction digit control above to determine the minimum/maximum significant figures in the formatted number string, as determined in concert with the number of decimal places required to accurately specify the number. (Note that in a multiple of 10 the significant digits may be ambiguous, as in “100” with its one, two, or three significant digits.)
    Boolean (defaulting to true) determining whether the formatted string will contain grouping separators (e.g. “,” as English thousands separator).

    NumberFormat also recognizes the esoteric, mostly ignorable localeMatcher property.

    Locale-centric options

    Just as DateTimeFormat supported custom numbering systems in the Unicode extension using the nu key, so too does NumberFormat. For example, the language tag for Chinese as used in China is zh-CN. The value for the Han decimal numbering system is hanidec. To format numbers for these systems, we tack a Unicode extension onto the language tag: zh-CN-u-nu-hanidec.

    For complete information on specifying the various numbering systems, see the full NumberFormat documentation.


    NumberFormat objects have a format function property just as DateTimeFormat objects do. And as there, the format function is a bound function that may be used in isolation from the NumberFormat.

    Here are some examples of how to create NumberFormat options for particular uses, with Firefox’s behavior. First let’s format some money for use in Chinese as used in China, specifically using Han decimal numbers (instead of much more common Latin numbers). Select the "currency" style, then use the code for Chinese renminbi (yuan), grouping by default, with the usual number of fractional digits.

    var hanDecimalRMBInChina =
      new Intl.NumberFormat("zh-CN-u-nu-hanidec",
                            { style: "currency", currency: "CNY" });
    print(hanDecimalRMBInChina.format(1314.25)); // ¥ 一,三一四.二五

    Or let’s format a United States-style gas price, with its peculiar thousandths-place 9, for use in English as used in the United States.

    var gasPrice =
      new Intl.NumberFormat("en-US",
                            { style: "currency", currency: "USD",
                              minimumFractionDigits: 3 });
    print(gasPrice.format(5.259)); // $5.259

    Or let’s try a percentage in Arabic, meant for use in Egypt. Make sure the percentage has at least two fractional digits. (Note that this and all the other RTL examples may appear with different ordering in RTL context, e.g. ٤٣٫٨٠٪ instead of ٤٣٫٨٠٪.)

    var arabicPercent =
      new Intl.NumberFormat("ar-EG",
                            { style: "percent",
                              minimumFractionDigits: 2 }).format;
    print(arabicPercent(0.438)); // ٤٣٫٨٠٪

    Or suppose we’re formatting for Persian as used in Afghanistan, and we want at least two integer digits and no more than two fractional digits.

    var persianDecimal =
      new Intl.NumberFormat("fa-AF",
                            { minimumIntegerDigits: 2,
                              maximumFractionDigits: 2 });
    print(persianDecimal.format(3.1416)); // ۰۳٫۱۴

    Finally, let’s format an amount of Bahraini dinars, for Arabic as used in Bahrain. Unusually compared to most currencies, Bahraini dinars divide into thousandths (fils), so our number will have three places. (Again note that apparent visual ordering should be taken with a grain of salt.)

    var bahrainiDinars =
      new Intl.NumberFormat("ar-BH",
                            { style: "currency", currency: "BHD" });
    print(bahrainiDinars.format(3.17)); // د.ب.‏ ٣٫١٧٠



    The primary options properties for collation are as follows:

    "sort" or "search" (defaulting to "sort"), specifying the intended use of this Collator. (A search collator might want to consider more strings equivalent than a sort collator would.)
    "base", "accent", "case", or "variant". This affects how sensitive the collator is to characters that have the same “base letter” but have different accents/diacritics and/or case. (Base letters are locale-dependent: “a” and “ä” have the same base letter in German but are different letters in Swedish.) "base" sensitivity considers only the base letter, ignoring modifications (so for German “a”, “A”, and “ä” are considered the same). "accent" considers the base letter and accents but ignores case (so for German “a” and “A” are the same, but “ä” differs from both). "case" considers the base letter and case but ignores accents (so for German “a” and “ä” are the same, but “A” differs from both). Finally, "variant" considers base letter, accents, and case (so for German “a”, “ä, “ä” and “A” all differ). If usage is "sort", the default is "variant"; otherwise it’s locale-dependent.
    Boolean (defaulting to false) determining whether complete numbers embedded in strings are considered when sorting. For example, numeric sorting might produce "F-4 Phantom II", "F-14 Tomcat", "F-35 Lightning II"; non-numeric sorting might produce "F-14 Tomcat", "F-35 Lightning II", "F-4 Phantom II".
    "upper", "lower", or "false" (the default). Determines how case is considered when sorting: "upper" places uppercase letters first ("B", "a", "c"), "lower" places lowercase first ("a", "c", "B"), and "false" ignores case entirely ("a", "B", "c"). (Note: Firefox currently ignores this property.)
    Boolean (defaulting to false) determining whether to ignore embedded punctuation when performing the comparison (for example, so that "biweekly" and "bi-weekly" compare equivalent).

    And there’s that localeMatcher property that you can probably ignore.

    Locale-centric options

    The main Collator option specified as part of the locale’s Unicode extension is co, selecting the kind of sorting to perform: phone book (phonebk), dictionary (dict), and many others.

    Additionally, the keys kn and kf may, optionally, duplicate the numeric and caseFirst properties of the options object. But they’re not guaranteed to be supported in the language tag, and options is much clearer than language tag components. So it’s best to only adjust these options through options.

    These key-value pairs are included in the Unicode extension the same way they’ve been included for DateTimeFormat and NumberFormat; refer to those sections for how to specify these in a language tag.


    Collator objects have a compare function property. This function accepts two arguments x and y and returns a number less than zero if x compares less than y, 0 if x compares equal to y, or a number greater than zero if x compares greater than y. As with the format functions, compare is a bound function that may be extracted for standalone use.

    Let’s try sorting a few German surnames, for use in German as used in Germany. There are actually two different sort orders in German, phonebook and dictionary. Phonebook sort emphasizes sound, and it’s as if “ä”, “ö”, and so on were expanded to “ae”, “oe”, and so on prior to sorting.

    var names =
      ["Hochberg", "Hönigswald", "Holzman"];
    var germanPhonebook = new Intl.Collator("de-DE-u-co-phonebk");
    // as if sorting ["Hochberg", "Hoenigswald", "Holzman"]:
    //   Hochberg, Hönigswald, Holzman
    print(names.sort(", "));

    Some German words conjugate with extra umlauts, so in dictionaries it’s sensible to order ignoring umlauts (except when ordering words differing only by umlauts: schon before schön).

    var germanDictionary = new Intl.Collator("de-DE-u-co-dict");
    // as if sorting ["Hochberg", "Honigswald", "Holzman"]:
    //   Hochberg, Holzman, Hönigswald
    print(names.sort(", "));

    Or let’s sort a list Firefox versions with various typos (different capitalizations, random accents and diacritical marks, extra hyphenation), in English as used in the United States. We want to sort respecting version number, so do a numeric sort so that numbers in the strings are compared, not considered character-by-character.

    var firefoxen =
      ["FireFøx 3.6",
       "Fire-fox 1.0",
       "Firefox 29",
       "FÍrefox 3.5",
       "Fírefox 18"];
    var usVersion =
      new Intl.Collator("en-US",
                        { sensitivity: "base",
                          numeric: true,
                          ignorePunctuation: true });
    // Fire-fox 1.0, FÍrefox 3.5, FireFøx 3.6, Fírefox 18, Firefox 29
    print(firefoxen.sort(", "));

    Last, let’s do some locale-aware string searching that ignores case and accents, again in English as used in the United States.

    // Comparisons work with both composed and decomposed forms.
    var decoratedBrowsers =
       "A\u0362maya",  // A͢maya
       "CH\u035Brôme", // CH͛rôme
       "o\u0323pERA",  // ọpERA
       "I\u0352E",     // I͒E
    var fuzzySearch =
      new Intl.Collator("en-US",
                        { usage: "search", sensitivity: "base" });
    function findBrowser(browser)
      function cmp(other)
        return, other) === 0;
      return cmp;
    print(decoratedBrowsers.findIndex(findBrowser("Firêfox"))); // 2
    print(decoratedBrowsers.findIndex(findBrowser("Safåri")));  // 3
    print(decoratedBrowsers.findIndex(findBrowser("Ãmaya")));   // 0
    print(decoratedBrowsers.findIndex(findBrowser("Øpera")));   // 4
    print(decoratedBrowsers.findIndex(findBrowser("Chromè")));  // 1
    print(decoratedBrowsers.findIndex(findBrowser("IË")));      // 5

    Odds and ends

    It may be useful to determine whether support for some operation is provided for particular locales, or to determine whether a locale is supported. Intl provides supportedLocales() functions on each constructor, and resolvedOptions() functions on each prototype, to expose this information.

    var navajoLocales =
      Intl.Collator.supportedLocalesOf(["nv"], { usage: "sort" });
    print(navajoLocales.length > 0
          ? "Navajo collation supported"
          : "Navajo collation not supported");
    var germanFakeRegion =
      new Intl.DateTimeFormat("de-XX", { timeZone: "UTC" });
    var usedOptions = germanFakeRegion.resolvedOptions();
    print(usedOptions.locale);   // de
    print(usedOptions.timeZone); // UTC

    Legacy behavior

    The ES5 toLocaleString-style and localeCompare functions previously had no particular semantics, accepted no particular options, and were largely useless. So the i18n API reformulates them in terms of Intl operations. Each method now accepts additional trailing locales and options arguments, interpreted just as the Intl constructors would do. (Except that for toLocaleTimeString and toLocaleDateString, different default components are used if options aren’t provided.)

    For brief use where precise behavior doesn’t matter, the old methods are fine to use. But if you need more control or are formatting or comparing many times, it’s best to use the Intl primitives directly.


    Internationalization is a fascinating topic whose complexity is bounded only by the varied nature of human communication. The Internationalization API addresses a small but quite useful portion of that complexity, making it easier to produce locale-sensitive web applications. Go use it!

    (And a special thanks to Norbert Lindenberg, Anas El Husseini, Simon Montagu, Gary Kwong, Shu-yu Guo, Ehsan Akhgari, the people of, and anyone I may have forgotten [sorry!] who provided feedback on this article or assisted me in producing and critiquing the examples. The English and German examples were the limit of my knowledge, and I’d have been completely lost on the other examples without their assistance. Blame all remaining errors on me. Thanks again!)

  2. A call for quality HTML5 demo markup

    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 <button>edit</button> using the “edit” as the trigger for certain functionality would have to have the JS localised, too when you create the German <button>bearbeiten</button>.

    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:

        <a href="{link}">
          <img src="{src}" alt="{title}">

    The markup I found though was this:

    <div id="sky">
      <div class="skyTile" style="{calculated styles};display:block">
        <img class="skyThumb" src="{src}" style="{generated styles}">
        <img src="images/thumb_dropShadow.png"
             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:

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

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

    <ul id="mitems">
      <li>{parent name}
          <li><a href="{url}">{name}</a></li>
          [... 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:

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

    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:

    <div id="homeButtonPanel">
      <div class="homeButton" id="drawHomeButton"
           style="display: block;">
        <p>Start Drawing</p>
      <div class="homeButton" id="viewHomeButton"
           style="display: block;">
        <p>View the Mural</p>
    <div id="controlPanel" style="display: block;">
    <div class="titleButton"><p>{title}</p></div>
      <div class="mainMenu">
        <div class="mainButton mainSelected" id="drawButton">
          <div id="inkDisplay">
            <div id="inkMeter" style="width: 94px;">
        <div class="menuContainer">
          <div class="menuButton drawMenuButton" id="behaviorsButton"
               style="display: block; opacity: 1;">
            <p>Gesture<br />Behaviors</p>
        <div class="menuContainer">
          <div class="menuButton drawMenuButton" id="artworkButton"
               style="display: block; opacity: 1;">
        <div class="menuContainer">
          <div class="menuButton drawMenuButton" id="resetButton"
               style="display: block; opacity: 1;">
        <div class="menuContainer">
          <div class="menuButton drawMenuButton" id="undoButton"
               style="display: block; opacity: 1;">
        <div class="menuContainer">
          <div class="menuButton drawMenuButton" id="saveButton"
               style="display: block; opacity: 1;">
      <div class="mainMenu">
        <div class="mainButton" id="viewButton"><p>View</p></div>
      <div class="mainMenu">
        <div class="secondaryButton" id="helpButton"><p>Help</p></div>
      <div class="mainMenu">
        <div class="mainShare shareButtonSmall" id="mainTwitterButton">
          <img alt="twitter" src="images/twitter_icon.png"
               style="opacity: 0.6;">
        <div class="mainShare shareButtonLarge" id="mainFacebookButton">
          <img alt="facebook" src="images/facebook_icon.png">
        <div class="mainShare shareButtonSmall" id="mainEmailButton">
          <img 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:

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

    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:

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

    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:

    <div id="tools">
      <span onmouseout="buttonOut(1)" onmouseover="buttonOver(1)"
            onclick="buttonClicked(1)" id="button1" class="button">
        <img alt="" src="image/button/1.png">
      <span onmouseout="buttonOut(2)" onmouseover="buttonOver(2)"
            onclick="buttonClicked(2)" id="button2" class="button">
            <img alt="" src="image/button/2.png">
      [...repeated 20 times...]
    <div id="toolsSeparator">&nbsp;</div>
      <a title="" id="toolbarButtonSave" class="toolbarButton"
        <img alt="" src="image/save.png">
      <a title="New" id="toolbarButtonNew" class="toolbarButton"
        <img alt="New" src="image/new.png"></a>
      <!--[if !IE]><![IGNORE[--><!--[IGNORE[]]-->
      <a id="toolbarButtonMenu" class="toolbarButton"
         onmouseout="closeMenuDelay()" onmouseover="showMenuHover()"
        <img alt="&gt;" src="image/menu.png">
      <div onmouseout="closeMenuDelay()" onmouseover="overMenu()" id="menu">
        <a class="saveMenu" onmouseout="closeMenuDelay()"
           onmouseover="overMenu()" href="javascript:saveCanvas()">
          save normal
        <a class="saveMenu" onmouseout="closeMenuDelay()"
           onmouseover="overMenu()" href="javascript:saveCanvasHi()">
          save high quality
          <span class="footnote">&nbsp; (rename to *.png)</span>
        <a onmouseout="closeMenuDelay()" onmouseover="overMenu()"
        <a class="lastMenu" target="_top" onmouseout="closeMenuDelay()"
          <span class="footnote">
          <em>a sound memory game</em>

    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.

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

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

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

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

  7. 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.
  8. (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.

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


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