EditingHelp

This page provides detailed help and examples of how to fill in individual fields of feature entries.

Feature name

Each feature should have a unique name that is written as a noun phrase.

• Capitalize only the first letter and the beginnings of proper nouns.
• Avoid using verbs such as "add", "enhance", "deprecate", or "delete". Instead, simply name the feature itself and use the feature type and stage fields to indicate the intent of change.
• Do not include markup or markdown.
• Write keywords and identifiers as they would appear to a web developer, not as they are in source code. For example, a method implemented as NewInterface#dostuff would be written as in JavaScript: NewInterface.doStuff().

Feature name example

• Conversion Measurement API
• CSS Flexbox: New intrinsic size algorithm
• Permissions-Policy header

Summary

Provide a one sentence description followed by one or two lines explaining how this feature helps web developers.

• Do not use markup or markdown.
• Do not use hard or soft returns.

Summary example

Splits the HTTP cache using the top frame origin (and possibly subframe origin) to prevent documents from one origin from knowing whether a resource from another origin was cached. The HTTP cache is currently one per profile, with a single namespace for all resources and subresources regardless of origin or renderer process. Splitting the cache on top frame origins helps the browser deflect side-channel attacks where one site can detect resources in another site’s cache.

Motivation

Provide a short explanation of the motivation for this feature.

The motivation field should not include any markup or markdown.

Motivation example

Cache attacks can lead to the following leaks:

Detect if a user has visited a specific site: If the cached resource is specific to a particular site or to a particular cohort of sites, an adversary can detect user’s browsing history by checking if the cache has that resource.

Cross-site search attack: There exist cross site search attack proofs-of-concept which exploit the fact that some popular sites load a specific image when a search result is empty. By opening a tab and performing a search and then checking for that image in the cache, an adversary can detect if an arbitrary string is in the user’s search results.

Interoperability and compatibility risks

Please describe the degree of interoperability risk.

For a new feature, the main risk is that it fails to become an interoperable part of the web platform if other browsers do not implement it.

For a removal, please review our principles of web compatibility.

Please include citation links below where possible. Examples include resolutions from relevant standards bodies (e.g. W3C working group), tracking bugs, or links to online conversations.

Interoperability and compatibility risks example

 WebCrypto API was specified to allow the addition of new (normalized)
 crypto algorithms. When an algorithm is not yet supported by a browser,
 an exception of unrecognized algorithms would be thrown after invoking
 related APIs.