Interview: David Baron on Firefox 3 and W3C Standards

At the news of the official release of Firefox 3 (FF3), I asked David Baron, Mozilla's Advisory Committee Representative at W3C (see photo), a few questions about the browser release and support for standards.

Note: I anticipate interviewing (lots of) other W3C Members about their involvement in W3C work and support for standards in products. Next week: Opera, on its recent browser release.

Q. So is the rumor true that Firefox 3 implements every W3C Recommendation perfectly?

A. No.

Q. Rats! Well, let's continue anyway. Your list of favorite changes mentions some changes related to CSS. What are some that you think authors will like in particular? Are there some noteworthy changes that will make cross-browser authoring easier? Can say a word about Mozilla's priorities in CSS support for the next year or so (and how they align with those of the CSS Working Group)?

A. Some of the ones I think authors will be most interested in are inline-block and inline-table, font-size-adjust, rgba() and hsla() colors, new values for width, min-width, and max-width, and white-space: pre-wrap. These are the ones I mentioned in that post.

One of the top things that will ease cross-browser authoring is inline-block. But a larger part of the work in easing cross-browser authoring is really the large numbers of small bug fixes that have gone into this release.

As far as priorities for CSS support go, we want to continue improving conformance to CSS 2.1. Fixing bugs in the details makes it more likely authors will find the same behavior in different browsers in real-world use of the specifications.

We're also looking at adding a bunch of additional features over the next year. It's hard to know which features will end up in which release because we don't really know how hard they are or how long they take to implement until we try. But some of the things we're looking at or working on are downloadable fonts (both OpenType and SVG) through @font-face, allowing some CSS properties from SVG (like clip-path, mask, and filter) to be used with other languages, new graphical properties like text shadows, border images, and box shadows, implementing CSS media queries, the remaining selectors in css3-selectors, some of the new functions in css3-values like calc(), and Apple's proposal for CSS transformations, and standardizing and improving the flexible box model that we use to construct the user interface of Firefox and other Mozilla-based applications. I think these align reasonably well with the priorities of the CSS working group, which is actively working on the specifications in many of these areas.

Q. I read that there are several security-related changes (phishing, malware). Mozilla is participating in the W3C Web Security Context (WSC) Working Group, chartered to address this sort of thing. Are FF3 updates influenced by the work of that group (or vice versa)?

A. Since this isn't in my area of expertise, I asked Johnathan Nightingale, who represents Mozilla on that group, for his answer, and he wrote:

Yes, there is definitely influence in both directions. The WSC is an interesting group because it's chartered with tackling things like UI guidelines that have not traditionally been the W3C's focus; that creates a really interesting tension between people who want to document and standardize best practice, and people who want to change the world. We try to pull the group towards the middle, towards a document that can set a good baseline and a high bar for future implementors. The security of users on the web is very important to us, and using this group to make user interfaces more intelligent and more human can help keep people safe, regardless of which browser they choose.

Q. Does FF3 ship with XForms in the default configuration? If not, is there a reason we should be aware of?

A. No. It's a complex specification that depends on a number of other complex specifications. We haven't seen enough demand for it to balance the cost of writing, testing, offering for download, and permanently supporting the code needed to implement all of these.

Q. Can you comment on the state of SVG implementation in FF3?

A. There are a bunch of new SVG features in Firefox 3: see SVG improvements in Firefox 3 for details. One of the highlights is that we now support putting HTML inside svg:foreignObject.

Q. Mozilla has been very actively involved in the work on the W3C Access Control for Cross-Site Requests draft specification, which provides a way securely make cross-site requests over the Web -- for example, cross-site XHR/Ajax requests. Are you still supporting that work? And if so, can you say a bit about why it's important?

A. Definitely. This spec gives sites a way to opt-out of cross-domain access restrictions for public data or other data that they wish to share with other sites. This is a big step forward in allowing Web sites ("mashups") that mix data from different sources to be built easily and securely.

Q. You are a developer. There is a new feature in a draft specification, when do you start to implement it? How do you proceed? What are the steps of modifying the source code of the browser? I've seen Tantek Çelik modify source code at the dinner table, for example.

A. Well, we're always thinking about what we can do to improve the Web. If there's already a solid specification for what we need, that makes our work easier, but if there isn't we can contribute to writing one. If there are already other implementations, that means there's a shorter path to our implementation being usable by Web authors. So implementation doesn't always start from seeing a feature in a draft specification.

When I start implementing something, my first step is to understand how the feature works and how it interacts with all the other features we implement. This leads naturally either to writing tests, or to designing and writing code. Both need to get done before the feature is complete. For more complex features, there's often more planning and coordination required, since when more work is involved, the time spent planning can save more time later from not having to redo things that were done wrong.

When you see Tantek writing code at the dinner table after a working group meeting, it probably means he already understands the feature well from working group discussion earlier in the day, and probably did at least some of the design in his head during the discussions. It's likely that he's just doing the typing (and the debugging) for a design that he already has in his head.

Q. Some W3C groups receive a lot of comments on specifications, and the more stakeholders the more comments. What changes have you observed at Mozilla with the growth of Firefox?

A. I think open source projects are quite different from the W3C. One of the guiding principles of open source software is that anybody has the source, and thus the ability to take that source and build a better product using it. This means we try to choose to use or ignore input depending on whether we think using it is the most efficient way to improve the software we make. (This applies in the long term, too: encouraging and taking input from new contributors can make us better in the long-term even if it costs us time or even bugs in the short-term.)

This is very different from the W3C, where groups have an obligation to respond to comments, whether or not they're going to improve the specification, or even whether or not they're intended to improve the specification.

So with the growth of Firefox, we do have a lot more people involved than we used to, which means more progress is happening at once. But there's still a relatively small group of people at the center who make the core architectural and planning decisions. I think in some cases these people do more filtering than they used to.

Q. Based on FF3 experience, are there any particular issues that you would like W3C to address as a priority?

A. It's hard to point out one or two particular issues, though one that comes to mind as particularly important is the lack of a widely-acceptable royalty-free video codec that can be used for interoperable video on the Web.

More generally, I'm glad to see W3C actively working to improve and complement the core Web specifications, like HTML, CSS and the DOM, that we already implement and that form a foundation used by most Web pages. I like seeing solid specifications and test suites that improve the Web as a platform as effectively as possible.

Q. The W3C community is currently discussing starting work on "Geolocation" at W3C, with a goal of creating an API that will expose device location-sensing capabilities (for example, GPS data) to Web applications. If work starts, would Mozilla get involved in that work? If so, what do you see as being important about it?

A. A number of people at Mozilla have already been participating in the discussion, so I think we're already involved.

One of the great things that having the Web available on mobile devices can provide is the ability to quickly get information about where you are. But entering location information, potentially without a keyboard, can be slow (and inaccurate, especially if the user is lost and looking for maps). A user who can click a button or two to send location data to a Web site has a faster and easier path to finding local maps, nearby restaurants, train schedules from the nearest station, or other location-specific information. And there's no reason this faster path wouldn't be useful for laptop or desktop users too.

Q. I sometimes read and hear people mentioning "mozilla-central". What is "mozilla-central" and what changes has it brought to the work on Firefox and Mozilla?

A. We've switched version control systems, from CVS to mercurial, which is a distributed version control system. Distributed version control systems have a lot of advantages over CVS, such as much better ability to work offline and better mechanisms for collaboration. mozilla-central is just the name of the mercurial repository in which we integrate changes for future releases of Mozilla. Work is pushed to the mozilla-central repository when it's thought to be close to the quality level it needs to be to be in a shipping release. (Sometimes, of course, it turns out that something isn't as ready as its author thought.) We generate our main nightly builds from the code in mozilla-central.

Many thanks to David for his answers.