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.

dev-platform mailing list

Reply via email to