On Monday 2017-09-25 09:12 -0400, Boris Zbarsky wrote: > On 9/25/17 9:01 AM, Anne van Kesteren wrote: > > It does not seem hard to come up with solutions to those problems, if > > we're actually committed to going down this path. > > If we are, yes. We need to decide whether we are... > > > (E.g., just like globals have isSecureContext, > > there could be a media query that can be used from CSS for the same > > purpose. Or @supports could be used if we make parsing fail.) > > Right, so we could block worklets on new CSS features to be specced in the > CSSWGs copious free time. ;) I say this tongue-in-cheek, but the CSS > editing situation is pretty horrible. We _still_ don't have a spec for > <link rel="stylesheet"> at all, in any meaningful sense. :(
I don't think this is a big deal. What I proposed in https://github.com/w3ctag/design-principles/pull/75 (which I think the TAG will have a full discussion of this week) was that the secure context restriction apply at the points where major features are commonly added, and when they're feature-detectable. So for new CSS features restricted to a secure context, they wouldn't parse in a non-secure context, and @supports would do the right thing. So I don't think this requires any new *features* to be spec'd in CSS (since @supports would work, and is the right thing to use), although it probably does require a small amount of new spec prose to explain how it works. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: PGP signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
