- From: Alex Russell <notifications@github.com>
- Date: Tue, 05 Feb 2019 00:23:17 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 5 February 2019 08:23:38 UTC
Hey @clelland, Thanks for filing for a review. A few questions from today's F2F discussion with @torgo, @sideshowbarker, @ylafon, @torgo, and @alice. First, we acknowledge that this work appears to be a follow-up from our suggestions in #159 that the allow attribute superset the set of sandbox attributes. Thanks for doing this. * What's the interaction between a non-null `sandbox` policy and `allow`? E.g., if sandboxing prevents something, but `allow` enables it, who wins? The processing order doesn't seem to be specified. * Do you have data about the usage of sandbox attributes? On what timeframe would a deprecation be possible? * As a meta point, the explainer doesn't really address the question of why this solves an important problem for developers. Given that this might make controlling feature use easier and provide a single way to do it, that seems worth calling out. * An aside: t seems like there's some overlap between `document.featurePolicy.allowsFeature()` and the Permissions API. How is that going to be resolved? Are the semantics the same? Which one should a developer use? Are events sent to `document.featurePolicy` to note when things are relaxed or tightened? -- 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/339#issuecomment-460550546
Received on Tuesday, 5 February 2019 08:23:38 UTC