#341: Permissions policy (formerly feature policy) evolution
Discussions
2019-05-01
Dan: bigger issue rather than review?
Sangwhan: I'd be happy to kick to face-to-face.
Dan: How should we structure? Bring in people who are working in the feature policy space? Facilitate a discussion between us and Andrew and others? These issues still seem to be quite open.
Sangwhan: I think I need to digest the potential of what is currently shipped and get myself filled in on background, and then involve other people.
David: Also related to an issue we have elsewhere, maybe design-principles, about six different mechanisms for blocking stuff.
David: Maybe need work before the face-to-face if it's going to be useful -- need to figure out how.
Dan: I'm commenting on the issue.
Dan: Will bump a week. Let us know if you have ideas about how to structure discussion. This isn't a review in that sense, but feels like something we ought to be paying attention to.
Alice: Does it feel like something that could feed into design principles doc? Would be very specific.
Tess: definitely
Tess: feature policy is a client api, naming is part of good api design. One of issues here about how weird the naming is. There's a broader question about design of the feature in the future.
David: I don't feel like it's too specific for design-principles doc. Would be good if other spec bits link to it.
Tess: There's a separate doc about promises. We don't have a separate thing for the things you should think about when designing a feature policy; it should go in the catch all
2019-05-08
David: i think we need to bump this to f2f [and 349]
Tess: do we know if Andrew will call in for it?
Dan: I will reach out to Andrew
2021-01-Kronos
Feature policy was split into permissions policy and document policy. All the issues we had were either addressed or moved into document policy. Closing.
OpenedFeb 7, 2019
こんにちはTAG！
Special delivery courtesy of your request of me earlier this evening. I would like to draw your attention to two aspects of Feature policy. Feature policy itself was reviewed by the TAG while I was a member and generally judged to be splendid. However, being a 'framework spec' (my term for a spec that creates a scaffold on which elements of its behaviour will operate, but where those elements are defined elsewhere or not within the same process), it has developed in a way that might attract further interest:
Whilst policies are generally named for the behaviour that they allow, in some cases they are named after the behaviour that results from denying the policy. 'lazyload' is one such policy. In the default case, where no policy is defined or it is defined and allowed for the relevant origin, the document follows the instructions of the lazyload attribute, which defaults to immediate ('eager', if you like) loading. If a policy is defined and disallowed for the relevant origin, the page forces all elements to be lazyloaded. This could be considered counterintuitive, and if the TAG were to take a view, I would imagine it would be on the principle rather than this specific instance.
Feature Policies are booleans, but there is a proposal to make them parameteri[sz]ed. Some of the examples cited for parameterised policies seem to suggest that the value would be required ('allowed-image-formats' seems not to make sense without a value), while others which already exist as boolean policies become quite different when in parameterised 'mode' (eg lazyload), and still others seem like they are fundamentally booleans so the behaviour if a value is supplied is undefined (eg document-write).
Ref: