-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace Feature Policy integration with Document Policy. #295
base: main
Are you sure you want to change the base?
Conversation
This would close #296 |
I'm not sure if @martinthomson's comment there implies implementer interest. Were there existing tests that need to be modified to address this? (Should Document Policy move to its own repository?) |
That's fair; should I request an official position on MSP? I figured that your comments here, here, 👍 here, and @martinthomson's comments and 👍 there were at least indicative of interest, and at least met the non-binding support mentioned in Changes (there aren't any descriptions of more formal processes there). I'm happy to follow whatever process makes sense for WHATWG; in the meantime, I've removed the indication of support in the issue description. Test changes to WPT are inbound; there are always chicken-and-egg issues with these things. Moving Document Policy to its own repo is a better issue to raise with WebAppSec, I think, than here. |
We're being very careful to distinguish between interest (lots of stuff is interesting) and outright support. If you want a clear indication of support then asking is best. Of course, if we've implemented something, feel free to interpret that as support in the absence of other signals, but those cases are usually fairly obvious. |
I think that what is asked for in the issue template (and what I figured I was responding to originally) is interest, but the working mode doc only mentions support, so I'm no longer sure what the criteria for checking the box there is. If it needs a "we are planning on implementing this soon"-level-of-support, then certainly this PR can stay open until it gets there (if ever). I'm fine letting the box stay unchecked until we have whatever level of consensus is needed. |
Sorry for the lack of clarity, what the WHATWG looks for is support in the sense of "should be part of the web platform" (roadmap matters a bit less, though in practice we look for at least one implementer having it on there). I don't think Firefox is there yet for Document Policy, though it's a better and more principled approach than what preceded it. |
See whatwg/xhr#321: > We should probably drop this section for now as it doesn't have > multi-implementer interest. Related: whatwg/xhr#295
See whatwg/xhr#321: > We should probably drop this section for now as it doesn't have > multi-implementer interest. Related: whatwg/xhr#295
See whatwg/xhr#321: > We should probably drop this section for now as it doesn't have > multi-implementer interest. Related: whatwg/xhr#295
As an update, we're removing the Permissions Policy-based integration in #322. This can then be rebased for the Document Policy-based integration and merged when there's sufficient implementer support for Document Policy. |
Feature Policy is now known as Permissions Policy and sync-xhr is no longer part of it. It is now part of Document Policy. See #295 for follow-up work.
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff