The Changing Web Platform Landscape: More Fragmentation?

The Web is an ever changing place and the first half of the year has been rich in surprises, big announcements and industry shifts! A diversity of implementations is good for many reasons we will discuss. But a more fragmented web could be the price to pay. Will it be the case?

About Implementation diversity

A few weeks ago Opera announced they were stopping work on their Presto rendering engine and switching to Chromium. They have already started contributing code to the project. Then, earlier this month, Google announced the Blink project, essentially a new fork of WebKit. And now Opera announced they will contribute to Blink!

Reactions were interesting as we went from WebKit monopoly concerns to worries about web platform fragmentation in a matter of weeks. Quite a 180 degrees turn!

At Adobe, we actively contribute to Web standards and browser implementations (historically mostly WebKit and Chromium, even though we also make some contributions to Gecko). As such we are delighted to see Opera join one of the projects we contribute to. Their considerable web expertise will undoubtedly be an asset.

There was some debate before the Blink announcement about whether or not we were heading for a WebKit monoculture: a web where content can be written with the assumption a WebKit-based engine is most likely to render it. While WebKit browsers share much core layout code they also differ in many ways at runtime: different JavaScript engines and graphics libraries, even different sets of features enabled by default. This makes it difficult in practice to write once for WebKit and run everywhere.

So we were not too concerned about a WebKit monoculture. But…

… there was a but in that view. The web is bigger than any one of its leading browser implementations and too important to be limited to a single code base even if that implementation has variations. The web is even growing to be an OS platform (e.g., ChromeOS, FirefoxOS, the new Windows Runtime), the core technology behind packaged applications (like PhoneGap applications). And ongoing innovation across HTML, JavaScript (in the TC-39 group at ECMA) and CSS needs validation, testing, consolidation.

As Brendan Eich says in his blog about “why Mozilla matters”:

“The web needs multiple implementations of its evolving standards to keep them interoperable.”

I believe this tenet to be central to delivering on the promise of the Open Web. A single implementation does not establish a standard. The W3C process even recommends two implementations in order for a specification to reach completion.

The Web needs Mozilla’s Gecko and Microsoft’s Trident engines to nurture an open, innovative environment. Historically, both companies have done a lot for the Web  – think of XHR which Microsoft invented (among other key contributions) or WOFF from Mozilla –  and they continue to innovate:  Microsoft and Mozilla co-edit the CSS Grid specification, which provides much needed and improved layout flexibility to CSS.

I trust that the addition of Blink will strengthen an already healthy browser competition. Over time, the Blink code base will diverge from WebKit’s but no harm to the web occurs if both engines implement the same features in different ways. Only significantly different feature sets could result in harmful fragmentation. Making sure that WebKit, Blink and other browser engines interoperate is more important than it has ever been.

About testing, fragmentation and experimental features

As the founders of Test the Web Forward, we have come to appreciate the mutually reinforcing benefits multiple independent implementations bring to standards. Historically, testing has been key to the success of web standards. For example, the focused testing effort on CSS 2.1 has shaped that specification and its implementations in the corner stone CSS has become. A single implementation would leave a lot of stones unturned.

It should also be noted that the Blink policy regarding prefixes is really good for standards and compatibility across browsers:  draft standard features can become truly experimental features that will not be used (and abused) in production. This should help avoid browser compatibility headaches down the line and I hope this example will be followed by all browsers.

About fragmentation and Adobe’s contributions

In this new web platform landscape, what about Adobe’s contributions to open source browsers? What impact does additional browser fragmentation has on Adobe’s efforts?

Adobe contributes to standards in open browser implementations for many reasons.

One of them is that our new generation Edge tools use a ‘web design surface’. For well over a year now, we have chosen to use the Chromium Embeded Framework (CEF) to provide this ‘web design surface’. So naturally, we will contribute to Blink since it is now the core engine that powers CEF.

Another reason for contributing to open browsers is to accelerate the availability of new features on the web. This is why we collaborate with Mozilla on a number of standards and contribute code to Gecko (like this patch on masking for canvas). And this is why we will also contribute to WebKit, in addition to Blink, now that the two are separate projects.

An open, innovative and tested web!

So yes, I think it is good to have multiple browser engines and Blink is a welcome addition to the web platform landscape. It is bringing a healthy diversity that I hope will help keep the web open and foster innovation as long as all browsers strive to implement ‘the same web’.

And this is where testing efforts are key to achieving diversity without fragmentation. I hope testing activities (of browser code of course, but of standard test suites as well and major initiatives that the W3C is driving) will be a major focus for all the browser vendors going forward, in particular for Google with its new Blink implementation.

The “Test The Web Forward” Movement: engaging the community to move towards a better Web

What makes a better Web?

Features are certainly important and there are multiple improvements to the web platform in the woks, for example the “SysApps” working group, the Linked Data effort or the new functionality added to CSS (such as CSS Regions and CSS Filter Effects which Adobe is actively contributing to).

However, while features are obviously key to a better, richer web, they are one of several elements which, when combined, deliver an enhanced web experience.

One is proper implementation of the web standards. For the web platform to be reliable, it is very important that implementations follow the various standards properly and reliably. The specifications define what browsers and other web components should do, but we need to make sure that implementations stick to the specification, from the most common features and down to the most obscure corner cases.
Tightly related to proper implementation is interoperability. It is possible, and this has happened many times in the past, to have standards, pretty solid implementations but poor interoperability because of various interpretation of the specifications by implementors. For example, in the early days of the Web, there were a lot of discrepancies between implementations of the Cascading Stylesheets specification. Interoperability issues are the plague of web developers as it either neuters the use of features (because the feature is not guaranteed to work in a consistent way across browsers for example) or weakens its appeal (because it will only be available to a fraction of the end-users).

Testing is the key to insure proper implementation and address interoperability issues. And great testing is the recipe for great implementations and awesome interoperability.  In the realm of web standards, testing comes in the form of specification test suite which are used to validate that a specification is implementable.

The testing challenge

Unfortunately, writing tests is fraught with difficulties. It requires dedication, expertise, persistence and careful attention to details. In addition, it is important to have the widest test coverage as possible to ensure testing depth and the desired implementation quality and interoperability. Historically, it has sometimes been difficult for implementors of particular specifications and working groups defining specifications to create test suites that are as deep as they would like. This issue has been at the root of implementation, interoperability and adoption difficulties for new standards.

Test the Web Forward

Move the Web Forward” is a grass roots movement that engages the community and challenges those passionate about the web to act on their desire for a better web. “Test the Web Forward” is exactly in that spirit: there are implementation or interoperability issues which the community of developers is painfully aware of, let’s try to enable developers to do something about this and contribute to better test suites which are an excellent way to improve the web.

Following that train of thought, Adobe and others in the community such as Microsoft, Mozilla, Google, W3C and Facebook have started to engage the community to contribute to web standards tests with a series of events call “Test the Web Forward”. To date, three events have been held: one in San Francisco (in June), one in Beijing (in October) and one in Paris (also in October). So far, about 700 new tests have been created that will be contributed towards web standards test suites. The events are typically held over a day and a half. During the first half day, experts from the standards working group (such as the CSS or SVG working groups in W3C) give short presentations about standards testing frameworks, browser bug filing and other topics related to reporting issues, isolating problems or ready a specification carefully to identify testable portions. The full day that follows is dedicated to ‘hacking tests’ in groups where the web developers work with the experts to write new tests, convert tests that may need reformatting or review existing tests so that they can be integrated into official test suites.

The following blog posts relate the events as they happened in San Francisco, Beijing  and Paris and this video gives a good description of what the events are about, how they foster interest in testing the web, generate good discussions, suggestions and produce concrete results.

Next Steps

While the Test the Web Forward events are fun, there is a desire to find ways to keep engaging between events and at the recent W3C Technical Plenary meeting in Lyon, France, Adobe suggested concrete ways for interested web developers to keep contributing. There are also very interesting discussions about how the “Test The Web Forward” movement relates to the Web Platform Docs effort and a lot of suggestions that the two efforts should be closely related.

It is very encouraging and exciting to see the web community interested in contributing to a better web and offer time and expertise in efforts such as TestTWF. Our team at Adobe will continue working on this effort and with our partners to help it grow and further demonstrate its efficacy to help build a better web.

So if you and your team are passionate about the web, want to help move it forward please follow #TestTWF on Twitter and visit to learn about upcoming events and new developments around this initiative!