User:Glob/intent-to-prototype

Email templates for new or changed features

When announcing your intent to prototype or ship a feature, using these templates is mandatory to ensure that you don’t miss anything critical, and that relevant teams and organizations are aware of upcoming changes.

Intent to prototype

Every field in this template is required; answer with Not-Applicable or N/A on fields that are not relevant rather than deleting the field from your response.

To: dev-platform@mozilla.org
Subject: Intent to prototype: <your feature goes here>

Summary:
Elevator pitch for the new functionality including benefits to users and web developers.

Bug:
Link to Bugzilla (tracking) bug.

Specification:
Link to the specification (see details above).

Standards Body:
Identify the standards body responsible for standardizing this feature if that is not obvious from the specification; if the specification is not already adopted by a standards body, link to the issue or a discussion about adoption of the work (if no discussion exists, please start that process before filing this intent).

Platform Coverage:
Where will this be available? Android, Desktop, only exposed to privileged apps (certified app-only functionality does not require an email), etc.

Preference:
How can interested parties test this before it ships pref'd on by default?

DevTools Bug:
Link to a Developer Tools bug coordinating work with the DevTools team to build tools for this feature.

Extensions Bug:
Link to a WebExtension bug coordinating work with the WebExtension team to build tools for this feature.

Use Counter:
Name of the use counter used for this feature. Please elaborate if it's not reasonable to add a use counter for complexity or other reasons.

Standards-Positions Discussion:
Link to an issue in mozilla/standards-positions about what we think about the specification.

Other Browsers:
- Blink: address with "shipped" (since version X, behind what flags if any), "intent emailed" (mailing list URL), or "considering" (citation). - WebKit: address with "shipped" (since version X, behind what flags if any), "intent emailed" (mailing list URL), or "considering" (citation).

web-platform-tests:
Link to the test suite. If any part of the feature is not tested by web-platform-tests, or if you had to write gecko-only tests for parts of the feature, please include links to one or more of: - A web-platform-tests issue explaining why a certain thing cannot be tested (example). - A spec issue for some change that would make it possible to test (example). - A Bugzilla bug for the creating web-platform-tests.

The above is the minimum required that must be in an "Intent to prototype" email — if you've covered those, you're good.

Suggested Additions

If you're looking for extra credit, or to preempt common questions, consider adding any or all of the following (all based on existing dev-platform examples, and questions asked on dev-platform in response to intent to ship emails).

How Stable Is The Spec:
Note that even if it's unstable that shouldn't stop us implementing; that mostly affects shipping. So as long as we're pretty sure that the basic set of functionality is stable, even if the actual names of the values are not, implementing makes sense.

Web Designer / Developer Use-Cases:
Why a developer would use this Feature?. Provide a URL to at least briefly documented use-cases for web designers and developers that illustrate why and when they would use this feature. E.g. a link to an https://webwewant.fyi/wants/ entry with that information.

Example:
Provide a brief code sample on how to use the API. Even with a formal specification, not everyone will know about the feature just from the name of the spec. An example will make it easier to understand how this feature can be used. This can either be an inline code sample, or a direct link to an example on the web.

Example (Intent to Prototype)

To: dev-platform@mozilla.org
Subject: Intent to Prototype: Container Timing API

Summary:
The Container Timing API enables monitoring when annotated sections of the DOM
are displayed on screen and have finished their initial paint. A developer will
have the ability to mark subsections of the DOM with the containertiming
attribute (similar to elementtiming for the Element Timing API) and receive
performance entries when that section has been painted for the first time. This
API will allow developers to measure the timing of various components in their
pages.

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1940240

Specification:
https://github.com/bloomberg/container-timing (Soon to move into WICG first, then W3C)

Because of the similarities to Element Timing, this can't go directly into W3C.
The working group are happy for work to continue in WICG first whilst we come
up with a solution to potentially merge the two specifications in future. (See
responses here: https://github.com/WICG/proposals/issues/260)

Standards Body:
W3C (Web Perf WG)

Platform Coverage:
all.

DevTools Bug:
N/A

Extensions Bug:
N/A

Use Counter:
N/A 

Link to standards-positions Discussion:
https://github.com/mozilla/standards-positions/issues/1155

Other Browsers:
Blink: Positive https://chromestatus.com/feature/5110962817073152
WebKit: considering

Preference:
dom.enable_container_timing

web-platform-tests:
https://wpt.fyi/results/container-timing/tentative?label=master&label=experimental&aligned&q=container%20timing

Bas Schouten has already provided a patch in the bug, this will be iterated on,
alongside the specification which myself, Bas and others will be looking at.

Intent to Ship

An "Intent to Ship" is a follow-up to a previously sent "Intent to Prototype".

If there isn't a previous "Intent to Prototype" email, your "Intent to Ship" email must include all the fields from the "Intent to Prototype".

Don't forget to set the dev-doc-needed keyword on the relevant bug.

To: dev-platform@mozilla.org
Subject: Intent to ship: <your feature goes here>

As of <target date or version> I intend to turn <feature> on by default [<on these platforms>]. It has been developed behind the <pref> preference. Status in other browsers is <details>.

Bug to turn on by default:
Link to main relevant bug (https://bugzilla.mozilla.org/show_bug.cgi?id=). Please set the dev-doc-needed keyword.

Standard:
Link to the standard; if the work is not yet part of a standard, also provide evidence that the responsible standards body has agreement that shipping the feature has broad support (see details above).

Intent to Prototype Thread:
Link to the previous "Intent to prototype" thread. If anything changed since that thread please include that information in this email. If no "Intent to Prototype" email was sent, you must include all fields from the "Intent to prototype" template in this email.

Suggested Additions

TAG Review:
Link to TAG review of the feature/spec Note: Blink requires this in their intent process.

Example (Intent to Ship)

To: dev-platform@mozilla.org
Subject: Intent to ship: ariaNotify

As of Firefox 150, I intend to turn ariaNotify on by default on all platforms.
It has been developed behind the accessibility.ariaNotify.enabled preference.
Status in other browsers: shipped in Blink, implemented in WebKit.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=2018095

Standard:
https://w3c.github.io/aria/#ARIANotifyMixin

Intent to Prototype Thread:
This feature was previously discussed in this "Intent to Prototype" thread:
https://groups.google.com/a/mozilla.org/g/dev-platform/c/7UOkFqbeH7o

TAG Review:
https://github.com/w3ctag/design-reviews/issues/1075

Example (Intent to Prototype and Ship)

To: dev-platform@mozilla.org
Subject: Intent to prototype and ship: CSS revert-rule keyword

Summary:
Add a CSS-wide keyword that allows reversing a single rule from the cascade,
rather than a whole origin (like revert) or a layer (revert-layer). This is
useful for var() / attr() / if(), though note we don't implement the later.
E.g. you can use something like `width: attr(width px, revert-rule)`, and the
declaration will be ignored unless you have a width attribute.

Bug:
https://bugzil.la/2017307

Specification:
https://drafts.csswg.org/css-cascade-5/#revert-rule-keyword (initially my proposal in #10443)

Standards Body:
CSS WG

Platform Coverage:
All

Preference:
layout.css.revert-rule.enabled

DevTools Bug:
https://bugzil.la/2020814

Extensions Bug:
N/A

Use Counter:
None [0]

Link to standards-position Discussion:
https://github.com/mozilla/standards-positions/issues/1358

Other browsers:
    Blink: About to ship
    WebKit: work in progress

web-platform-tests:
See the bug, there's a variety. Note that our implementation suffers from a
couple issues, but those are common to the pre-existing revert keywords and
haven't caused issues in practice: behavior in @keyframes (bug 1533327), and
behavior with dependent properties (csswg-drafts#9131). I don't think these are
blockers given that.

[0]: While we have somewhat comprehensive machinery to measure CSS values when
parsing, we have two issues that make it non-trivial to measure the right
thing:
- CSS wide keyword parsing has many entry points due to their nature, not all
  of them carrying the right context (so measuring parsing right would be kind
  of a PITA).
- Parsing wouldn't be the right thing to measure anyway. Ideally, we'd want to
  count it at cascade time instead (when the value is actually used). However
  we don't have an easy way to do that right now (and I don't think it's worth
  it for a relatively simple feature). I can look into adding that separately,
  filed bug 2020819.