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.

5 thoughts on “Interview: David Baron on Firefox 3 and W3C Standards

  1. I would like David Baron to reconsider his opinion about XForms by giving more than a few minutes of thought. He shouldn’t put much merit in rumours started by those who have a non-technical agenda either.

    He claims that XForms is dependent on numerous other complex specifications, yet everything upon which XForms depends is already available in the Firefox browser code. XForms uses XPath 1.0. I’m sorry, that’s just not complicated. Google put out a free javascript implementation years ago. An XForm may use a real XML schema, if the author decides to do so. This means an implementation needs a schema engine, but again those are freely available, so the effort to include that capability is measured in person days. XForms depends on HTTP and HTTPS for data submissions during the form run-time, but this is also already available in the Firefox browser due to Ajax. So, I don’t think this claim of David’s has any leg to stand on.

    David claims that XForms itself is complex. This also sounds like the FUD he got from someone else and is now passing on without any further effort. The most challenging piece of XForms to implement is the recalculation engine, which automatically updates data values based on declared formulae– just like a spreadsheet. Despite being a well-known 30-year-old technology, when I first joined the XForms group and suggested doing automatic recalculation, there was some pushback from people who said it would be too difficult to implement and that a spec would be required. I submitted the spec immediately, yet the reaction from the same folks was that the spec showed it was too complicated. This is what happens when one looks at text without actually reading it and thinking about it. Seeing that reasoning is preferrable to reaction, Mikko Honkala decided that arguing the point should take a back seat to simply implementing the specification. Guess what?!? His implementation was completed by the very next weekly teleconference, at which point the working group adopted automatic recalculation.

    Now normally, this is the point in discourse where I would ask “Surely, this isn’t too difficult for the Firefox implementation team.” But the simple truth of the matter is that ALL OF XFORMS is ALREADY IMPLEMENTED in a Firefox plugin. So, the question of implementation complexity is just more FUD.

    The final question, then, is that of demand. David says he doesn’t hear of enough demand to warrant it. How much have you looked, David? We ran a special session on XForms at XML 2007, and there wasn’t enough space in the conference room for all the people who showed up. A similar XForms event held in London the year before sold out in two days. XForms demand is swelling very rapidly in government, insurance, financial and healthcare web applications.

    These industries don’t scream out “Give me this technology or that technology”. They demand solutions for their complex technical problems, and XForms provides the solutions. It solves hard web application problems by making them easier to implement and maintain. The role of the web browser maker is supposed to be to make it easier for web application developers, not easier on themselves by passing along the complexity to web application developers. I would like the Firefox team to regain that focus and reconsider offering XForms support natively in the FF browser.

    Meanwhile, the demand for XForms is such that IBM has decided not to wait for web browser makers to define the web. Just as Ajax libraries like Dojo are coming to define the new face of web application development, IBM is teaming up with Backplane Ltd to offer the Ubiquity XForms processor, a new Ajax library aimed at making XForms available on all web browsers. Development is well underway, and within the next two months, there will be an Apache-licensed XForms processor that works in IE (which means Opera too, right Opera guys?), Firefox and Safari. Come find out more about this open source project here: http://code.google.com/p/ubiquity-xforms/

  2. Hi,

    XML has become a ubiquitous language, and Firefox was an early supporter of it.

    Which makes me wonder why https://bugzilla.mozilla.org/show_bug.cgi?id=22942 (with 75 votes) on supporting external DTDs is still unresolved. While external parsing of the DTD may not be a universal requirement for XML parsers, the defining of one’s own entities in an external document is extremely common, convenient, and is even used internally within Firefox itself! The lack of predefined entities suggests such use would be common. Moreover, the modularization and use of true XHTML (which Firefox was early to support) is hindered by not being able to customize entity definitions with an external DTD. Yet because of this bug, these frequently used documents which rely on external DTDs, when parsed by Firefox, fail.

    I know there is mention in the Mozilla bug reports and elsewhere about “what is good for the web” not always coinciding with official standards and questioning of the balance due to a lack of web-oriented companies on the standards bodies. Regardless of the degree of validity of these arguments, I hope it is not used as an excuse (akin perhaps to how criticisms of the U.N. are used to justify exceptionalism by member countries).

    In any case, with such a common staple as XML, I think it is also unnerving to see a false dichotomy made between web and other uses. Supporting a meta-language fully does not inevitably portend balkanization and deviance from standards as some suggest–it enables the development of useful new standards, including for those of us using or developing for the web. And why should excellent, already popular XML languages like DocBook, TEI, etc. be relegated to (often non-free) programs off of the web?

    To my mind, this basic support should even trump attention to the more flashy features (some of which can themselves benefit from DTDs, which is not to even mention schema support).

    thank you

  3. I’m in the IT industry but not a professional web developer. Three years ago I began playing with XML-based technologies and am now a novice with XPath, XSLT, XML Schema, XHTML, SVG and recently XForms. I’m happy to see the strong support in Firefox-3 for improvements to SVG and CSS. But Mr. Baron’s comment about XForms is extremely disappointing. XForms truly does make it easy to develop a sophisticated user interface application for the web. I was amazed how easy it was using just a text editor and then seeing it work in Firefox-2 with the XForms “preview” add-on.

    Thank you Mr. Boyer for your comments. I enjoyed reading them, because I too sense that there is a need (an unrealized demand) for something this practical and easy to use. I’m baffled as to why such a great W3C specification like XForms is taking such a painfully long time to gain momentum. Glad to hear about Ubiquity XForms. It would be a real shame if Mozilla decides (has already decided?) not to support XForms in Firefox.

  4. I have to admit that I gave up on XForms and TEI etc long ago. I put my first electronic edition up using TEI standards, but now with the state of the source code that Google Books is putting out I’m a little disillusioned and decided to put my PhD out in plain old vanilla HTML

  5. I am just beginning to work with XFORMS, but it seems an incredible step in the right direction away from the old html forms. It puzzles me as to why you guys would not enthusiastically support it, building native capacity within the browser. It is what would differentiate Gecko/FF from the others, and sustain the impression of supporting key W3C recommendations. I think the demand will express itself forcefully in a year or so. Indeed XForms capability may make or break browser loyalty in coming years.

Comments are closed.