Eyes Above The Waves

I'm going offline from Wednesday afternoon to Saturday --- 10th wedding anniversary.

I'm excited that FF3.1 should be released well in advance of IE8; of course, we have serious competition from other directions :-). The layout blocker list for 1.9.1 is currently at 51 bugs. However, 23 of those bugs are fixed by patches that are ready to land as soon as the tree reopens after beta2. Several other bugs have patches awaiting review. So I think we're in quite good shape heading towards the final release. On the other hand, video/audio currently has 15 blocker bugs --- partly because the spec keeps changing. We're definitely going to go down to the wire in that area. But overall I'm feeling more comfortable heading into the end-game than I ever have before. I think a few factors have contributed to that: great test infrastructure over the entire development cycle, no huge architectural changes in this cycle, and more development manpower.

We had a big discussion over the last couple of weeks about whether to restrict <video> and <audio> elements to playing media from the same domain by default (with Access Controls to let servers opt in to greater permissiveness). The result was to allow it, with a few caveats.

Karl Tomlinson has CSS @font-face "src:url()" downloaded fonts working with GTK/Pango/Freetype, and should be landing right after beta2. (@font-face "src: local()" isn't done yet but should be soon.) The integration is deep; ligatures, kerning and other shaping features are supported to the full extent Pango allows. It's also integrated with fontconfig although the best way to interface with fontconfig is not obvious.

One semi-controversial issue is what to display while a font is downloading. Should we display nothing, as Safari/Webkit does, or should we display text from the fallback font (e.g. the font used by a non @font-face-supporting browser)? There are arguments both ways.

It's summer so that means interns are arriving (hi Michael!). We've also got Jonathan Kew visiting from the UK. Jonathan's working on integrating Core Text into Gecko; Apple promises performance wins, so it'll be interesting to see how that works out. In any case we'll need it sooner or later since key parts of ATSUI won't be available in 64-bit Mac. It shouldn't be hard to support both ATSUI and Core Text, even switching at runtime depending on the OS version. I'd like to get that into Gecko 1.9.2.

There's a lot more interesting font and text work to do. We're running into limitations of platform shaping APIs. For example, we want to expose CSS properties that let authors control the use of Opentype features, e.g., to control the kinds of ligatures that are used --- already in Firefox 3 we've found that there's no ligature setting that satisfies all authors. Another problem with platform APIs is that we have performance-critical optimizations that depend on assumptions like "fonts don't perform contextual shaping across ASCII spaces" and "insertion of line breaks doesn't affect shaping". These assumptions could be wrong, so we need to be able to tell when they're wrong and turn them off when necessary (and only when necessary) ... but platform shaper APIs don't give us this information.

It seems like a promising way to go is to invest in Harfbuzz, first to use with GTK instead of going through Pango, then to ship and support on Windows and Mac as well. The second step is not trivial since we will have to make it play well with platform rasterizers (GDI and Quartz) without significant performance overhead. But it should let us solve the above problems and create new opportunities, e.g., the ability to add support for whatever Opentype features we desire. For various reasons we'd want to continue supporting Core Text and Uniscribe for fonts and scripts that Harfbuzz doesn't support well.

There are lots of other exciting things to work on for 1.9.2. SMIL, SVG fonts and SVG images (<img> and CSS background-image) are high on the list, along with low-hanging CSS3 features like background-size, multiple backgrounds, maybe text-overflow. I think we'll see more work on deep architectural improvements than during the 1.9.1 cycle, although some of those will probably be too deep to actually make 1.9.2, assuming we keep it tight like we have for 1.9.1 --- I think we should!

One deep project is memory management. I fantasize about a world without refcounting and the cycle collector, having JS objects and C++ objects living in the same heap, with concurrent mark and sweep collection. I don't know how realistic that is but I hope we find out.

Amid all this, one thing that focuses me:

From everyone who has been given much, much will be demanded; and from the one who has been entrusted with much, much more will be asked.