Mozilla

Articles by Christopher Blizzard

Sort by:

View:

  1. two important api changes – CSS gradients and the media load event

    Robert O’Callahan has been posting updates in his weblog about changes that we’re going to be making that are web-facing. It’s worth summarizing two here for web developers.

    Removing the media element ‘load’ event.

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

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

    Changing our CSS Gradient Syntax

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

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

  2. Firefox 3.6 Beta 1 now available – what’s new for web developers

    Firefox 3.6b1 is now available for download. As usual, this is a beta release so the usual warnings about eating your data and burning your house down apply.

    If you download and run this beta you will get updates as we make them available – once every 1-2 weeks or so. To keep up with things as they land in the betas, please follow us on the @mozhacks twitter account.

    Many add-ons have not been updated for 3.6. To help us test if add-ons are compatible consider installing the Add-on compatibility reporter. It will let you run add-ons that are listed as incompatible and gives you the chance to report if add-ons appear to be working OK. This is our first attempt at crowdsourcing compatibility and if you’re feeling adventurous you should try it out.

    Here’s what’s new and notable in 3.6 Beta vs. Firefox 3.5 that might be of interest to web developers:

    Here’s the list of things that we will support by 3.6 final, but aren’t in this beta:

    • Support for CSS gradients is in this beta, but we’re changing it due to negative feedback on the current syntax.
    • We will support the <input type=”file” multiple> so you can upload more than one file from the same file upload control.
    • We have support in 3.6 for a new version of the File API draft spec but that spec is out of date and our docs aren’t complete. There’s an IDL entry for the FileRequest object, but it’s likely to be renamed to FileReader based on feedback. We’ll try to keep people updated as we release updated betas.
  3. help build the mozilla developer network

    Route 66 by Caveman 92223

    Route 66 by Caveman 92223

    Help us build the Mozilla Developer Network

    Take the survey now.

    At Mozilla we’ve been talking recently about how important the web has become to everything around us. The web – and the Internet it’s built on – has become the defining computing platform for this century. And most of that has happened because of web developers, and the freedom they have enjoyed.

    Firefox is one of the most important tools for web developers. Firebug combined with Firefox’s strong support for standards means that most web developers are building for Firefox first and then porting to other browsers later.

    But even with developers using Firefox for development there hasn’t been an easy way for those of us at the Mozilla project to let you know about what’s going on at Mozilla – what we’re putting in Firefox, what we’re doing to bring the web forward and what we’re doing for web developers. (Although the hacks weblog is the first attempt at that.) And conversely there isn’t an obvious way for individual web developers to give Mozilla structured feedback about what’s important to them or what issues they might be having.

    That’s why we’re working on the Mozilla Developer Network. It will serve two purposes:

    1. To provide you with information about what’s going on at Mozilla and around the web.
    2. To give you the chance to give us structured feedback and become part of the Mozilla Community.

    Our first step is to do a quick survey. If we can get 5,000 responses to the survey, we’ll release the aggregate results.

    The survey itself asks you about how you work, what you think of Firefox and should only take a few minutes to complete.

    Thanks! We’ll have more on the Mozilla Developer Network as things progress.

  4. font_dragr: a drag and drop preview tool for fonts

    This demo is from our good friend Ryan Seddon who came up with a demo that seems deeply appropriate for this week, given our focus on the future of fonts on the web.

    If you’ve ever been editing a page and wanted to know what a particular font looked like without having to upload files to a web server and update CSS (so tedious, that!) then this demo is for you.

    He’s come up with a demo that shows what’s possible when you’ve got downloadable fonts, drag and drop and editable content. (If you want to know more about drag and drop we suggest you read his excellent overview of using drag and drop to do file uploading.)

    From Ryan’s description:

    Font dragr is an experimental web app that uses HTML5 & CSS3 to create a useful standalone web based application for testing custom fonts, once you visit it for the first time you don’t need to be online to use it after the initial visit. It allows you, in Firefox 3.6+, to drag and drop font files from your file system into the drop area. The browser will then create a data URL encoded copy to use in the page and render the content in the dropped font.

    You can either read the full description, which contains a lot of useful technical information about how the demo works, or you can view the demo below. Either way, it’s nice to see the excellent HTML5 support in Firefox 3.6 coming together with everything else we’ve added to bring a lot of new capabilities to web developers and users.

    Thanks, Ryan!

  5. after Firefox 3.6 – new font control features for designers

    Note: the discussion below applies to work in progress that might show up in Firefox 3.7. It does not describe features in Firefox 3.6.

    This post is from Jonathan Kew and John Daggett. He’s supplied a 5 minute video that shows some of the features on the fly. If you’re a total font nerd and you enjoy a soothing British accent, you might want to watch it.

    Using @font-face allows web designers a wide palette of font choices and with commercial font vendors supporting the WOFF font format, the set of font choices should improve even more. So the next step is clearly to try and make better use of features available in these fonts.

    For many years, “smart” font formats such as OpenType and AAT have provided font designers ways of including a rich set of variations in their fonts, from ligatures and swashes to small caps and tabular figures. The OpenType specification describes these features, identifying each with a unique feature tag. But these have typically only been available to those using professional publishing applications such as Adobe InDesign. Firefox currently renders using font defaults; it would be much more interesting to provide web authors with a way of controlling these font features via CSS.

    Håkon Wium Lie of Opera, based on discussions with Tal Leming and Adam Twardoch, proposed extending the CSS ‘font-variant’ property to include values for font features. Mozilla is actively working on a new proposal along these lines. This is a fairly big addition to CSS, so it will most likely involve some complex discussions about how best to support these features.

    Experimental Implementation

    As part of this effort, Jonathan Kew has been working on porting a portion of the Pango library for use with handling complex scripts and to enable the use of font features on all supported platforms. He currently has an experimental build that uses a special CSS property to associate a list of OpenType features with specific elements in a page. This is not the proposed format, it simply provides a better way of discussing possible sets of font-variant properties and the OpenType feature settings to which they should map.

    .altstyles {
      /* format: feature-tag=[0,1] with 0 to disable, 1 to enable */
      -moz-font-feature-opentype: "dlig=1,ss01=1";
    }

    The feature setting string above implies rendering with discretionary ligatures (dlig) and the first set of stylistic alternates (ss01). An example using Jack Usine’s MEgalopolis Extra:

    This font makes extensive use of OpenType features; the homepage of the font contains a sample rendering that uses many of these features. Below is a rendering of the same sample written in HTML with OpenType features enabled:

    Tabular Figures for Numerical Alignment

    OpenType features also enable better control over alignment. When numbers are listed in tabular form, proportional forms often result in the misalignment of digits across rows, making the list harder to scan. With tabular alignment enabled, individual digits are rendered using a fixed width so that digits align across rows:

    Automatic Fractions

    Automatic fractions are also possible with OpenType features, note the inline use of fractional forms in the recipe ingredient list below:

    Language Sensitivity

    OpenType also includes support for features on a per-language basis. This is important for rendering text correctly in some languages. For example, Turkish uses both a dotted-i and a dotless-i, so the distinction needs to be preserved when rendering ligatures or small caps. Below is the same text in English and Turkish, with both default and language-sensitive renderings shown for the Turkish text:

    Historical Text

    The way text is rendered constantly evolves; glyphs once in common use often morph into other forms, making the historical forms distinct from their modern forms. Below is the text of an old Massachusetts Bay Colony law, taken from a book in the Daniel R. Coquillette Rare Book Room of the Boston College Law Library.

    Original scanned image:

    Below is the same text rendered in HTML using the Fell Types revival fonts by Igino Marini with OpenType features enabled. Note the ‘ct’ ligature and the contextual form of the ‘s’:

    More resources

    Font feature support in CSS proposal
    OpenType font feature list
    Fell Types revival fonts by Igino Marini

  6. Web Open Font Format for Firefox 3.6

    This article was written by John Daggett. John is a Mozilla contributor and has been working hard with font creators and web developers to improve the state of fonts on the web. This article is a high-level overview of whats different and shows some examples of WOFF in use. A full list of other supporting organizations can be found at the official Mozilla Blog.

    In Firefox 3.5 we included support for linking to TrueType and OpenType fonts. In Firefox 3.6 we’re including support for a new font format – the Web Open Font Format, or WOFF. This format has two main advantages over raw TrueType or OpenType fonts.

    1. It is compressed, which means that you will typically see much smaller download sizes compared with raw TrueType or OpenType fonts.
    2. It contains information that allows you to see where the font came from – without DRM or labeling for a specific domain – which means it has support from a large number of font creators and font foundries.

    The WOFF format originated from a collabaration between the font designers Erik van Blokland and Tal Leming with help from Mozilla’s Jonathan Kew. Each had proposed their own format and WOFF represents a melding of these different proposals. The format itself is intended to be a simple repackaging of OpenType or TrueType font data, it doesn’t introduce any new behavior, alter the @font-face linking mechanism or affect the way fonts are rendered. Many font vendors have expressed support for this new format so the hope is this will open up a wider range of font options for web designers.

    Details on Differences between TrueType, OpenType and WOFF

    First, compression is part of the WOFF format so web authors can optimize the size of fonts used on their pages. The compression format is lossless, the uncompressed font data will match that of the original OpenType or TrueType font, so the way the font renders will be the same as the original. Similar compression can be achieved using general HTTP compression but because compression is part of the WOFF format, it’s simpler for authors to use, especially in situations where access to server configuration is not possible.

    Second, the format includes optional metadata so that a font vendor can tag their fonts with information related to font usage. This metadata doesn’t affect how fonts are loaded but tools can use this information to identify the source of a given font, so that those interested in the design of a given page can track down the fonts used on that page. Fonts in WOFF format are compressed but are not encrypted, the format should not be viewed as a “secure” format by those looking for a mechanism to strictly regulate and control font use.

    Note: until Firefox 3.6 ships, users can test the use of WOFF fonts with Firefox nightly builds.

    Examples

    Below is a simple example that shows how to construct an @font-face rule that links to a WOFF font. To support browsers that only support direct linking to OpenType and TrueType fonts, the ‘src’ descriptor lists the WOFF font first along with a format hint (“woff”), followed by the TrueType version:

    /* Gentium (SIL International) */
     
    @font-face {
      font-family: GentiumTest;
      src: url(fonts/GenR102.woff) format("woff"),
           url(fonts/GenR102.ttf) format("truetype");
    }
     
    body {
      font-family: GentiumTest, Times, Times New Roman, serif;
    }

    Structured this way, browsers that support the WOFF format will download the WOFF file. Other browsers that support @font-face but don’t yet support the WOFF format will use the TrueType version. (Note: IE support is a bit trickier, as discussed below). As WOFF is adopted more widely the need to include links to multiple font formats will diminish.

    Other examples below demostrate the use of WOFF formatted fonts but each example has been constructed so that it will work in any browser that supports @font-face, including Internet Explorer.

    A font family with multiple faces

    Using a Postscript CFF font

    African Language Display

    Below is an example of how downloadable fonts can be used to render languages for which font support is usually lacking. The example shows the UN Declaration of Human Rights, translated into two African languages, and how these render with default browser fonts vs. with a downloadable font suited for rendering these languages.

    Note that in one of these examples that the font size goes from a 3.1MB TTF to a 1MB WOFF font and in the other from a 172KB TTF to an 80KB WOFF file.

    Another Postscript CFF font

    An example in Japanese

    Working With Other Browsers

    Firefox 3.6 will be the first shipping browser to support the WOFF format so it’s important to construct @font-face rules that work with browsers lacking WOFF support. One thing that helps greatly with this is the use of format hints to indicate the format of font data before it’s downloaded; browsers that don’t recognize a given format simply skip data in a format they don’t support.

    Internet Explorer, including IE8, only supports the EOT font format and only implements a subset of the @font-face rule descriptors. This makes creating cross-platform @font-face rules that work with IE especially tricky. One solution is to make different rules for IE:

    @font-face {
      font-family: GentiumTest;
      src: url(fonts/GenR102.eot);  /* for IE */
    }
     
    @font-face {
      font-family: GentiumTest;
      /* Works only in WOFF-enabled browsers */
      src: url(fonts/GenR102.woff) format("woff"); 
    }

    One minor downside of this is that IE doesn’t understand format hints and doesn’t parse @font-face URL’s correctly, it treats format hints as part of the URL, so web authors using the @font-face rules above will see the following in their access logs:

    GET /fonts/GenR102.eot HTTP/1.1" 200 303536
    GET /fonts/GenR102.woff)%20format(%22woff%22) HTTP/1.1" 404 335

    IE successfully pulls down and uses the EOT version of the font but also tries to pull down the WOFF font with the format hint included in the URL. This fails and doesn’t affecting page rendering but it wastes valuable server resources. For more discussion, see Paul Irish’s blog post for one interesting workaround.

    Another problem is that IE currently tries to download all fonts on the page, whether they are used or not. That makes site-wide stylesheets containing all fonts used on site pages difficult, since IE will always try to download all fonts defined in @font-face rules, wasting lots of server bandwidth.

    Further Resources

    Documentation

    Latest draft WOFF specification
    Original blog post on using @font-face
    CSS3 Fonts working draft
    MDC @font-face documentation

    Tools

    Jonathan Kew’s sample encoding/decoding code
    woffTools – tools for examining and validating WOFF files
    FontTools/TTX – Python library and tool for manipulating font data
    Web-based font subsetting tool

    General @font-face Examples

    CSS @ Ten: The Next Big Thing
    Example layout using Graublau Sans
    Examples of Interesting Web Typography
    The Elements of Typographic Style Applied to the Web

    Font Resources

    Font Squirrel
    10 Great Free Fonts for @font-face
    40 Excellent Free Fonts by Smashing Magazine

  7. a multi-touch drawing demo for Firefox 3.7

    Firefox Multitouch at MozChile – Drawing Canvas Experiment from Marcio Galli on Vimeo.

    A couple of months ago we featured a video that had some examples of multi-touch working in Firefox. At a recent event in South America, Marcio Galli put together a quick and fun drawing program based on the multi-touch code that we’ll have in a later release of Firefox. What’s really great is that he was able to put this together in just a couple of hours based on the web platform.

    There are three main components to the touch support in Firefox:

    1. Touch-based scrolling and panning for the browser. This allows you, as a user, to scroll web pages, select text, open menus, select buttons, etc. This is part of Firefox 3.6.

    2. Implement a new CSS selector that will tell you if you’re on a touch-enabled device. This is -moz-system-metric(touch-enabled). You can use this in your CSS to adjust the size of UI elements to fit people’s fingers. This is part of Firefox 3.6.

    3. Exposing multi-touch data to web pages. This takes the form of DOM events much like mouse events you can catch today. This isn’t part of Firefox 3.6, but is likely to be part of Firefox 3.7.

    Although not all of this will be in our next release we thought it would be fun for people to see what will be possible with the release after 3.6.

    Note: You can find the sample code on Marcio’s page for the demo.

  8. new device API for Firefox 3.6: orientation

    One new feature that we’re including as part of Firefox 3.6 is support for web pages to access machine orientation information if it’s available. As you can see from the demo above you can use it to figure out if the machine is moving and what direction it’s facing.

    Using the API is very simple. All you have to do is add a simple event listener:

    window.addEventListener("MozOrientation", function(e) {
                            /* 3 values: e.x, e.y, e.z */
                            }, true);

    Originally built as something that we would include for our upcoming mobile browser release, we’ve made it available on desktop systems as well. Many modern Macbooks and Thinkpads contain devices and drivers that expose this information. We’ve added support for Linux, Macs and some Thinkpads where drivers and devices are available. (Note, on some Macbooks detect the orientation information backwards – we’re working on that.)

    You can find more information on two posts by Doug Turner and an update on documentation for orientation from Eric Shepherd.

    Paul Rouget has this and some other demos up in one of his posts.

  9. 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 media1.com media2.com *.cdn.com; \
                               script-src trustedscripts.example.com

    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.

  10. WebGL in the wild

    This is a guest post by David Humphrey and was originally posted in his weblog. David is a professor at Seneca College in Toronto where he teaches and researches open source development and leads Mozilla’s education project. David’s been involved with WebGL well before it became WebGL and was just a Firefox extension. It’s nice to see that work making its way out of the experimental stage and already being used to solve real-world problems even before it’s officially shipped anywhere.

    I’ve been spending a lot of time lately thinking about 3D in the browser. It’s to the point that I have to blog about it, and try to get it out of my head and onto the web where it belongs. Part of the reason I’m writing this tonight is that my colleague, Cathy Leung, has just put up a demo so awesome I’m compelled to share it (video here):

    She put the video together after this article was written about her work to make 3D accessible to web developers via C3DL. Cathy has been working with a team of students at Seneca College for the past few years, focused on an experimental 3D technology created by Mozilla. Her work proves how valuable 3D in the browser can be. I think a lot of people misunderstand its significance: “Doom in the browser?” Sure, but it’s way more than that. There is no shortage of tea pots on the web these days, as various browser vendors start to show-off early releases of WebGL enabled builds. However, Mozilla has been at this game a long time. I know because we’ve been using their stuff as long as they’ve been building it. And it’s really reached a new level now.

    As Mozilla pushes WebGL further, and Cathy continues her work on C3DL, I’m focused on another project to harness the power of 3D in the browser. Together with Al MacDonald, I’m leading a Mozilla Foundation project to complete the work begun by John Resig to port the Processing language to JavaScript (aka processing.js). The processing.js port, while unfinished, is already amazing. Imagine if we took eight students, finished it, and added 3D support from C3DL? I know, exactly.

    Part of what makes me so excited about all this work is the deep intersection of things I love. I’ve long been a fan of the work of Processing creators, Ben Fry and Casey Reas, every since they were part of the Aesthetics and Computation Group. I’ve always thought that their work belonged on the web instead of on the desktop. At the same time, my own work with Mozilla and the open web has proven to me the need for richer ways of working with things like open data. The web is at an interesting point in its evolution. We now take for granted that it can do what was once only possible via desktop apps. Looking forward I can already see a time when the web will also be the proper medium of artists, designers, data visualizers, and others pushing the limits of the second and third dimensions. I’m thrilled to be a small part of this effort now.

    If you’d like to get involved with any of the work discussed above, please do get in touch with me. The most exciting aspect of everything I’ve told you remains that it’s all community developed, from Mozilla to C3DL to processing to processing.js. That’s how you build the software stack of the future.