On Fri, Oct 18, 2019, at 9:31 AM, ikilpatr...@chromium.org wrote: > I'd argue that the color example is a "trivial" feature, unlike > subgrid. But the original framer of the policy would have a better > understanding of what that meant. > > FWIW most new CSS features are placed behind values/etc, so I don't > believe that is the distinction in the policy.
That's true. And I agree it is not "trivial". The policy is (rightly) vague so we can make a judgement call, though I would probably side with others in thinking that this is an extension of an existing feature. But I think we've ended up with practical considerations dictating whether we restrict a given CSS feature to secure contexts. I have some half written patches from a couple of years ago to add support in Gecko for hiding individual properties (though not values) behind a secure context flag. I ran into the issues that Emilio mentioned, where it affects shorthand serialization in a way that is not as easy to handle as pref-controlled properties, and would result in additional state propagated down onto declaration objects. Far from impossible to handle, but it made us stop and think whether it was worth it. If I remember correctly, when the issue of gating CSS features behind secure contexts was brought up in the CSS Working Group last, the response was tepid. So at this point I wonder whether it is worth trying to restrict features at the CSS syntax level. Secure context restrictions are a kind of best effort thing to help encourage authors to switch to https, and it's not necessary for 100% of new features to be restricted to achieve that. Unlike Web IDL defined features, where it's easy to drop in [SecureContext] in the spec and in our implementations, there is some work involved here to restrict CSS properties or values. If other vendors are willing to add the ability to make CSS properties and values be unavailable in secure contexts to their engines, then I can resurrect my patches. But if that's not likely to happen, I think it's probably best to concentrate our restriction efforts on DOM APIs, where I believe it's still the right thing to do. (Including for Paint API.) I'm curious to hear if others think differently. Thanks for raising this Ian, and I hope we can clarify our policy as a result of this discussion. Cameron _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
