Featured Articles

Releasing an app is much more than just coding it. You are providing a service to people and they trust you with their data. With the amount of reports of apps “calling home” and storing and sending your data to third parties without your consent rising it is important to make it plain and obvious what you do. An easy to understand and plain Privacy Policy is not only a good service but it can make it easier for investors and users to choose your product over another.

Ramping up developers to submit and publish their apps to the Mozilla Marketplace we just released a few simple to understand Privacy policy guidelines complete with an HTML/CSS/RSS Privacy Policy Template on GitHub.

Whilst the guidelines are not a substitute for a real lawyer and don’t provide legal advice they have some very simple and powerful tips to get you going:

• Design your app or add-on so that what you actually do with user data is what users think you are doing with it.
• Try to give the user as much control over their data as you can, such as giving them the choice to opt-in to or opt-out of data collection whenever possible.
• Try to limit your data collection and use to only the data that you need.
• Design your app and service to protect the security of your user’s data in its collection, storage, and use.
• Respond to user questions and concerns about your privacy practices.
• Avoid ‘secret’ updates.
• Make your use of social features transparent, so that users are aware of when they’re sharing data socially.
• Give people a way to turn off automatic sharing or make more granular choices about sharing data.
• Obtain consent from users when necessary, especially for location and other sensitive information.
• Put a link to your privacy policy and, if you have them, your “terms of use” somewhere in your app.

Avoid confusion and problems in the future by getting the basics right – and that very much includes privacy concerns in your app.

We have just released Firefox Aurora 14, which includes a number of improvements. If all goes well, these features should be released in 12 weeks as part of Firefox 14.

Highlights

There are a few of things we’d like to shine some extra light on here:

• Native Fullscreen Support in Mac OS X 10.7 “Lion”: Firefox can now use the native full-screen mode and button. It animates and behaves properly in that mode, like any other well-integrated application.
• Great news for gamers! The Pointer Lock API, sometimes called the Mouse Lock API, lets games better control the mouse, by removing the pointer and letting the application capture and handle the mouse move coordinates directly.
• The four default ways to search — using the search bar, the address bar, the contextual menu, or the home page, now all use the Google https search service in Aurora. This increase the security of your searches.
• The dev tools now allow easily inspecting pseudo-classes states: when hovering over an element with the dev tools activated, the contextual menu now lists the different states of the element, like :hover, :active, and :focus. When selecting one of these items, the element is locked in the associated state and can be inspected. That feature was already there in Aurora 13, but the interface to access it is now very convenient!
  
  

List of improvements

Here is a (more or less) complete list of the improvements.

DevTools

• New keyboard shortcuts have been added to the Source Editor JS module (used by the Scratchpad or the Style Editor) to quickly jump to the code block start and end.
• Still in the Source Editor module, it is now possible to add or remove a comment on a line or the current selection with one keystroke.
• Beside the new pseudo-class inspector, several improvements have been made to the infobar which has now an inspect button to the left and a node menu to the right (for example, it may be used to set the pseudo-class state on the node!)

DOM

• The Pointer Lock API has been implemented.
• A proposal for the replacement of MutationEvents, introduced in DOM Level 2 but deprecated in DOM Events Level 3, has landed, prefixed: instead of events, an API allowing callbacks to be registered has been crafted.
• New, with added performance, DOM bindings for non-list objects have landed. Currently XMLHttpRequest is the only non-list object using them. These bindings are often called the “Paris DOM bindings” as they were designed in that city.
• The SVGSVGElement has been fixed to be a DOM Element.
• HTMLProgressElement, the DOM object associated with the <progress> HTML element, was a HTMLFormElement. This was incorrect and has been fixed. It is a simple HTMLElement now.

Plugins

• Optionally, if the plugins.click_to_play preference is enabled in about:config, plugins will require an extra click to activate and start “playing” content. This mode improves the security of the browser and may be extended in the future to be activated by default in some cases. When on, site-specific permissions can be set.

Layout

• CSS text-transform and font-variant properties have been updated to match the spec and now handle the Dutch IJ digraph, the Turkic dotless and dotted i, and the Greek sigma lowercase characters correctly. This is big improvement for writing on the Web in these languages!
• Related to CSS transforms, the skew() function has been removed from the spec, so support has been removed from Firefox as well. It wasn’t a real skew function which designs the linear shear mapping transform and its effect is still achievable using the matrix() function.
• Directly viewed images now have a textured background.
• The character maps (cmap) have been optimized. Fonts with identical character coverage now share them. This lets Firefox use less memory, about 0.5 MB on a desktop system with few fonts, and up to 1.8MB or more on systems with a lot of fonts. The more fonts that are installed, the greater the savings. This was done as a part of the MemShrink project.
• SVG performance has been significantly improved.

User Interface

• The popup bubble containing a link URL that appears on the bottom of the page when hovering over a link is now longer when the URL doesn’t fit in it.
• As part of the Australis theme evolution project, the navigation bar buttons have been modified (on Windows only).
• The identity block has been redesigned. The favicon has been changed to show an icon describing the connection used:
• The page is served unencrypted (http).
  
• The page is served encrypted (via https) but some of its content comes from unencrypted servers.
  
• The page and its content is served encrypted (and the server uses a CV certificate).
  
• The page and its content is served encrypted (and the server uses an EV certificate).
  

Network

• At launch, tabs are no longer loaded in the background. Instead, they are now loaded when first selected, which improves response during the start-up of Firefox. This has been done as a part of the Snappy project.

Others

• Both the Internet Explorer and Safari migrators have been rewritten in JavaScript. Using asynchronous I/O, they don’t block the browser when they run and it improves their maintainability. This has been done as part of the Snappy project.
• On Linux, the $LANG system variable is now used when not able to locate a given dictionary in another way. Useful for system-wide installed dictionaries.
• For add-ons writers, the js-ctypes library has been extended. Variadic ctypes functions — that is, support for functions with a variable number of arguments — have been added.
• Several bugs in our WebGL implementation have been fixed (and workarounds for some common driver bugs added). We are close to WebGL 1.0.1 conformance, but your help is still needed.
• Extra flexibility has been added to the Garbage Collector (GC): it could previously be applied on a single compartment or on all compartments. Now it can also be applied on a set of compartments. This will let it be launched in more cases in the future, leading to a finer control of memory and of GC pauses.

Note: pdf.js and the new panel-based Download Manager, though they landed on Nightly, have not been lifted to Aurora 14 as they need further polishing. Similarly, support of GStreamer for videos, though it landed last week, has not been activated yet.

As we’re having a HTML5 Audio developer derby this month, I thought it fun to play with audio again. And I found it sadly enough pretty frustrating.

One thing I proposed in a lot of talks is using the idea of CSS sprites and apply them to HTML5 audio. You’ll get the same benefits – loading one file in one HTTP request instead of many, avoiding failure as files might not get loaded and so on.

To test this out I wrote the following small demo using the awesome Music Non Stop by Kraftwerk.

Clicking the different buttons should play the part of the music file and nothing more. This works fine in Firefox, Chrome and Opera on my computer here. Safari, however, fails to preload the audio and the setting of the current time is off. The code is simple enough that this should work:

<div id="buttons"></div>
<audio preload controls>
  <source src="boing-boomchack-peng.mp3" type="audio/mp3"></source>
  <source src="boing-boomchack-peng.ogg" type="audio/ogg"></source>
</audio>

// get the audio element and the buttons container
// define a sprite object with the names and the start and end times 
// of the different sounds.
var a = document.querySelector('audio'),
    buttoncontainer = document.querySelector('#buttons'),
    audiosprite = {
      'all': [ 0, 5 ],
      'boing': [ 0, 1.3 ],
      'boomtchack': [ 2, 2.5 ],
      'peng': [ 4, 5 ]
    },
    end = 0;
 
// when the audio data is loaded, create the buttons 
// this way non-HTML5 browsers don't get any buttons 
a.addEventListener('loadeddata', function(ev) {
  for (var i in audiosprite) {
    buttoncontainer.innerHTML += '<button onclick="play(\'' +
                                  i + '\')">' + i + '</button>';
  }
}, false);
 
// If the time of the file playing is updated, compare it 
// to the current end time and stop playing when this one 
// is reached
a.addEventListener('timeupdate', function(ev) {
  if (a.currentTime > end) {
    a.pause();
  }
},false);
 
// Play the current audio sprite by setting the currentTime
function play(sound) {
  if ( audiosprite[sound] ) {
    a.currentTime = audiosprite[sound][0];
    end = audiosprite[sound][1];
    a.play();
  }
}

Now, this is nothing new, Remy Sharp wrote about audio sprites in 2010 and lamented especially the buggy support in iOS (audio won’t load at all until you activate it with a touch – something that sounds horribly like the “click to active” Flash has on IE).

Other issues are looping and latency of HTML5 audio. As reported by Robert O’Callahan there is a work-around by cloning the audio element before playing it (with an incredibly annoying test) and this fix has been used in the Gladius HTML5 game engine.

All in all it seems HTML5 audio still needs a lot of work which is why a lot of Games released lately under the banner of HTML5 use Flash audio or no audio at all. This is sad and needs fixing.

Interestingly enough there are some great projects that you could be part of. Are we playing yet? by Soundcloud and others for example is a test suite for audio support in browsers. You can write own tests on GitHub and report results to the browser makers.

The jPlayer team has a great HTML5 Media Event Inspector showing just how many of the HTML5 media events are supported in your current browser.

If you want to be safe, you can use SoundManager 2 by Scott Schiller to have an API that uses HTML5 when possible and falls back to Flash when the browser doesn’t have any support. It also fixes a few issues for you.

Speaking of Scott Schiller, he continually gives good insight on the state of audio. There is a 51 minute video of his article on 24 ways “Probably, Maybe, No: The State of HTML5 Audio“.

A shorter and more recent talk on the same subject is also available:

All in all it would be interesting to hear what you think of the state of HTML5 audio:

• Did the companies that heralded HTML5 as the end of plugins drop the ball?
• Is it really sensible to have an API that returns probably or maybe or ” when you ask it if the browser can play a certain type of media?
• What could be done to work around these issues?

Let’s re-ignite the discussion on HTML5 audio, after all we need it for the future of messaging in the browser and telephony, too.

Oh and another thing. Of course there is the Audio Data API of Firefox and the web audio proposal from Webkit available but getting those running in mobile devices will be a much bigger change. If you want to know more about those and libraries to work around their differences, there is a great overview post available on Happyworm.

[Also posted at brendaneich.com.]

I wrote The Open Web and Its Adversaries just over five years ago, based on the first SXSW Browser Wars panel (we just had our fifth, it was great — thanks to all who came).

Some history

The little slideshow I presented is in part quaint. WPF/E and Adobe Apollo, remember those? (Either the code names, or the extant renamed products?) The Web has come a long way since 2007.

But other parts of my slideshow are still relevant, in particular the part where Mozilla and Opera committed to an unencumbered <video> element for HTML5:

• Working with Opera via WHATWG on <video>
  • Unencumbered Ogg Theora decoder in all browsers
  • Ogg Vorbis for <audio>
  • Other formats possible
  • DHTML player controls

We did what we said we would. We fought against the odds. We carried the unencumbered HTML5 <video> torch even when it burned our hands.

We were called naive (no) idealists (yes). We were told that we were rolling a large stone up a tall hill (and how!). We were told that we could never overcome the momentum behind H.264 (possibly true, but Mozilla was not about to give up and pay off the patent rentiers).

Then in 2009 Google announced that it would acquire On2 (completed in 2010), and Opera and Mozilla had a White Knight.

At Google I/O in May 2010, Adobe announced that it would include VP8 (but not all of WebM?) support in an upcoming Flash release.

On January 11, 2011, Mike Jazayeri of Google blogged:

… we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

These changes will occur in the next couple months….

A followup post three days later confirmed that Chrome would rely on Flash fallback to play H.264 video.

Where we are today

It is now March 2012 and the changes promised by Google and Adobe have not been made.

What’s more, any such changes are irrelevant if made only on desktop Chrome — not on Google’s mobile browsers for Android — because authors typically do not encode twice (once in H.264, once in WebM), they instead write Flash fallback in an <object> tag nested inside the <video> tag. Here’s an example adapted from an Opera developer document:

<video controls poster="video.jpg" width="854" height="480">
 <source src="video.mp4" type="video/mp4">
 <object type="application/x-shockwave-flash" data="player.swf"
         width="854" height="504">
  <param name="allowfullscreen" value="true">
  <param name="allowscriptaccess" value="always">
  <param name="flashvars" value="file=video.mp4">
  <!--[if IE]><param name="movie" value="player.swf"><![endif]-->
  <img src="video.jpg" width="854" height="480" alt="Video">
  <p>Your browser can't play HTML5 video.
 </object>
</video>

The Opera doc nicely carried the unencumbered video torch by including

 <source src="video.webm" type="video/webm">

after the first <source> child in the <video> container (after the first, because of an iOS WebKit bug, the Opera doc said), but most authors do not encode twice and host two versions of their video (yes, you who do are to be commended; please don’t spam my blog with comments, you’re not typical — and YouTube is neither typical nor yet completely transcoded [1]).

Of course the ultimate fallback content could be a link to a video to download and view in a helper app, but that’s not “HTML5 video” and it is user-hostile (profoundly so on mobile). Flash fallback does manage to blend in with HTML5, modulo the loss of expressiveness afforded by DHTML playback controls.

Now, consider carefully where we are today.

Firefox supports only unencumbered formats from Gecko’s <video> implementation. We rely on Flash fallback that authors invariably write, as shown above. Let that sink in: we, Mozilla, rely on Flash to implement H.264 for Firefox users.

Adobe has announced that it will not develop Flash on mobile devices.

In spite of the early 2011 Google blog post, desktop Chrome still supports H.264 from <video>. Even if it were to drop that support, desktop Chrome has a custom patched Flash embedding, so the fallback shown above will work well for almost all users.

Mobile matters most

Android stock browsers (all Android versions), and Chrome on Android 4, all support H.264 from <video>. Given the devices that Android has targeted over its existence, where H.264 hardware decoding is by far the most power-efficient way to decode, how could this be otherwise? Google has to compete with Apple on mobile.

Steve Jobs may have dealt the death-blow to Flash on mobile, but he also championed and invested in H.264, and asserted that “[a]ll video codecs are covered by patents”. Apple sells a lot of H.264-supporting hardware. That hardware in general, and specifically in video playback quality, is the gold standard.

Google is in my opinion not going to ship mobile browsers this year or next that fail to play H.264 content that Apple plays perfectly. Whatever happens in the very long run, Mozilla can’t wait for such an event. Don’t ask Google why they bought On2 but failed to push WebM to the exclusion of H.264 on Android. The question answers itself.

So even if desktop Chrome drops H.264 support, Chrome users almost to a person won’t notice, thanks to Flash fallback. And Apple and Google, along with Microsoft and whomever else might try to gain mobile market share, will continue to ship H.264 support on all their mobile OSes and devices — hardware-implemented H.264, because that uses far less battery than alternative decoders.

Here is a chart of H.264 video in HTML5 content on the Web from MeFeedia:

And here are some charts showing the rise of mobile over desktop from The Economist:

These charts show Bell’s Law of Computer Classes in action. Bell’s Law predicts that the new class of computing devices will replace older ones.

In the face of this shift, Mozilla must advance its mission to serve users above all other agendas, and to keep the Web — including the “Mobile Web” — open, interoperable, and evolving.

What Mozilla is doing

We have successfully launched Boot to Gecko (B2G) and we’re preparing to release a new and improved Firefox for Android, to carry our mission to mobile users.

What should we do about H.264?

Andreas Gal proposes to use OS- and hardware-based H.264 decoding capabilities on Android and B2G. That thread has run to over 240 messages, and spawned some online media coverage.

Some say we should hold out longer for someone (Google? Adobe?) to change something to advance WebM over H.264.

Remember, dropping H.264 from <video> only on desktop and not on mobile doesn’t matter, because of Flash fallback.

Others say we should hold out indefinitely and by ourselves, rather than integrate OS decoders for encumbered video.

I’ve heard people blame software patents. I hate software patents too, but software isn’t even the issue on mobile. Fairly dedicated DSP hardware takes in bits and puts out pixels. H.264 decoding lives completely in hardware now.

Yes, some hardware also supports WebM decoding, or will soon. Too little, too late for HTML5 <video> as deployed and consumed this year or (for shipping devices) next.

As I wrote in the newsgroup thread, Mozilla has never ignored users or market share. We do not care only about market share, but ignoring usability and market share can easily lead to extinction. Without users our mission is meaningless and our ability to affect the evolution of open standards goes to zero.

Clearly we have principles that prohibit us from abusing users for any end (e.g., by putting ads in Firefox’s user interface to make money to sustain ourselves). But we have never rejected encumbered formats handled by plugins, and OS-dependent H.264 decoding is not different in kind from Flash-dependent H.264 decoding in my view.

We will not require anyone to pay for Firefox. We will not burden our downstream source redistributors with royalty fees. We may have to continue to fall back on Flash on some desktop OSes. I’ll write more when I know more about desktop H.264, specifically on Windows XP.

What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G and survive the shift to mobile.

Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance. So I am fully in favor of Andreas’s proposal.

Our mission continues

Our mission, to promote openness, innovation, and opportunity on the Web, matters more than ever. As I said at SXSW in 2007, it obligates us to develop and promote unencumbered video. We lost one battle, but the war goes on. We will always push for open, unencumbered standards first and foremost.

In particular we must fight to keep WebRTC unencumbered. Mozilla and Opera also lost the earlier skirmish to mandate an unencumbered default format for HTML5 <video>, but WebRTC is a new front in the long war for an open and unencumbered Web.

We are researching downloadable JS decoders via Broadway.js, but fully utilizing parallel and dedicated hardware from JS for battery-friendly decoding is a ways off.

Can we win the long war? I don’t know if we’ll see a final victory, but we must fight on. Patents expire (remember the LZW patent?). They can be invalidated. (Netscape paid to do this to certain obnoxious patents, based on prior art.) They can be worked around. And patent law can be reformed.

Mozilla is here for the long haul. We will never give up, never surrender.

/be

A lot of people are interested in Firefox, the progress that is being made and what we plan to do. Therefore, I’d like to outline the things we accomplished with Firefox in 2011, and what we have already done, and plan to do, in 2012.

Continued…

TL;DR: we have to stop advocating localStorage as a great opportunity for storing data as it performs badly. Sadly enough the alternatives are not nearly as supported or simple to implement.

When it comes to web development you will always encounter things that sound too good to be true. Sometimes they are good, and all that stops us from using them is our notion of being conspicuous about *everything* as developers. In a lot of cases, however, they really are not as good as they seem but we only find out after using them for a while that we are actually “doing it wrong”.

One such case is local storage. There is a storage specification (falsely attributed to HTML5 in a lot of examples) with an incredibly simple API that was heralded as the cookie killer when it came out. All you have to do to store content on the user’s machine is to access the navigator.localStorage (or sessionStorage if you don’t need the data to be stored longer than the current browser session):

localStorage.setItem( 'outofsight', 'my data' );
console.log( localStorage.getItem( 'outofsight' ) ); // -> 'my data'

This local storage solution has a few very tempting features for web developers:

• It is dead simple
• It uses strings for storage instead of complex databases (and you can store more complex data using JSON encoding)
• It is well supported by browsers
• It is endorsed by a lot of companies (and was heralded as amazing when iPhones came out)

A few known issues with it are that there is no clean way to detect when you reach the limit of local storage and there is no cross-browser way to ask for more space. There are also more obscure issues around sessions and HTTPS, but that is just the tip of the iceberg.

The main issue: terrible performance

LocalStorage also has a lot of drawbacks that aren’t quite documented and certainly not covered as much in “HTML5 tutorials”. Especially performance oriented developers are very much against its use.

When we covered localStorage a few weeks ago using it to store images and files in localStorage it kicked off a massive thread of comments and an even longer internal mailing list thread about the evils of localStorage. The main issues are:

• localStorage is synchronous in nature, meaning when it loads it can block the main document from rendering
• localStorage does file I/O meaning it writes to your hard drive, which can take long depending on what your system does (indexing, virus scanning…)
• On a developer machine these issues can look deceptively minor as the operating system cached these requests – for an end user on the web they could mean a few seconds of waiting during which the web site stalls
• In order to appear snappy, web browsers load the data into memory on the first request – which could mean a lot of memory use if lots of tabs do it
• localStorage is persistent. If you don’t use a service or never visit a web site again, the data is still loaded when you start the browser

This is covered in detail in a follow-up blog post by Taras Glek of the Mozilla performance team and also by Andrea Giammarchi of Nokia.

In essence this means that a lot of articles saying you can use localStorage for better performance are just wrong.

Alternatives

Of course, browsers always offered ways to store local data, some you probably never heard of as shown by evercookie (I think my fave when it comes to the “evil genius with no real-world use” factor is the force-cached PNG image to be read out in canvas). In the internal discussions there was a massive thrust towards advocating IndexedDB for your solutions instead of localStorage. We then published an article how to store images and files in IndexedDB and found a few issues – most actually related to ease-of-use and user interaction:

• IndexedDB is a full-fledged DB that requires all the steps a SQL DB needs to read and write data – there is no simple key/value layer like localStorage available
• IndexedDB asks the user for permission to store data which can spook them
• The browser support is not at all the same as localStorage, right now IndexedDB is supported in IE10, Firefox and Chrome and there are differences in their implementations
• Safari, Opera, iOS, Opera Mobile, Android Browser favour WebSQL instead (which is yet another standard that has been officially deprecated by the W3C)

As always when there are differences in implementation someone will come up with an abstraction layer to work around that. Parashuram Narasimhan does a great job with that – even providing a jQuery plugin. It feels wrong though that we as implementers have to use these. It is the HTML5 video debate of WebM vs. H264 all over again.

Now what?

There is no doubt that the real database solutions and their asynchronous nature are the better option in terms of performance. They are also more matured and don’t have the “shortcut hack” feeling of localStorage. On the other hand they are hard to use in comparison, we already have a lot of solutions out there using localStorage and asking the user to give us access to storing local files is unacceptable for some implementations in terms of UX.

The answer is that there is no simple solution for storing data on the end users’ machines and we should stop advocating localStorage as a performance boost. What we have to find is a solution that makes everybody happy and doesn’t break the current implementations. This might prove hard to work around. Here are some ideas:

• Build a polyfill library that overrides the localStorage API and stores the content in IndexedDB/WebSQL instead? This is dirty and doesn’t work around the issue of the user being asked for permission
• Implement localStorage in an asynchronous fashion in browsers – actively disregarding the spec? (this could set a dangerous precedent though)
• Change the localStorage spec to store asynchronously instead of synchronously? We could also extend it to have a proper getStorageSpace interface and allow for native JSON support
• Define a new standard that allows browser vendors to map the new API to the existing supported API that matches the best for the use case?

We need to fix this as it doesn’t make sense to store things locally and sacrifice performance at the same time. This is a great example of how new web standards give us much more power but also make us face issues we didn’t have to deal with before. With more access to the OS, we also have to tread more carefully.

Mozilla’s Boot to Gecko (B2G) is about building a complete, standalone operating system for the open web. It aims at making web technologies the number one choice for applications on desktop and mobile, and we believe it can displace proprietary, single-vendor stacks for application development. And we have made some exciting progress that we want to share with you!

Continued…

The other day we wrote about how to Save images and files in localStorage, and it was about being pragmatic with what we have available today. There are, however, a number of performance implications with localStorage – something that we will cover on this blog later – and the desired future approach is utilizing IndexedDB. Here I’ll walk you through how to store images and files in IndexedDB and then present them through an ObjectURL.

Continued…

This is the fourth installment of Mission:Mozilla, a series of interviews that link Mozillians, the technology they produce and the Mozilla mission. This time, We’re interviewing Tantek Çelik, a long-time Web standards contributor. He started working on web standards at Microsoft in 1998, while leading the development of Tasman, the IE Mac rendering engine, and subsequently founded independent efforts like microformats.org, BarCamp, and most recently, IndieWebCamp.org.

Tristan – Hi Tantek, could you introduce yourself? (I could point our reader to your Wikipedia page, but it seems a bit out of date).

Tantek – I’ve been passionate about web standards since being inspired at the level of collaboration among different companies, cultures, individuals at my first W3C CSS&PF WG meeting May 1998 in Paris. My interest in standards as building blocks started much earlier with many childhood hours spent building things with LEGOs.

Tristan – Ah, LEGOs! I have fond memories of them, particularly LEGO technic! They’ve inspired so many geeks that they somehow should be credited for their work in W3C specs, don’t you think? ;-)

Tantek – Indeed I think LEGOs have inspired many an engineer. Simple pieces that could be combined in numerous ways and built into amazing unique and creative structures.

Tristan – Sounds like a good description of Web technologies to me! Who was your employer back then?

Tantek – I was working for Microsoft at the time, having joined the Macintosh Internet Products Group in 1997. I started work on Macintosh Internet Explorer (MacIE) in mid 1997 with mostly bug fixes and improvements in CSS support which incrementally made their way into MacIE 4. It was soon clear though that we needed a fairly big overhaul to implement better CSS support. Soon after I joined standards discussions in the W3C.

Tristan – It’s a little known fact, but IE Mac was really raising the bar when it came to CSS compliance. It was a time where few people cared about Web standards. I was at Netscape back then, and you at Microsoft. It was amazing to see a team trying to push Web standards on the other side of the fence!

Tantek – When I was made the developer lead for the MacIE rendering engine, it wasn’t immediately obvious to me what we should focus on, so I decided to interview web design firms in San Francisco and just ask: “Hi I’m with the Microsoft MacIE team. What would you like to see in terms of standards / rendering support in the next version of MacIE?” The answers were loud and clear: dependable standards support! In particular: reliable and ideally complete CSS support, “XML support” (whatever that meant), and better Javascript/DOM support. A few specifically asked for PNG support. Those interviews drove the priorities of what became Tasman, the new rendering engine for MacIE5 which itself in the process got renamed to Internet Explorer 5 for Macintosh (IE5/Mac). Little did I know at the time that such a focus on getting web standards right would come as a surprise to others.

Tristan – And now, a few years down the road, we’ve seen how Web standards have made the Web what it is today, but they’re also something that Web browser vendors are heavily investing on! What do you do for Mozilla today? Why should Web developers care?

Tantek – I joined Mozilla in May 2010 as Web Standards Lead and I’m excited to be working with so many people passionate about standards. In an organization with numerous talented web standards contributors, in addition to editing/iterating specifications, my role is often more of coordination and collaboration, making sure that folks who care about particular standards find each other and work together. One key thing I’ve created and driven in Mozilla is the open documentation of our standards participation, in a public place where not only we (Mozillians) can find each other, but web developers in general can see how much effort Mozilla and individual Mozillians put into web standards.

Tristan – I have the impression that Mozilla does not get the share of credit we deserve when it comes to our work on standards. Don’t you agree?

Tantek – As someone who’s been involved with web standards for over a decade, I’ve had a deep respect for Mozilla’s involvement with web standards for quite some time. However I do think that recognition can easily be forgotten outside of standards circles. I think the web community as a whole greatly underestimates the longevity, depth, and dedication of Mozilla’s contributions to web standards.

Tristan – Where do you think Mozilla particularly shines?

Tantek – One thing that’s always impressed me about Mozilla’s commitment to web standards is the level of quality and thoroughness that Mozilla places into implementations. In my experience, historically Firefox has had the highest fidelity handling of various CSS properties for example, focusing more on getting things precisely right rather than shipping quick implementations that may only cover common or 80% cases.

Second, Mozilla works far more in the open, early and often, than any other organization. For example, we do nearly all our project work on open wiki pages on wiki.mozilla.org. I even keep my own Mozilla projects list on an open Mozilla wiki page. It makes it really easy to answer when people ask me what am I working on these days.

Tristan – I agree with you. I sense that Mozilla tends to do the right thing, rather than the thing that makes us look good. Can you give an example why do Web standards matter?

Tantek – The browser compatibility tax. When the Web Standards Project started in 1998, they raised the real and painful issue of the “browser compatibility tax” that developers had to pay when developing web sites. No matter what standard a web author would use, they’d have to spend potentially 50-75% of their time purely on making their code work in multiple browsers, sometimes having to write multiple versions of their markup and style sheets and then use fragile user-agent string tests to serve different content (a bad habit that still persists to this day). Much of this was due to the abysmal standards support in 1990s browsers.

Web standards are an agreement between authors and browsers: if the author writes valid code (whether HTML, CSS, or JS), the browsers agree to render and execute it predictably and according to the standards. Without standards, web authors end up wasting their time coding for one browser at a time (typically focusing on whatever is the popular browser that year), and browsers developers end up wasting their time writing code fixing one site at a time.

Tristan – And if we want the Web to be the platform of choice for all kind of developers and all kinds of applications, from desktop to mobile, we need to remove this “browser compatibility tax”.

Tantek – Yes. It’s up to all of us as browser implementers to provide strictly correct implementations of web standards for authors to use, and for implementers to openly propose and test innovations in web standards.

Tristan – what’s your biggest concern about Web standards?

Tantek – My biggest concern about web standards can be summed up in four words: “Best Viewed In [...]“ where the fourth word can be filled in with a different browser nearly every year. Anything that encourages web authors to focus on a single browser (or browser engine) to the expense of other browsers hurts the web. It’s also short-sighted – next year all the browsers will change and what was “best” last year is not the same this year, even newer versions of the same browser!

Worst of all is when browser vendors themselves either encourage or outright publish “best viewed in” content themselves, thus setting a bad example for web authors.

Judge for yourself – whenever you see a site purporting to show-off or demonstrate web standards, if the site ever gives you an excuse like “Please use browser X to view this” then they’re misbehaving. Standards demonstrations should simply state the standards they require, and then link to test suites (developed in standards bodies) for you to check your own browser.

And “Best Viewed In” is just one of several concerns.

There are many difficult challenges to open web standards that we must acknowledge and continue fighting hard to overcome. Challenges like patents that may hurt Touch Events, devices that only effectively support a single browser engine, and when one or a small number of companies decide to dictate de-facto standards through “delayed open” tactics.

Tristan – What’s the most exciting thing going on in the world of Web standards these days?

Tantek – So many things to choose from! I think the most exciting thing about web standards these days is the unprecedented level of intense interest and collaboration across numerous companies on the open web platform built on web standards. There’s a rising culture of placing importance on the open web, and I think we have Mozilla to thank for keeping that flame alive for so long and setting an ever higher bar for how to best work openly on open web standards.

The Mozilla Manifesto provides an excellent set of principles for how to do so. I think what’s particularly important is to keep evolving openness, and Mozilla encourages community members to contribute their own views on how and why to work openly. Here is some more on the subject:

• http://paulrouget.com/e/openness/
• http://tantek.com/2010/281/b1/what-is-the-open-web
• http://tantek.com/2011/168/b1/practices-good-open-web-standards-development

Tristan – Thank you very much for your time Tantek, and keep up the good (and open) work!

In this post I round-up my first time at FOSDEM and the two talks I gave during my time there; one on open Web apps and the other on creating games with HTML5.

Continued…