Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Generic Sensor API - and friends...
• Specification or proposal URL: https://www.w3.org/TR/generic-sensor/

Other information

This has also spawned other sensors that inherit the generic interface - which refactor sensors we already have exposed (and in many cases had to remove) in the browser.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Cookie Change Events
• Specification or proposal URL: https://patrickkettner.github.io/cookie-change-events

Other information

Currently, for a page to become aware of cookie changes made by another browsing context with a page from the same site open, the page has to poll document.cookie. The feature being proposed makes polling unnecessary by introducing an event that can be listened to instead.

See also an explainer.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Activation Delegation
• Specification or proposal URL: https://github.com/WICG/gesture-delegation/blob/master/explainer.md

Other information

Some features on the platform require a user activation in order to be triggered. Among these features, some of them require a user activation to have happened on the document. Gating features to user activations is meant to reduce user annoyance but can hurt the ecosystem when the features are triggered from an iframe. Indeed, iframes may be used as components of a website and can be used to sandbox third party code. Allowing these iframes to be able to use the user activation information from the embedder would still allow the embedder to limit the behaviour of an iframe without entirely breaking the intended experience.

• Specification Title: Permissions API
• Specification or proposal URL: https://w3c.github.io/permissions/

It seems that request() and revoke() were dropped so I suspect this is no longer controversial, but it came up in email with @marcoscaceres, @martinthomson, @jan-ivar, and @overholt.

The main question that came up in email is who gets to watch it.

In whatwg/html#3518 Apple engineers propose a new attribute for <input type=password> that'll assist password generators doing the right thing.

I'm personally enthusiastic about the idea.

(There's many small incremental features like this added to WHATWG standards. It's not quite clear to me if we want an issue for each of them, but we probably do want a Mozilla position on each of them, so... Filing this one as a test.)

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Payment Request
• Specification or proposal URL: w3c/payment-request#694

Other information

The Payment Request API currently only checks that monetary values passed into it adhere to the ISO4217 currency format: ASCII 3-alpha (e.g., "USD", "EUR", etc.). However, the spec doesn't ask the browser to check if those are "real" (fiat) currencies - which would be possible by checking against ISO4217 itself (maintained and updated by ISO).

There is a proverbial elephant in the room around cryptocurrencies, such as "BTC", which, although they conform to the ISO4217 "currency format", may or may not be "real" currencies.

Recently, Facebook, Google, and soon possibly Twitter, have banned advertising crypto currencies in their platform due to high levels of fraud.

When using the Payment Request API, I personally fear that by not checking if a currency is registered with ISO (as a "real" currency), we might subject Firefox users to fraud. For instance, a website might insist that you can only buy things with a particular crypto currency (or similar scams already seen).

What I'd like to propose is that, at a minimum, all currencies (including cryptocurrencies) be first blessed by ISO before they can be used with the Payment Request API. Coincidently, ISO is exploring the possibility of formally registering cryptocurrencies. This would be a minimum level of due diligence that would be required to use a currency.

Opinions? Is this something we (Mozilla) should push for in the spec (e.g., "if it's not in ISO4227, throw a RangeError." )? Or maybe just an assurance we implement into Firefox?

Opinions would be appreciated.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Locks
• Specification or proposal URL: https://wicg.github.io/web-locks/
• Explainer: https://github.com/WICG/web-locks/blob/master/EXPLAINER.md
• Chrome Intent to implement

Other information

Google is proposing, "a new web platform API that allows script to asynchronously acquire a lock over a resource, hold it while work is performed, then release it. While held, no other script in the origin can acquire a lock over the same resource. This allows contexts (windows, workers) within a web application to coordinate the usage of resources."

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Client Hints
• Specification or proposal URL: https://tools.ietf.org/html/draft-ietf-httpbis-client-hints
• Caniuse.com URL (optional): https://caniuse.com/#feat=client-hints-dpr-width-viewport
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=935216

Other information

• w3ctag/design-reviews#206

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Background Fetch
• Specification or proposal URL: https://wicg.github.io/background-fetch/

Other information

An API to handle large uploads/downloads in the background with user visibility.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Priority Hints
• Specification or proposal URL: https://github.com/WICG/priority-hints, whatwg/html#3670

Other information

Currently web developers have very little control over the heuristic importance of loaded resources, other than speeding up their discovery using <link rel=preload>. Browsers make many assumptions on the importance of resources based on the resource's type (AKA its request destination), and based on its location in the containing document.

This spec proposes to give developers the control to indicate a resource's relative importance to the browser. This would allow the browser to act on those indications to modify the time it sends out the request and its HTTP/2 dependency/weight so that important resources are fetched and used earlier.

In theory, giving the developer control over priority may lead to an improved the user experience.

Someone with administrative access should link https://mozilla.github.io/standards-positions/ from the top of https://github.com/mozilla/standards-positions.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Feature Policy
• Specification or proposal URL: https://wicg.github.io/feature-policy/

Other information

This is WICG proposal.

A web platform API which gives a website the ability to allow and deny the use of browser features in its own frame, and in iframes that it embeds. Examples of features that could be controlled by feature policy include:

• getUserMedia (Camera, Speakers and Microphone)
• Fullscreen
• Geolocation
• MIDI
• Payments
• Synchronous XHR
• Synchronous scripts
• Vibrate

There is also a detailed explainer

Introduction to Feature Policy

Based on the intro and the structure of the process, I think that we probably want the following labels: w3c, ietf, ecma. @marcoscaceres has been modifying titles, which doesn't really scale well. We probably want the coordinators to be responsible for applying labels.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Improving Ergonomics Of Events With Observable
• Specification or proposal URL: whatwg/dom#544

Other information

This is a proposal from Google with interest on the part of the Chrome team to add the Observable type to the browser as part of the EventTarget API. It is loosely related to the TC39 Observable proposal, where it was determined that they would like to see it's usefulness demonstrated as part of the platform.

See for example the description produced by doing

./activities.py add https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/

There is a minor misunderstanding around the WICG process implied in this repo. The WICG process doesn't require a spec until after two or more browser vendors have agreed that it would be interesting to explore or spec out a technology around a set of use cases.

What should normally happens at the WICG is:

1. A proposal is made on a discourse thread that outlines the use cases, and maybe a rough API shape.
2. A bunch of questions are asked about the proposal from developers and interested parties.
3. An attempt is made to get two browser vendors to say "yeah, that could be interesting - we should totally work on that together" (this is where the feedback from this repo will play a huge role!).
4. The WICG chairs check the proposal and then spec work actually begins (the the Chairs either creating or migrating a Github repo over to the WICG).

Here is a typical example that started as "Face Detection", involving people from Google, Microsoft, Intel, Mozilla, etc. providing input:
https://discourse.wicg.io/t/rfc-proposal-for-face-detection-api/

And ultimately moving to a incubation as a more general "Shape Detection API":
https://github.com/WICG/shape-detection-api

So, for (new) WICG things, I expect us to see links to the discourse discussions... there are some existing specs (e.g., priority hints) where we could point to an actual repository, however.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Signature-based Resource Loading Restrictions
• Specification or proposal URL: https://github.com/mikewest/signature-based-sri

Other information

There's a discussion starting at https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0000.html that's quite relevant. @sleevi's comments at https://lists.w3.org/Archives/Public/public-webappsec/2017Jun/0004.html are particularly intriguing.

You'll also probably find the TAG review discussion at w3ctag/design-reviews#186 interesting, as well as the (sparse) minutes from TPAC last year (with @dveditz, @TanviHacks, and @ckerschb in attendance): https://www.w3.org/2017/11/07-webappsec-minutes.html#item04.

We should probably tweak the help so that this makes sense when the repo becomes public.

Something could be both important and sponsored. Or involved and sponsored. Or harmful and alternative preferred. Maybe we should start out simpler and use the description field for the nuance.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Packaging Format
• Specification or proposal URL: https://tools.ietf.org/html/draft-yasskin-dispatch-web-packaging-00

Other information

It will allow people to bundle together the resources that make up a website, so they can be shared offline, either with or without a proof that they came from the original website.

Repo: https://github.com/WICG/webpackage

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebMIDI
• Specification or proposal URL: https://webaudio.github.io/web-midi-api/
• Caniuse.com URL (optional): https://caniuse.com/#feat=midi
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=webmidi

Other information

WebMIDI has been in development in Firefox since 2015. The DOM API (https://bugzilla.mozilla.org/show_bug.cgi?id=1201590) recently landed, but is pref'd off on all branches, runs only in tests, and was mostly landed to curb bit-rot. Platform implementation bugs exist at:

• Mac: https://bugzilla.mozilla.org/show_bug.cgi?id=1201593
• Windows: https://bugzilla.mozilla.org/show_bug.cgi?id=1201596
• Linux: https://bugzilla.mozilla.org/show_bug.cgi?id=1201598

The major blocker right now is security issues related to device firmware hijacking. There's a public google doc available listing issues and ideas for mitigation at

https://docs.google.com/document/d/1SjYRmNvQKxOPHufWbx6n0NOeTKKd_O1WIiTBZAjVj5E/edit#heading=h.lavkfo6fb57g

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Accelerated Shape Detection in Images
• Specification or proposal URL: https://wicg.github.io/shape-detection-api

Other information

Photos and images constitute the largest chunk of the Web, and many include recognisable features, such as human faces, QR codes or text. Detecting these features is computationally expensive, but would lead to interesting use cases e.g. face tagging, or web URL redirection. While hardware manufacturers have been supporting these features for a long time, Web Apps do not yet have access to these hardware capabilities, which makes the use of computationally demanding libraries necessary.

It should be clear they're public from the fact that everyone can access them. (Happy to provide a PR by the way, figured I'd assess agreement first.)

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Testing in standards: from idea to full interop
• Specification or proposal URL: https://github.com/foolip/testing-in-standards/blob/master/lifecycle.md

Other information

Proposes to enhance the w3c work mode to more closely align with the WHATWG Work Mode. It would be a grass roots effort.

In particular, encourages more use of ".tentative" as a filename post-fix to identify things in Web Platform Tests on which implementers don't have agreement on.

This is part of a larger discussion we've been having with Google about what ends up in WPT (and https://wpt.fyi). For example, should "Web Share" tests be part of the WTP without having the ".tentative" post-fix? (please don't fixate on Web Share, on which we have not yet taken a position #27, I'm just using it as an example).

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Payment Method Manifest
• Specification or proposal URL: https://w3c.github.io/payment-method-manifest/

Other information

This specification allows both web applications and native applications (specially on Android) to act as "payment handlers": A "native payment handler" is an native application capable of either settling a monetary transaction and returning a proof-of-payment token (e.g., the PayPal native app), or providing a website with an end-user's credit card information (e.g., Microsoft Wallet).

The purpose is to allow websites to bypass the browser's built in credit card store or "wallet", and to use, for instance, the natively installed PayPal application instead to settle a transaction.

Currently proposed by Google to the Web Payments Working Group. This spec is potentially controversial as it's specifically designed to bypass web applications to allow users to just use native apps.

However, to give the web the same capability, the Web Payments WG is proposing a specification called the Payment Handler API (will send a separate RFP).

Used by:

• Google Chrome
• Samsung Pay

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Thing API
• Specification or proposal URL: http://iot.mozilla.org/wot/

I'm filing this to some degree on behalf of @benfrancis, who I think doesn't yet have access to this repo.

I think this is in some sense a request for dual Mozilla positions, both on the work of the WoT interest group, and of Ben's proposal to change that work.

Other information

I asked @benfrancis 4 questions about this (in bold), and he wrote up his answers which I quote below:

1. what is the W3C WoT IG building, and how is it intended to be used?

1. A plain JSON serialization of a Web Thing Description for describing physical devices connected to the web
2. Incubation of a REST & WebSockets Web Thing API for monitoring and controlling connected devices over the web

This machine readable description format and API will be used by connected devices, IoT gateways and IoT cloud services to expose a consistent web interface to be consumed by software applications including web applications using existing browser APIs.

This work will combine lessons learned from implementations of the Web Thing Model member submission from the EU funded COMPOSE project and Mozilla's Web Thing API draft member submission (as well as prior art from multiple proprietary API implementations which use web technologies) into a single combined proposal to the Web of Things Working Group to eventually turn into a W3C specification.

2. how is Mozilla hoping to influence/change the work product of the WoT IG?

Mozilla hopes to assist with combining two previous Interest Group member submissions to create a more concrete and pragmatic application of the abstract data model being developed by the Web of Things Working Group, using existing web technologies like JSON, HTTP, WebSockets and TLS.

We would like the output of the Interest Group task force to be a proposal to the Working Group for a Web of Things approach which uses existing proven web technologies and security practices and appeals to web developers, without requiring knowledge of RDF and the semantic web or the standardization of any new scripting API or application runtime.

We believe this work complements the existing work of the WoT Working Group but could help move it in a more pragmatic and concrete direction which has been proven through multiple commercial implementations.

3. what do you think Mozilla should do with (e.g., implement, and how) the results of the work of the WoT IG?

The IoT team at Mozilla has a working open source implementation of a Web of Things gateway (source code on GitHub) which will be iterated upon as the Web Thing Description format and API develop.

4. How do (2) or (3) advance Mozilla's mission or the principles in its manifesto?

The vision of the Mozilla IoT team is an open and decentralized Internet of Things that puts people first, where individuals can shape their own experience and are empowered, safe and independent.

The Web of Things is about creating a decentralized Internet of Things by giving Things URLs on the web to make them linkable and discoverable, and defining a standard data model and APIs to make them interoperable. The idea is to apply lessons learned from the World Wide Web to the Internet of Things and to use the web as a unifying application layer protocol which bridges together many underlying IoT technologies.

The mission of the Mozilla IoT team is therefore to create an open source Web of Things implementation which embodies Mozilla’s values and helps drive IoT standards for security, privacy and interoperability.

Raising this per suggestion from @dbaron in #59. I'm not really sure how to split this up since as per https://github.com/w3c/webcomponents/blob/gh-pages/README.md the situation is complicated.

• Shadow DOM: we're implementing "v1" and this is now part of the DOM and HTML standards. (Some parts ended up in CSS, UI Events, Touch Events.)
• Custom elements: we're implementing "v1" and this is now part of the DOM and HTML standards.
• HTML Templates: shipped and now part of the HTML standard.
• CSS changes: I'm not sure what the status is here.
• HTML Imports: this is now abandoned I think. We've opposed this in the past: https://hacks.mozilla.org/2014/12/mozilla-and-web-components/.

On top of that there's various new proposals which @smaug---- and I should know more about next week (there's a meeting). My thinking is that we'll open issues for those proposals, but that for the above (apart from the CSS bits) we don't really need anything.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Gamepad Haptics
• Proposal URL: https://docs.google.com/document/d/1jPKzVRNzzU4dUsvLpSXm1VXPQZ8FP-0lKMT-R_p-s6g
• Bugzilla URL: https://bugzilla.mozilla.org/show_bug.cgi?id=680289

Other information

Gamepads have been rumbling since 1997, it's time we brought this capability to the web!

The proposal would add support for rumble effects of the sort that are common on console gamepads like the Dualshock or Xbox 360 controller. Two motors, located in the gamepad handles, with off-center weights. Although other types of effects and actuators are not yet specified, the proposal is intended to offer a clear path for extending support to a wider array of haptic devices.

We brought the topic up in the #webplat group at TPAC 2017 and received no objections to moving forward with the spec. marcosc asked that we reach out for feedback on this repo. Please take a look!

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Picture-in-Picture
• Specification or proposal URL: http://wicg.github.io/picture-in-picture
• Caniuse.com URL (optional):
• Bugzilla URL (optional):

Other information

This specification intends to provide APIs to allow websites to create a floating video window always on top of other windows so that users may continue consuming media while they interact with other content sites, or applications on their device.

• Chromestatus URL: https://www.chromestatus.com/feature/5729206566649856

cc @mounirlamouri

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Streams Standard
• Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1493537
• Specification or proposal URL: https://streams.spec.whatwg.org/#ts

Other information

Mozilla has been a great contributor to the streams API in general. We were hoping to get a sense of how they (probably specifically folks like @wanderview and @tschneidereit) were feeling about the TransformStreams section.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Payment Handler API
• Specification or proposal URL: https://w3c.github.io/payment-handler/

Other information

The Payment Handler API allows a web application to register itself as capable of handling a "payment request". That is, it claims to either be able to settle a monetary transaction or is potentially capable of supplying a requesting website with payment instrument (e.g., a credit card) on behalf of the end-user.

For example, wallet.com could register itself as being able to handle requests for credit card information on behalf of the user. Then merchant.com can say: "I support 'wallet.com', if you'd like to pay with that". Then requests for payment are routed to wallet.com (via a service worker), and wallet.com responds with either a proof-of-settlement token, or possibly a payment instrument like a credit card number.

This allows Payment Handlers to work along side the browser's built in wallet: giving the user a choice of either picking a credit card form the browser's wallet, or letting wallet.com provide a token or credit card number (and possibly other things... that's still up for discussion).

This specification already has some Mozilla support (e.g., @adamroach and I have contributed to it) - but wanted to bring it to people's attention while it's still early.

The title says these are Mozilla positions, but the <h1> says Firefox. Should we instead use the Mozilla logo and change <img alt> accordingly?

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Geolocation Sensor
• Specification or proposal URL: https://w3c.github.io/geolocation-sensor/

Other information

Geolocation API refactored to use Generic Sensor spec.

In whatwg/html#3538 a new attribute is proposed for all elements. It allows the page to control the visual label of the virtual keyboard enter key to some extent (it's an enum) when a visual keyboard is shown for that element (e.g., when it's editable and focused).

Publish to https://mozilla.github.io/standards-positions/

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Share API
• Specification or proposal URL: https://wicg.github.io/web-share/

Other information

Currently behind a flag in Chrome as an "origin trial".

This specification defines an API for sharing text, links and other content to an arbitrary destination of the user's choice. The available share targets are not specified here; they are provided by the user agent. They could, for example, be apps, websites or contacts.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Proposal for a z-layer property
• Specification or proposal URL: https://discourse.wicg.io/t/proposal-for-a-z-layer-property/2364

Other information

Proposal to group z-layer properties into groups as a means of solving the z-index: 9999999999 hack everyone uses.

@dbaron - maybe you can suggest some Moz CSS folks to ping for opinions?

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WHATWG Working Mode
• Specification or proposal URL: https://whatwg.org/working-mode

Other information

We need to have a discussion about the WHATWG Work Mode and to WHATWG testing policy. This includes taking an organizational position on Living Standards.

Personally, I'd like to see us all get behind:

• Incubation process.
• Living standards.
• Spec changes must be accompanied by tests.

And that groups we WGs participate in make a best effort to follow the above.

#1 indicates that content from this repository will be published on GitHub Pages, and the README is written as if for the general public. It would drastically simplify licensing concerns for this soon-to-be-published content if this repository applied a LICENSE prior.

https://www.mozilla.org/en-US/foundation/licensing/ encourages CC-SA for pure-content websites, and otherwise we use MPL2 for all repositories not otherwise compelled to use a specific license.

• Specification Title: Suborigins
• Specification or proposal URL: https://w3c.github.io/webappsec-suborigins/

There are many outstanding issues still, but I personally think the general idea is sound. Since I have invested some time in it already it seems good to raise it here as well.

cc @ckerschb @dveditz

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: CSS Shadow Parts
• Specification or proposal URL: https://drafts.csswg.org/css-shadow-parts/
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): N/A

Other information

Over in w3c/csswg-drafts#2368, Mozilla was asked for a position on this spec draft.

Explainer: https://meowni.ca/posts/part-theme-explainer/

• Specification Title: Trusted Types for DOM Manipulation
• Specification or proposal URL: https://github.com/WICG/trusted-types/blob/master/README.md

It seems useful to figure out something here early given its impact across a wide range of standards.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Budget API
• Specification or proposal URL: https://wicg.github.io/budget-api/

Other information

• Google Blog: https://developers.google.com/web/updates/2017/06/budget-api
• Origin Trialed: https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/completed-trials.md
  • First available in Chrome M60. Trial ended on October 17, 2017.
  • Feature team currently considering the next steps for the feature.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: BigInt
• Specification or proposal URL: http://tc39.github.io/proposal-bigint
• Caniuse.com URL (optional): None
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1366287

Other information

BigInt provides a second numeric type in JavaScript: unlimited-size integers. In the Blink Intent to Ship thread for BigInt, @bzbarsky noted that, although @cxielarko has been developing a BigInt implementation for SpiderMonkey (as an employee of Igalia, as part of partnership Bloomberg), it has not yet been accepted by Mozilla engineers. It'd be great to have an official Mozilla position on whether BigInt should be added to the Web Platform.

cc @tschneidereit @syg @jorendorff @jswalden

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Async cookies
• Specification or proposal URL: https://github.com/WICG/async-cookies-api/blob/gh-pages/explainer.md

Other information

Asynchronous cookie API to scripts running in HTML documents and service workers.

Seems Blink team is sending tests for this API to WPT - but marked as "don't merge" rn.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Media Session Standard
• Specification or proposal URL: https://w3c.github.io/mediasession/
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1112032

Other information

Add support for media keys and audio focus to the Web. Media keys, like play, pause, fast forward and rewind, are found on keyboards, headsets, remote controls, and on lock screens of mobile devices.

I think Chrome is shipping this in Chrome for Android.

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Notifications API
• Specification or proposal URL: whatwg/notifications#93

Would be great to if we could create a read-only access group that would allow folks like @annevk and myself to assign issues to people. This can be done via "Settings" -> "Collaborators & teams", and adding us there with "read-only" access.

Other folks who want to be included in that group should respond here. Hopefully, by assigning issues to people, we might be able to get some things moving a bit more quickly ... fingers crossed!🤞

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: IndexedDB Observers
• Specification or proposal URL: https://github.com/WICG/indexed-db-observers/blob/gh-pages/EXPLAINER.md

Other information

Name is fairly self explanatory. Right now, it's just a rough outline being proposed by Google folks, I believe.

At least for PRs against WHATWG standards we need a stronger signal than "participating" gives. We need something that indicates support. That's not a commitment to implement, but it is an endorsement of the feature that allows others to go ahead and implement it, to add tests to web-platform-tests, etc.

My initial hope for this repository was that we could have something where one could raise a standards-related issue with Mozilla stakeholders and determine a position on that issue. The way it's structured now doesn't really lend itself to that.