A Small Example Of The Value Of Browser Engine Diversity

Today there's an email to the www-svg list which illustrates perfectly the value of browser engine diversity. This kind of thing happens all the time.

To be clear, browser engine independence pays off here because it tells the Web developer that there is a real choice of behaviors. The developer can say "oh, that behavior is definitely better" instead of just "oh, how strange". It also gives us implementors confidence we can change the behavior since Web content (if it's been tested in multiple browsers) can't be depending on one particular behavior. It also tells us that the Web developer's preferred behavior is actually implementable.

And Then There Were Three

The news about Opera switching to Webkit is disappointing. It's a sad day for the Web, since I thought highly of their Presto engine and their Web standards work. Their impact on Web standards will be dramatically reduced, especially where they want to do something differently to Apple and Google. The big loss for the Web is a further decrease in the diversity of browser engines, especially on mobile devices. This means that our work at Mozilla simultaneously becomes more important --- we now have one of the three viable browser engines, instead of one of the four, and engine diversity is already critically endangered --- and more difficult, because this will strengthen the Webkit mobile monoculture and make it even harder for us to promote Web standards over "coding to Webkit".

Some people are wondering whether engine diversity really matters. "Webkit is open source so if everyone worked together on it and shipped it, would that be so bad?" Yes. Web standards would lose all significance and standards processes would be superceded by Webkit project decisions and politics. Webkit bugs would become the standard: there would be no way for developers to test on multiple engines to determine whether an unexpected behavior is a bug or intended. It wouldn't be the worst possible outcome --- victory of a closed-source engine would be worse --- but it would be a far cry from the open Web goals we've been striving for.

So, back to work!

Waiheke Island Sculpture Trail

Yesterday was a public holiday and the weather was brilliant so our family went to Waiheke Island for a walk and to check out the sculpture trail that's currently in place there. We discovered that thousands of other people had the same idea --- the ferry terminal was by far the busiest I've ever seen. Three cruise ships being docked downtown probably had something to do with it! We had to wait for about an hour to get on a ferry, which was annoying but it gave us an excuse to talk to the strangers around us, which was great.

Once we finally reached the island about 11:45am we did a long-ish route from the terminal at Matiatia, to Oneroa beach on the north side of the island, across to Blackpool on the south side, past the Piritahi Marae, across the hills to Church Bay on the west side, and then around the coast north back to Matiatia. It was hot and sunny but we were able to walk in the bush or in sea breezes most of the time so it was very pleasant. The sculptures were a lot of fun. We got back to Matiatia around 4:15pm.

The other major walk option at the west end of Waiheke is to walk along the coast from Matiatia north and east to Oneroa. When the sculptures aren't in place I'd say the northern walk is a bit better --- although if you're a gourmand with plenty of spare cash, the southern walk has the option of stopping at Mud Brick restaurant for lunch, which is pretty great. (We didn't do that yesterday, but I went there on Novell's budget once.)

SVG In OpenType: A New Approach To SVG Fonts

OpenType is the industry standard font format. This is good. However, OpenType fonts severely limit what can be drawn in a glyph: basically, you can fill simple paths, and that's it. Some use-cases, e.g. fonts for emoji, require colored and even animated glyphs. SVG is the vector graphics format for the Web platform, so it makes sense to support SVG content in glyphs. The SVG Fonts spec defines a non-Opentype SVG-based font format which in theory lets glyphs contain any SVG content. However, this format has some deficiencies that I believe make it unsuitable for the Web:

• SVG Fonts have very weak shaping support, which makes them unusable with Indic and other languages. A solution which is unusable by a large fraction of the world's population is inadequate for the Web.
• As a side effect, SVG Fonts do not support advanced typographic features that are offered by OpenType and are being exposed to Web authors via the CSS3 Fonts spec (e.g. stylistic alternates).
• SVG Fonts have a somewhat broken model for how style on the text affects rendering of the glyphs: CSS style inherits directly from the text to the glyphs. This is difficult to implement in a performant way, and doesn't do what authors expect.

The Web needs an approach that overcomes these problems.

Introducing SVG Glyphs In OpenType!

We propose to extend OpenType with support for glyphs consisting of SVG content. A new "SVG" OpenType table is defined, containing one or more SVG documents, each of which contains one or more glyphs. It's almost as simple as that! SVG glyph documents are subject to the same restrictions as SVG image documents, i.e. animation is supported but not scripting or external resource loads. CSS style is not inherited from the text to the glyphs; instead, the stroke and fill property values of the text are available in the glyphs document as new CSS values "context-fill", "context-stroke" etc. (These new values would also be useful with other SVG features such as markers.)

This proposal has been implemented in Firefox. It's disabled by default (in order to not pollute the Web with our not-yet-standardized implementation), but can be enabled by toggling gfx.font_rendering.opentype_svg.enabled in about:config (test page here). The only significant missing feature in our implementation is that animation is not yet supported. There are some bugs :-). Currently "context-fill" etc are named "-moz-objectFill" etc.

This approach has some nice advantages:

• Very simple spec and implementation. This proposal only affects glyph rendering. Shaping relies entirely on existing OpenType features, so there is nothing to say about that in the spec, and nothing new to implement. An intern was able to design and implement most of this feature in a few months with no prior Gecko experience. (Thanks Edwin!)
• No way to mutate the glyph DOM, which simplifies implementation considerably.
• Full power of OpenType shaping available, including support for every script supported by OpenType, which is to say almost all of them. In theory this should also "just work" in fonts that use Graphite, an alternate, more extensible shaping engine for OpenType.
• Powerful ability to customize the stroking and filling of glyphs based on stroke and fill properties of the text.
• Fallback to regular OpenType glyph rendering for renderers that don't support SVG glyphs, and also if we need to obtain the outline of a glyph as a path (e.g. for <canvas> addText()).

We'll be working with other vendors like Adobe (who have a similar proposal) on the public-svgopentype mailing list to converge on a standard as soon as we can.

Thanks to Edwin Flores for doing the implementation work and Cameron McCormack for helping design the feature and write up the spec.