hacks.mozilla.org

Archive

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.

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.

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.

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!

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