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

We discussed this twice during the Iceland F2F. One was with @triblondon, and @dbaron and I had a separate discussion on this as a breakout.

While it is somewhat unclear what is expected from us here, so we considered it as a open-ended request for the time being.

First of all, we are supportive of the spec being split into three different things - we believe this allows better division of work and being able to ship the less-complex parts sooner.

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.

Spec templates should ideally be updated to have a separate fixed section for feature policy identifer, to be 1) machine parsing friendly and 2) easier to find by readers. This does beg the question whether or not long term there should be a registry, which is more of a question than a suggestion.

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. This relates to an issue that we should be looking at: w3ctag/design-principles#41

-- 
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-494799991