mozilla / standards-positions Goto Github PK
View Code? Open in Web Editor NEWHome Page: https://mozilla.github.io/standards-positions/
License: Mozilla Public License 2.0
Home Page: https://mozilla.github.io/standards-positions/
License: Mozilla Public License 2.0
See for example the description produced by doing
./activities.py add https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/
The title says these are Mozilla positions, but the <h1>
says Firefox. Should we instead use the Mozilla logo and change <img alt>
accordingly?
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.
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
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.
We should probably tweak the help so that this makes sense when the repo becomes public.
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."
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.
#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.
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:
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.
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!
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.
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.
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:
And that groups we WGs participate in make a best effort to follow the above.
It seems useful to figure out something here early given its impact across a wide range of standards.
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 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.
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:
There is also a detailed explainer
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.
Someone with administrative access should link https://mozilla.github.io/standards-positions/ from the top of https://github.com/mozilla/standards-positions.
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!🤞
An API to handle large uploads/downloads in the background with user visibility.
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.
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.
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?
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.
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.
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?
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.
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.
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:
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
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.
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).
Name is fairly self explanatory. Right now, it's just a rough outline being proposed by Google folks, I believe.
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.
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.)
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.)
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.
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).
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.
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.
Over in w3c/csswg-drafts#2368, Mozilla was asked for a position on this spec draft.
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.
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.
Geolocation API refactored to use Generic Sensor spec.
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 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.
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.