index.bs

<h1>The evergreen web</h1>
<pre class="metadata">
Group: tag
Shortname: evergreen-web
ED: https://w3ctag.github.io/evergreen-web/
Repository: https://github.com/w3ctag/evergreen-web/
Status: FINDING
Editor: Hadley Beeman, https://hadleybeeman.com/
<!-- Group doesn't currently generate correct license info, so use copyright no, temporarily -->
Boilerplate: conformance no, copyright no
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.<p>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.
Markup Shorthands: markdown on
</pre>

Interoperable evolution {#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:
* The addition of new capabilities to the Web platform
* Security and privacy risks to be addressed
* Developers to build interoperable content
* The web to continue evolving as one cohesive platform

Subsetting slows evolution {#subsetting}
==========================

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.

Browsers are part of the web and must be continually updated {#updates}
============================================================

Vendors must decide whether their products can browse the public web. Products that can load arbitrary content are &ldquo;browsers&rdquo;. 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.