Why Mozilla shouldn't implement SVG (or at least not too much of it), and what we should do instead (00:14 -0700)

One of the things that has made Firefox successful is that its development has been driven by the needs of users. Features that were helpful to users were added and features that were harmful to users (generally because they added more confusion than benefit) were removed.

In a sense a layout engine, the part of a browser that's responsible for displaying Web pages, has two sets of users: those who write Web content (authors) and those who read it (users, or end users when it might be ambiguous). When deciding what features to add to the layout engine, we need to consider both sets of users. Mozilla's layout engine actually has a third set of important users: those who use the layout engine for the development of non-Web XUL applications.

Adding features to the layout engine generally doesn't harm Web developers, since the existing ones (should) behave the same, and there's no user interface to clutter (except maybe the user interface of DevMo). However, adding features to the layout engine can harm users who are reading Web content if they give authors too much power over the user's experience.

I propose that layout engine feature development should (like that in Firefox) be driven by the needs of users: first by the needs of the end users who read Web content, and second by the needs of content authors. In other words, we should add support for new standards when they will lead to a net improvement in the user experience (not just an improvement in user experience in the rare case when they're used appropriately). Standards that make authoring easier generally do improve the user experience since they allow authors to work on other things, including writing more or better content.

Not surprisingly, I have a specific example in mind: SVG. I think the presence of SVG on the Web would generally harm users. The fundamental difference is this: HTML and CSS are based on the idea that the user has a default font size and that text should wrap when it doesn't fit, depending on the width of the document; SVG is based on the idea that the author determines the size of text relative to the size of the image and that all the text scales depending on the width of the document. If SVG were designed primarily to replace what is currently done using images (things like figures, graphs, and logos), that would be fine, and it would probably improve the user's Web experience. However, SVG is being designed to do much more than that and being promoted to replace what is currently done using HTML and CSS, to be a language for Web applications and their user interface. If it's used that way, I believe it will be more harmful to the user experience than helpful, since it will lead to Web pages being worse at adapting to different font sizes and browser window sizes and it will make the mechanisms the browser can use to overcome those problems (such as text zoom, which violates Web standards to improve the experience for users) less useful.

I think the reasons Mozilla chose to include SVG in the layout engine in Mozilla 1.8 (and thus in Firefox 1.5) were based largely not on the desire to see SVG on the Web, but the desire to use SVG as part of the Mozilla application development platform. In other words, it was included because people want to be able to use SVG's advanced graphics features when developing the user interface of Firefox, Firefox extensions, and other XUL applications.

Design and feature decisions for Mozilla's layout engine are generally made to serve two goals: being a layout engine for Web content and being a layout engine for an application development platform. These goals often conflict, and I believe they conflict in this case. (Another case where they conflict is fixing bugs in standards compliance. When we have a bug that other Web browsers don't, fixing it is the obvious choice, since Web content doesn't depend on the bug. However, if XUL applications depend on the bug, it can be much harder or even impossible to fix.) I think the goal of being an application platform has come to dominate the decision making process, both because it's easier to control (since authors are writing Mozilla-specific applications rather than cross-browser Web pages) and because most Mozilla developers have much closer connections to XUL application developers (who are very much a part of the Mozilla community) than they do to Web developers (who tend to hang out in other places).

As more Web technologies are incorporated into the application development platform and as the application development platform becomes more popular, these conflicts will only increase. I chose to work on Mozilla's layout engine because I was interested in the Web platform, not the application development platform. Thus I find I often disagree with the priorities of other developers and the direction our layout engine is headed.

I'd like to work on features that would help users, such as better layout systems that would make it easier for authors to design pages that scale better. The XUL box model is actually pretty good at this. After all, the XUL box model was based on existing ideas of user interface layout, and applications built using XUL really do work at many window sizes and font sizes (although, as with HTML, authors sometimes go out of their way to defeat this feature). I think the first steps of this work are figuring out better integration between HTML and XUL in Mozilla (since they currently interact in rather bizarre ways), and standardization of XUL box model. The first of these is one of the goals of the reflow branch that I'm currently working on.

However, I feel like there's no way I can do all of this myself or with just one or two other people who have lots of other things to work on. And there are lots of other things to do too: fixing crashes, memory leaks, and bugs, and developing other new features (but not too many). We just need more good developers working on the core of Mozilla's layout engine if it's going to continue to succeed: developers who can make good decisions about what specifications (and features within them) we should implement, can figure out what implementing those specifications requires, can decide what to do about the things that the specifications leave open, can provide good feedback to specification authors, can answer questions about what the existing code does by reading and testing it, can make good decisions about tradeoffs between code complexity and performance, and can write robust and correct code that is clear enough that it can be maintained by various people for many years.