A short post on this topic.
Alexander Limi has a post describing a simple way that web sites could improve their performance: by putting images, css and other static resources in a .zip file for downloading. He’s asking for feedback on the topic. If the feedback is good we’re likely to try and get this implemented for Firefox 3.7.
If you’re a web developer and you have a comment, please put it in his weblog post. Thanks! (Comments are closed here.)
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.
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
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.comExample 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.
The ever-energetic Felipe Gomes was nice enough to intern with Mozilla this summer in between busy semesters in Brazil. During that time he’s been working on multi-touch support for Firefox on Windows 7. A nice result of that work is that he’s also found ways to bring multi-touch support to the web. He’s made a short video and written up some short technical information to go with it.
This post has also been cross-posted to Felipe’s personal blog.
I’ve been anxious to demonstrate the progress on our multi-touch support for Firefox, and this video showcases some possible interactions and use cases for what web pages and webapps can do with a multi-touch device.
We’re working on exposing the multi-touch data from the system to regular web pages through DOM Events, and all of these demos are built on top of that. They are simple HTML pages that receive events for each touch point and use them to build a custom multi-touch experience.
We’re also adding CSS support to detect when you’re running on an touchscreen device. Using the pseudo-selector :-moz-system-metric(touch-enabled) you can apply specific styles for your page if it’s being viewed on a touchscreen device. That, along with physical CSS units (cm or in), makes it possible to adjust your webapp for a touchscreen experience.
Firefox 3.6 will include the CSS property, but is unlikely to include the DOM events described below.
Here is an example of what the API looks like for now. We have three new DOM events (MozTouchDown, MozTouchMove and MozTouchRelease), which are similar to mouse events, except that they have a new attribute called streamId that can uniquely identify the same finger being tracked in a series of MozTouch events. The following snippet is the code for the first demo where we move independent <div>s under the X/Y position of each touch point.
var assignedFingers = {}; var lastused = 0; function touchMove(event) { var divId; if (lastused < = 4) return; if (assignedFingers[event.streamId]) { divId = assignedFingers[event.streamId]; } else { divId = "trackingdiv" + (++lastused); assignedFingers[event.streamId] = divId; } document.getElementById(divId).style.left = event.clientX + 'px'; document.getElementById(divId).style.top = event.clientY + 'px'; } document.addEventListener("MozTouchMove", touchMove, false); document.addEventListener("MozTouchRelease", function () { lastused--; }, false);
On the wiki page you can see code snippets for the other demos. Leave any comments regarding the demos or the API on my weblog post. We really welcome feedback and hope to start some good discussion on this area. Hopefully as touch devices (mobile and notebooks) are getting more and more popular we’ll see new and creative ways to use touch and multitouch on the web.
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.
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.
