First, let’s start with the awesome dichotomy. You start with this:

My god, what a beautiful thing. They are the web. I love that. I could have written it myself. I should have written it myself.

That classic Apple dark headline and light grey subtext that everyone loves. And the text: standards, CSS, JavaScript, web designers, puppies and rainbows. Who could possibly disagree with that? From a marketing perspective, it’s beautiful – non-specific, feels good, it means that Apple loves the web, and loves you.

But how do they prove it?

That’s right. If you’re not on Safari, then Fuck You.

Aside from the incendiary language I’ve used to help you understand how it feels the real underlying message here is that if you don’t have access to Safari then you must not have access to HTML5. Wait, only Safari supports HTML5??

Nope, lots of browsers do. A huge percentage of the world does have access to standards like HTML5. Today. In fact, given the page says html5, you might ask, who has the best html5 support across the browsers right now? Not Safari. Not Chrome. The browser that also happens to have a lot of market share – Firefox:

(The best overall site that gives you useful information for this stuff is actually one that a lot of people don’t use, but should: caniuse.com lovingly maintained in his own time by Alexis Deveria)

Of course, the big problem is that html5 has come to mean a lot of things, mostly thanks to Google. They’ve basically been riding that and flogging it and making it their own. (That and performance – simple, great marketing messaging. I appreciate it, even if the dishonesty of it makes my blood boil.)

And I’m sure that this entire apple site is a result of exactly the same problem we’ve been struggling with at Mozilla as of late. This is best described by a recent experience that we had from a candidate that came in to interview. He asked:

Hey, are you guys ever going to support html5?

Like, what? Are you fucking kidding me? Truth that marketing works. The perception-to-reality gap is giant.

I’m sure this was Apple is having exactly the same problem. Basically they are saying internally “omg, no one thinks we support html5, we need to prove them otherwise! We’ll put up tests! Demos! The world will then know and we can go back to being perceived as actually leading the WebKit project which is also made of puppies and rainbows!”

So you end up with sites like this. Sites that entirely miss the point of the web, interoperability, standards and html5. The demos that they put up are just filled with stuff that Apple made up, aren’t part of HTML5 and are only now getting to the standards process. Part of CSS3? Kind of, sort of, but under heavy development and still in a feedback process.

Let me be clear. I’m being snarky here essentially to get your attention. Because this is actually important. And if there’s one paragraph you should read here it’s this one:

The most important aspect of HTML5 isn’t the new stuff like video and canvas (which Safari and Firefox have both been shipping for years) it’s actually the honest-to-god promise of interoperability. Even stodgy old Microsoft, who has been doing their best to hold back the web for nearly a decade, understands this and you’ll see it throughout their marketing for IE9. (Their marketing phrase is “same markup” – watch for it and you’ll see it everywhere in their messaging.) The idea that the same markup, even with mistakes, will be rendered exactly the same. HTML5 represents the chance for browsers to work together and find common ground.

Before people misunderstand me, this is different than the question of how we innovate in browsers. Standards are part of that process, but standards follow more often than lead. HTML5 contains lots of new stuff that isn’t in IE, so it looks innovative, but most of HTML5 is like breathing to Mozilla. We’ve been doing that stuff for years. We’re more interested in what’s next at this point.

But it’s unfortunate, and I guess inevitable, that browsers would compete on how much html5 they are bathed in. But it’s important to ask: when you see someone making a claim, what does it really mean? Is that a made up test by a vendor? A demo of something that goes well beyond the standards that exist? (Tons of room for that, but it should be labeled as such!) Is it a test that is designed to show off other browser’s bugs in a meaningful and constructive way? Does the person running the tests know what they are doing and respond to constructive comments?

Apple’s messaging is clearly meant to say “hey, we love the web” but the actual demos they have and the fact that actively block other browsers from those demos don’t match their messaging. It’s not intellectually honest at all.

Since you made it this far I’ll make a promise. I can’t go back and fix the past, but I can help propose a new future. I personally end up driving a lot of the messaging that comes out of Mozilla (although maybe I won’t be after this post!) I promise that:

• I’ll be as honest as I can be about what we’re doing, what it means to other browsers and even to the new darling brand of the web: html5.
• I’ll work to make sure that demos that Mozilla does work in as many browsers as possible, even with graceful fallback.
• Demos or messages that are meant to show off stuff that’s not part of any standards process at all will be labeled as such.

HTML5 is in a dangerous place since everyone wants to own it, but everyone is in a different place in terms of support or even what it means. I can’t promise what other organizations will do, but I can at least say what I will do in the future. At Mozilla, intellectual honesty matters and it matters to me personally. So I don’t think you’ll see us do things like this in the future. To us, the web and its users matter more than any particular standard or browser. And you’ll see that reflected in messaging that comes from me and shows up as marketing.

Ryan points out that there are significant differences between what Google has built here and what we’ve built. I thought it might be worth it to expand on that a bit since it isn’t explained in depth in the Ars article.

Google’s 3D work is a plugin.  So much like how Flash or Silverlight works you get a rectangle in the browser to draw into.  They provide a high level scene graph API which uses the COLLADA format for loading objects underneath.  It’s a very large chunk of code.  If you take a look at the API and click around at the packages and classes you can see that there’s a lot there.  Their use case is games and game-like things – virtual worlds.  So it’s a great piece of work, but it’s also at a very high level.

Mozilla’s current proposal to Khronos is a very simple API that’s a wrapper around OpenGL ES 2.0.  It’s currently available as an extension to Firefox 3.5 and is likely to be rolled into a version of Firefox after 3.5.  The proposal is very focused on 3D.  For example, we didn’t try to include video or audio because those are being covered by other web standards and we’re interested in making sure they are well integrated instead of trying to wrap those into a 3D spec.  We’ve bound it to the canvas element so you can use it in much the same way you use the current canvas 2D context.  Things like asset loading (via COLLADA or other systems) are things we haven’t dealt with because those can be handled entirely outside of the 3D api and layered on top of it.  (Later in this post you’ll understand why this is important.)  But the important thing is that it’s something that you can easily mix with the rest of the open web.  Open Video and Audio, CSS, HTML, Canvas 2D, Canvas 3D, etc – you should be able to mix them all together and that’s our goal.

So these two 3D things from Mozilla and Google are pretty different.  Not really competitive, either, because they have such different goals.  The Google software is a very high level API 3D graphics API and what we’re proposing is more akin to the low level graphics API that those high-level systems are built on.

Given the title of the google blog post (“Towards an open web standard for 3D graphics”) it’s important to point out these differences since they affect how the standards process might look, and what the output might be.  We’ve been through this a few times with different standards and it’s easy to point out what the key success factors are to build a successful standard.  Here’s a quick iteration on those principals in my mind:

1. It’s important to keep the scope as small as possible.

The smaller the scope of the standard, the easier it is to understand the interaction of the various parts, what your goals are and what it takes to build an interoperable implementation.  It’s also the easiest thing you can do to remain as future-proof as possible.  It’s easier to add new APIs later if your scope is very very small.

2. Clear rules for interaction with the rest of content.

How does it work with the rest of the HTML spec?  CSS?  Video?  Images?  How can you copy content in and out?  Can you use them as textures?  These are just some of the questions that you have to raise as a way to describe how something like this might work with content.  Once again, this is gated on #1 above – if the functionality is simple then the interactions can generally be pretty simple as well.

3. Allow the scope to change slowly over time.

Understanding that technology – especially on the web – does not exist in a vacuum outside of time.  Standards do change over time and understanding how people use technology in the real world is the best possible way to understand how something should change and improve.  Understanding that standards are an iterative process is important.  Note that in #1 above – controlling scope – I mention that it’s important to keep things future-proofed via small and simple APIs.  This is why – because you know that you will need to improve that API once you understand how people are using it in the field.

4. Allow most of the innovation to happen next to and on top of your API.

Last point – your standard should allow as much iteration and work to happen on top of your API as possible.  This allows you to learn as much as possible about how people are using your software and gives them huge amounts of freedom to experiment and teach you about what you need to improve in the next iteration.  If people are stretching your APIs and finding gaps in performance, you can add convenience APIs to make things faster – as long as they are simple APIs.  We saw this in the real world with the JS libraries (dojo, jQuery) – we’ve been optimizing our engines and APIs over time to assist them as they have pushed our browsers to the limits.  But we would not have known had we tried to implement everything that the libraries could have possibly done at the browser level.

OK, so those are the things that we think make for a successful standards process.  I’ll point out one particular example of a dichotomy that I believe illustrates these rules so that people understand what I’m talking about: Canvas vs. SVG + SMIL.

Canvas is a very simple API (more info), much like what we’ve proposed to Khronos for 3D support.  It’s well-scoped, well understood and integrates very well with other web technologies.  And it’s been getting a huge amount of traction on the web.  People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization.  Have a look through Google’s own promotional site for Chrome – a huge number of them use canvas.  It has traction.  And we’ve gone through a couple of iterations – we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.

Now compare this to SVG and SMIL.  Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web.  (SVG 1.1 is a 719 page PDF.  SVG 1.2 Tiny is 449 pages.  The spec for SMIL is a 2.7MB HTML file.)  We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web.  The model for these specs was wrong, and I think it shows.

So I’ve spent some time talking about the context for standardization and what makes standards successful.  How does this related to our stuff or Google’s stuff?  Well, quite a bit actually.  If we want something that browser vendors can easily implement, we need to understand that context and what we’re trying to standardize.  Much of the work that Google did happened before browsers got as fast as they have, so there’s a good reason why they felt that they needed to implement so much of the code as native code and deliver it as a plugin.  Their API is a good example of what a scenegraph API would look like on top of Canvas 3D.  JS engines have gotten a lot faster since they started their plug-in and we think that it’s time that we start using them.  Hence a low-level API that we can build on.

There’s a lot of great stuff going on with 3D on the web.  We’ll be working with Google (and others!) via the Khronos group to try and standardize on a low-level API that browsers can support.  It’s going to be a really fun year and I’m happy that we’re working to drive the web forward.

In terms of claims some members of the V8 team have been bragging a little bit about how V8 is “many times faster” than TraceMonkey. In fact, some guarantees may have been made.

Based on the data above, we’re running about 20% faster than V8 on SunSpider. While I’m sure there will be changes to each of the engines in the coming months I think that the claim that “many times faster” is ludicrous on its face and should be tempered by actual data. [ Note that the Google test is recursion heavy, something we're adding to TraceMonkey right now. This explains the gap on that one type of test. See Brendan's post above or John's post below for more details. ]

It’s also important to realize another fact. Google has had a small army of people working on the V8 engine for two whole earth years. We’re about 60 days into TraceMonkey and we’re already starting to match the performance characteristics of V8. As Brendan put it:

What spectators have to realize is that this contest is not a playoff where each contending VM is eliminated at any given hype-event point. We believe that Franz&Gal-style tracing has more “headroom” than less aggressively speculative approaches, due to its ability to specialize code, making variables constant and eliminating dead code and conditions at runtime, based on the latent types inherent in almost all JavaScript programs. If we are right, we’ll find out over the next weeks and months, and so will you all.

If you want data across browsers you should look at this post from John Resig that contains some graphics that give relative performance of various browsers including Safari, Firefox 3.0.1, IE, etc. His overview is great and gives a much wider view of relative browser performance.

Also as a side note because I have your attention. There are some bizarre and incorrect claims made in the comic about garbage collection. Brendan puts things right as a comment in John’s post:

@Ben: Chrome has a nice GC: exact rooting, generational with copying. Single-threaded, too (not an option for SpiderMonkey, which is used in AT&T 1-800-555-1212 and 411 AVR massively multi-threaded services built by tellme.com, now owned by Microsoft!). It definitely helps cut down on pauses and keep memory use flatter.

The Chrome comic book did have one piece of misinformation, though: it said other browsers’ engines use conservative GC, and have false positive problems because they can’t distinguish random integers from pointers into the heap. This is not true of Firefox, IE, or Opera.

We do live in interesting times.

The article covers well tread ground: People are worried that Microsoft will leverage its market power to create a leadership position for multimedia on the web. Replacing the (proprietary) Flash video codecs with the (proprietary) Silverlight video codecs and associated tools. In some ways it looks like a battle between two companies and strategies that no one would care about. More lock-in, more proprietary tools, more opportunities to undermine the main single item that makes the web great: it’s open nature. But those companies have existing market reach and they will do anything they can to convert that into even more leverage over how you interact with the web. If nothing else, they will buy their way with cold hard cash onto your computers. These two industry players should be taken seriously.

John Lilly is quoted in the article as talking about the “generative Web” (via Jonathan Zittrain.) I like this phrase quite a bit. I think that might be an even be a better way to describe what we (as in the Mozilla Project) think is the most important part of the open web. That is, by the act of creation on the web you are also creating things that other people can build on. Everything from scraping data to create a search engine like Google to being able to look at other people’s HTML and JavaScript to discover how they do something clever. Transparency and openness creates innovation – innovation by thousands and thousands of people, each of which has a positive impact on the millions who use the web.

Think about it another way. The main metric that I would use to describe the health of a truly open web is this: That as the ecosystem expands, the raw number of people, companies or groups who hold power inside the ecosystem, and can affect its direction, grows as the ecosystem grows. Put another way, the power center is decentralized over time. Change inside of that ecosystem require more voices to agree that change is good. That’s healthy. And that’s an open web.

Then there’s the other side of the metric. That as an ecosystem expands it enhances the power of a single player in the market instead of creating many players in the market. Change in that market requires the permission of only that one player and that one player can make decisions on behalf of everyone who is also part of it. That’s not healthy. And it’s not the open web.

Based on those metrics for health the battle is between those who would expand for the sake of expanding the opportunity for everyone vs. those who would expand for the sake of centralizing their own market power. In one phrase: it’s expansion vs. centralization. That’s what you should be looking for and what you should be thinking about when you hear someone talking about the open web.

All of this is nice, of course, but it doesn’t really describe what we have to do to create the world we want to live in. It talks about the nature of the marketplace but it’s not really a roadmap for people to understand how, as the good guys in this picture, we can continue to compete and win against much larger competitors. I first word in the title for this post is “competing” for a reason. Because that’s what we really need to do.

Recently at the Firefox summit I was reminded in one of Mitchell’s talks about how Firefox is a mechanism. Firefox is the best representation of our vision for an open + generative web that we can come up with: As a rule our users love it, we’ve built an ecosystem of thousands of add-ons, we continue to protect our users from the worst aspects of the web, we continue to both compete and collaborate with other browser vendors and we manage to do all that in an open forum with open source code. Firefox is a reflection of our larger view of the transparency that we want to see in an open web. Put simply: We are the change we want to see on the web.

So that’s a lot of talk. Back to the issue at hand. Silverlight, video, adobe, multimedia, market power. How do we compete? Or, really, how do you compete? Because Mozilla isn’t going to create this change alone. We’re very very small by any standard in the tech marketplace. Our reach is pretty good with Firefox 2 + Firefox 3, and we’re starting to have real market effects, but we’re not going to be able to buy our way onto millions of computers by sponsoring the olympics.

People who have talked to me have heard me talk about two things on this topic. I usually say something like “you need to learn how to build a product” or “you need to find out what you can lead at and go do that.” There’s usually more than that, but that’s the main part of the message. And I think that if we want to make sure that the web isn’t overtaken by the acts of industry giants, that there are real actionable things we can do to make that happen.

I’ll use video on the web as a simple example. Here are the things that I think need to happen to make Theora a player in the real world.

1. Make sure there’s a really great video plugin for Apple Quicktime that delivers the OGG Theora video format to people who use the video tag in Safari. When I tried to play the ogg theora video from my post the other day the ogg plugin jumped around, showed a white screen for long periods, paused for a few seconds at a time – bad!

2. Create a control that brings the video tag to IE like Vlad did for the canvas tag. The world is much bigger than just Firefox. This would make it very easy to deliver and build content and make it easy for consumers to get access to it. Bring ubiquity to content like Adobe was able to do with Flash. (Note: Cortado isn’t good enough – it’s still stuck in the plugin prison!)

3. Make a super-easy, consumer-focused, high-quality encoder for ogg theora that anyone can use to encode their videos for the web. (Here’s a hint: Handbrake is still too hard to use.) Hook it up to the various video camera providers on mac and windows so that it’s super easy to create content, encode it, and with the tools listed above, upload it and make it available to others.

4. Even better, build a business around the tools above. Or even a service for people to upload to. Sustainability is an important component and it should not be left behind.

5. Create awesome demos of what you can do with the video tag, or even better mixed with the recent stuff we’ve been showing off with video + svg filters. Blur effects, video driven by content, content people can create and overlay onto existing videos, etc. Some of this stuff is out there, some of it isn’t. But it’s a start. Try mixing video with other content on the web – mash it up, cover it up, add value and context to otherwise boring videos. Its easier to do with the video tag than it is when it’s hidden inside of Flash or Silverlight.

So that’s just a short list of things people can do to help with video. There are lots of other things that people can do in other areas, other than just video, but I wanted to give an example of my thinking around OGG Theora as an example.

People seem excited about us including OGG Theora in our next Firefox release. But keep in mind it’s only a start. If the same ecosystem that we’ve seen develop around the open + generative web doesn’t grow around open video like it has around the web then we will end up with the status quo: a vibrant growing web but with large parts that are hobbled by a model that doesn’t grow on itself. Mozilla isn’t going to be able to do this job entirely on its own, but we’re doing our part. It’s going to take others to understand how we do what we do, copy its model and try to create the same effects in the other important parts of the ecosystem.

I wonder what the world will look like five years from now. It’s going to be an interesting ride.

He mentions that he’s working with us at Mozilla – very true. And good fodder for another post on another day.

He also touches on an important topic for me, which is the difference between between being “open” and being “good.” Being open is easy. Being good is not. I’ll write more about that at a later date as well.

Atul Varma talks about how Weave works and some of the wider goals for the project.

Weave is a very interesting part of the Mozilla project. The underlying mechanisms are very simple (just a webdav store and a private and public key system, basically.) But the fact that we’ll be able to use it to share data between users on their terms and extension authors should be able to take advantage of the storage that’s there – well – it could be huge. Lots of great potential here.

He also touches on an important part of weave. That we want user data to be private and we want users to control what they are exposing to the world. Mozilla’s servers can’t read the data that you post and neither can anyone else. That’s an important piece of what Weave represents.

Google drops the Google from Gears and will be adding Firefox 3 support.

It’s clear that Google is trying to build a larger community around the Gears plugin and is willing to give up branding in order to try and make that a reality. Also good that they are porting to Firefox 3 given that a huge chunk of the world is about to update to it.

Jorge Castro talks about his views on Mozilla’s commitment and investment in Linux.

Jorge is a pretty fantastic guy and I’m happy that he’s willing to jump out there and say something about the hard work that our community put in for this release of Firefox on Linux support. Great native integration, memory and performance improvements, a great experience for users, etc. Good to see him focus on the big picture which is how much better Firefox 3 will be vs. Firefox 2.

Anyway, that’s it for Friday. Thanks for tuning in!