The evergreen Web

W3C TAG Finding

This Version:
https://www.w3.org/2001/tag/doc/evergreen-web-20170209
Latest Version:
https://www.w3.org/2001/tag/doc/evergreen-web/
Latest editor's draft:
https://w3ctag.github.io/evergreen-web/
Editor:
Hadley Beeman
Issue Tracking:
GitHub
Mailing list

Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

Abstract

Constant evolution is fundamental to the Web’s usefulness. Browsers that do not stay up-to-date place stress on the ecosystem. These products potentially fork the web, isolating their users and developers from the rest of the world.

Browsers are a part of the web and therefore they must be continually updated. Vendors that ship browsers hold the power to keep the web moving forwards as a platform, or to hold it back.

Status of This Document

This document has been produced by the W3C Technical Architecture Group (TAG).

The TAG approved this finding at its February 2017 face to face meeting. Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org (archive).

1. Interoperable evolution

The web ecosystem enjoys a high level of interoperability, despite intense competition between browser vendors. Interoperability allows web developers to build experiences that are portable across devices and operating systems at a scale unique in the history of computing. Code written once can render in every browser.

Interoperability helps the web progress — innovation propagates between browsers though competition and standards. Browsers that are slow to update can inhibit the web’s evolution. The web has suffered periods of stagnation, impeding progress for users and developers.

Today, the web ecosystem is developing rapidly. Rapid, automatic software updates, vendor co-operation, standardization, and competition are essential to a healthy web. They have allowed:

2. Subsetting slows evolution

Some products support only a limited subset of the web platform. Vendors create these subsetted web runtimes for a number of reasons:

  1. Intentionally: to simplify their implementation, reduce resource requirements or meet environmental constraints (e.g., some browsers in TVs).

  2. Unintentionally: by shipping a relatively complete implementation but failing to update it as the web evolves (e.g., browsers from the pre-auto-update era or browsers on old operating systems not supported by the current version of the browser).

Web developers have a natural instinct to build content for the broadest possible audience. These subsetted browsers may require them to build separate content. They may also delay adoption of newer features across the web.

Subsets and legacy browsers can hold the lowest common denominator down, preventing the spread of platform-wide progress. This risk is magnified by use; more instances of subsetted browsers lead to a more heterogeneous web. Runtimes which are not general-purpose browsers or do not see much use pose less risk.

3. Browsers are part of the web and must be continually updated

Vendors must decide whether their products can browse the public web. Products that can load arbitrary content are “browsers”. Browsers must be regularly updated, especially to fix security and interoperability bugs — ideally with an automatic, secure update mechanism.

This responsibility does not limit vendors' freedom to use elements of web technologies or browser-derived runtimes to create closed systems (e.g. digital signage platforms or intranet-specific environments) that do not access the public web.