Everyone remain calm

A lot of folks in the Mozilla community share the reaction Boris had to some deeply mistaken, tentative and now-aborted plans to remove View / Source and other “developer” features from Firefox. I wanted to point out that these plans were not made with agreement from me or, as far as I can tell, from Ben. First, let me just say that there is no way Firefox would ship without View / Source or any other UI that goes back to Netscape 1, and is therefore part of the “body plan” of browsers. Not while I’m around and involved, at any rate.

People dive into HTML all the time, copying and pasting, hacking, cribbing. View / Source is indispensable for such learning, not to mention for the kind of trouble-shooting all too frequently done by “end users”. My wife uses View / Source, and so do millions of others, whether or not they are “web developers” ™. You don’t have to be a Gecko hacker or even a paid web content designer to appreciate View / Source — far from it.

The web is the most popular and populist programmable content system ever created. There is no government-enforced monopoly, no union card, no web developer elite or cartel using arcane tools not available to mere mortals (well, there are plenty of would-be elites, and too many arcane and expensive tools, but web content can be, and often should be, written by hand). More than a few grandparents hack HTML and even JavaScript (not perfectly, but usually well enough).

The line between a “user” and a “developer” is soft and flexible on the web, and it should remain that way, lest some know-it-alls or business-suited sharpies lead us down an over-complicated, proprietary path.

Even in the early days of NCSA Mosaic, when there were ~40 servers in the world with content to care about breaking with incompatible browser changes, marca and ebina had good reason to tweak Mosaic’s layout engine to support known usage errors, some of which we now call “quirks”.

I cheerfully acknowledge that this is heresy, but their decision (insofar as it was a decision) was simply good economics, and it offered better usability or human factors design than a strict SGML purism would have afforded. Without tolerating human error of the sort tolerated in natural languages, I think it likely that the web would not have grown as it did.

Throughout the explosive growth of the web, View / Source has played a crucial role, hard to appreciate if you dumb down your user model based on myopic hindsight and a static analysis of the majority cohort of “end users”.

Anyway, I wanted to reassure everyone, from our top Gecko hackers to interested web developers to enthusiastic surfers, that Firefox is not about to implode into a bare-bones, ultra-minimalist browser that those important hackers, et al., can’t use. Firefox cannot be “all things to all people” without at least some people having to configure an extension or two, but the default features should support the crucial user bases.

There’s another point worth making about these late-breaking Firefox feature removal plans: it’s not wise to remove anything significant after Firefox 0.9, because removal has risks and opportunity costs — more marketing than technical to be sure — that we can’t fully assess in the time remaining before 1.0. If we can remove a buggily inadequate, vestigial feature such as offline support, perhaps. But certainly not View / Source, View / Page Info, or the JavaScript Console item in the Tools menu.

I’m willing to see DOM Inspector moved to an extension, based on its relative novelty and complexity compared to View / Source.

I’m increasingly skeptical about the wisdom of the alternative style sheet UI removal decried by Daniel, and I’ll make sure that feedback from the preview release on this removal is heard and fairly evaluated.

About Firefox UI: we’re trying something with both SeaMonkey and Firefox (and Thunderbird) now that couldn’t be done in the old days when Netscape paid most module owners, along with a good number of professional UI (or UE, they used to call it) designers: individually accountable product design leads.

Product design can’t be done well by committee, and SeaMonkey’s UI was always worse for the compromises, bloat, and confusion about its intended audience that resulted from past committees. No one was much or well empowered by any nominal share in such a committee or mob.

For SeaMonkey, which is moving into a sustaining engineering mode, and won’t be our premier product after Firefox 1.0, Neil Rashbrook leads the UI design and implementation.

For Firefox, Ben Goodger is the design lead.


Mozilla Developer Day Slides

The slides that shaver and I presented at last Friday’s Mozilla Developer Day are up now.

As presented at dev-day, these slides nicely demonstrated support for Apple’s canvas tag, embedded in Mozilla as <xul:canvas> and implemented using Cairo (a static PNG of the clock and animated stars must stand in for now, in the published slides, but you can view source to see the starbar.js script and related source). Thanks go to vlad and stuart for their heroic efforts hacking up <canvas> support.

As vlad pointed out, you can think of <canvas> as a programmable image tag. In that light, it’s reminiscent of the XBM images generated using <img src="javascript:genxbm()"> tricks developed by Bill Dortch back in the Netscape 2 era. All of which is to say, we really should have implemented this kind of tag in 1995, but both the management and hacker cultures then at Netscape deferred to Java for programmable graphics and other such features. What’s ironic is that this left most web designers reaching for Flash, not for Java, as the browser and Java-in-the-client wars played out.

The WHAT Working Group is considering standardizing <canvas>, with the goal of interoperating implementations based on the standard. My hope is that this is done both well, and quickly, in keeping with the WHATWG charter.

People ask about how SVG in Mozilla and <canvas> relate. The short answer is that they don’t, except that both must work well in all dimensions (complete and fast alpha-blending, e.g.) on top of a common graphics substrate, which looks likely to be Cairo.

A longer answer could compare and contrast <canvas>‘s non-persistent, procedural, PostScript-y rendering API with SVG’s declarative markup and persistent DOM. The upshot is that SVG and <canvas> complement one another, catering to fairly distinct requirements and authoring audiences.

One crucial fact to keep in mind: <canvas> support is tiny compared to the implementation of any known profile of SVG, so it will be easy to justify adding <canvas> support to default builds of Mozilla products. SVG should be supported in the same way as XForms and other, bulkier implementations of standards not yet seen much on the web: as a one-click download-and-install package that extends Gecko. I’ve asked top hackers to look into generalized support for such Gecko extensions, based on XTF, with versioning and update management a la Firefox’s extensions.

I’ll blog separately about the other points of interest raised in these slides.