Wednesday, 26 November 2008


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.

Thursday, 6 November 2008

The Essence Of Web Applications

One theme for Web platform improvements over the last few years has been stripping away the limitations that have characterized Web applications compared to desktop applications. So we support drag-and-drop, we compile JS to machine code, we offer fancy graphics, we let Web apps run offline, we give them writable local storage. A natural question is: what, if any, are the essential differences between Web apps and "desktop" apps? Will they converge completely?

I don't think so. Here are features of Web apps that I think are essential:

  • URL addressing You access a Web app by loading a URL. You can link to Web apps from other Web pages, you can save URLs in bookmarks or desktop shortcuts, and you can pass around URLs to your friends.
  • Always sandboxed Users are not able to make good trust decisions, so apps must always be sandboxed. One of the themes of Web platform evolution is finding ways to design APIs and browser UI so that we can safely grant access to platform features to untrusted apps. For example, Web apps can't be granted general filesystem access, but we can satisfy most needs with per-domain persistent storage and and the trusty <input type="file"> control to grant an app access to particular files.
  • Browser chrome Web apps are used in the context of a browser. Forward and back buttons are available (and usually work!), providing a universal navigation UI across applications. Bookmarks are available, status is available, history is available, reload, stop, tab organization, etc. A lot of designers wish they could escape from the browser chrome, but sandbox requirements make that unrealistic, and the comfort of common browser UI should not be disregarded.
  • Open box Web apps have internal structure that is exposed to the browser and to tools based on the browser. This enables tools like Greasemonkey to reach into and manipulate Web content. It enables browser features like text zoom and "find in page". It enables search engines. It allows for user style sheets and other kinds of end-user customization of the Web experience. It also creates an environment of pseudo-open-source-software, where authors can learn how other apps work, even if they can't modify or reuse that code directly.

Tuesday, 4 November 2008

Grumble Grumble

I've been hacking up an implementation of interruptible reflow. Laying out large pages is sometimes a source of unacceptable delays. It would be a better user experience if, during a long layout, we could detect that there's pending user input, get out of the layout code, handle the user input, and then resume the layout. In principle this isn't that hard now that we use dirty bits to track what needs to be laid out. It's simply a matter of making sure the right dirty bits are set as we bail out of reflow, and then making sure we enter reflow again eventually to complete the unfinished work. We also have to make sure we accurately distinguish "interruptible" reflows from "uninterruptible" reflows. For example, if a reflow is triggered by script asking for the geometry of some element, that's uninterruptible since returning with some work undone would give incorrect results and break things.

I have a patch that basically works, at least for pages that are dominated by block layout. But I've run into a severe problem: I don't know how to detect pending user input in Mac OS X or GTK :-(. On Windows, for about 20 years there's been a function called GetInputState which does exactly what we need. OS X and GTK/X11 just don't have anything like it. I've tried Appkit's nextEventMatchingMask; it sometimes processes some events, which is unacceptable. X11 doesn't seem to provide a way to peek the event queue without blocking; the only nonblocking event queue reading APIs always remove the event from the queue if they find one.

OS X and GTK suck, Windows rules. Prove me wrong, fanboys!