Re: [w3ctag/design-reviews] Feature policy evolution (#341)

Thanks for looking at this, @cynthia (and the rest of TAG)!

> One of the points that came up is that for cases where a feature policy will make an API disappear (e.g. deprecation of document.write) there is plumbing that will be required in WebIDL, and the fact that there is a path for disabling these features seems like a useful addition to the platform.

This is good to hear -- it's not something that has been proposed recently; in all of the cases where we thought we'd want to have FP control visibility of JS attributes, we eventually concluded that having methods exist, but fail in some well-defined way was less disruptive. Long term, though, actually removing APIs from the platform would be a good thing, I think.

> This does beg the question whether or not long term there should be a registry, which is more of a question than a suggestion.

We're tracking this idea in https://github.com/w3c/webappsec-feature-policy/issues/244 -- I was orignally opposed, but I've come around to the idea that there should probably be one, for interoperability of nothing else.

> There should definitely be strong guidance on the naming conventions of these following the points above, so the initial status is either as positive as possible of as negative as possible, and not named against the default state of the policy.

Can you give an example of what you mean by "not named against the default state of the policy"? Are there current features which we should be looking at renaming before they get too much traction?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/341#issuecomment-497079946