Re: Intent to ship: CSS subgrid
On Thursday, October 17, 2019 at 3:15:49 PM UTC-7, Sean Voisen wrote: > On Thu, Oct 17, 2019 at 1:05 PM wrote: > > > > > These features (broadly speaking) are different however. According to the > > above policy: > > "Exceptions to requiring secure contexts" > > " - other browsers already ship the feature insecurely" > > > > Most (all?) of the non-trivial features above have shipped in other > > browsers insecurely before shipping in Firefox, hence the above exception > > applies. > > > > But it also says: "In contrast, a new CSS color keyword would likely not be > restricted to secure contexts." Given that this is a new value for > grid-template-*, and not a new CSS property, I'd argue it doesn't apply. 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. > > > "subgrid" is different as Firefox is shipping this feature first. > > > > I believe we were also first to ship the support for multiple display > values, but again those are values. And I think we're the first on > ::marker. These were not restricted. Again "multiple dipslay values" are probably in the "trivial" feature bucket (if that exists). ::marker (which seems like it was only shipped recently) probably should have been restricted to secure contexts by this policy? > > > > As far as I know we don't even have a mechanism that I could > > > have used to restrict subgrid to secure contexts. And to be > > > clear: I have no intention of blocking subgrid on waiting for > > > such a mechanism. > > > > This should just involve passing a isSecureContext flag into the your CSS > > parser? > > > > There's also the consideration as to whether allowing grid in non-secure > contexts, but NOT subgrid, even makes sense. I think it would oddly > fracture support for grid layouts as a whole (or at least potentially make > things confusing for developers — it's certainly more confusing than just > restricting access to a single property like backdrop-filter or something). > Perhaps we should ask what the value of restricting only subgrid to secure > contexts even brings. If part of the spirit of the policy (at least the > part that applies here) is to quicken adoption of secure contexts, is the > value of subgrid's contribution to this endeavor worth the trade-off of > potential user confusion? For almost any CSS feature you could make a similar argument I believe. I think one interesting part here is that (from my knowledge) this policy actually hasn't been applied yet, due to the "other browsers shipping insecurely" exception. But all good questions! > > > Given this shouldn't a "...Mozilla’s Distinguished Engineers to judge the > > outcome..."? > > > > It's an interesting test of the policy. Thanks for bringing it up :) No problem! I trust the Mozilla community will decide on a reasonable outcome, and update the policy if necessary. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
On Thursday, October 17, 2019 at 12:47:27 PM UTC-7, Mats Palmgren wrote: > On 10/17/19 8:12 PM, ikilpatr...@chromium.org wrote: > > On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren > > wrote: > >> As far as I know, we never constrain new CSS features to secure > >> contexts. At least not on the property/value level. > > > > According to > > https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ > > you should be? > > > > "Effective immediately, all new features that are web-exposed are to be > > restricted to secure contexts. Web-exposed means that the feature is > > observable from a web page or server, whether through JavaScript, CSS, > > HTTP, media formats, etc." > > True, but we have never applied that policy for CSS features > as far as I know. Just recently we've added 'column-span', > the ::marker pseudo, new 'display' syntax with values like > 'inline list-item', 'block ruby' etc, 'clip-path: path()', > and a long list of other CSS features since 2018. These features (broadly speaking) are different however. According to the above policy: "Exceptions to requiring secure contexts" " - other browsers already ship the feature insecurely" Most (all?) of the non-trivial features above have shipped in other browsers insecurely before shipping in Firefox, hence the above exception applies. "subgrid" is different as Firefox is shipping this feature first. > As far as I know we don't even have a mechanism that I could > have used to restrict subgrid to secure contexts. And to be > clear: I have no intention of blocking subgrid on waiting for > such a mechanism. This should just involve passing a isSecureContext flag into the your CSS parser? > > > Or does the policy wrong and needs to be updated? > > Maybe, but that's not for me to decide. > > The issue you raise is a good one, but it's not really related > to subgrid specifically. Perhaps it would be better if you > start a new thread regarding how that policy applies (or not) > to CSS features in general? See above - I believe it actually is only related to this feature, as it is shipping in Firefox first. Given this shouldn't a "...Mozilla’s Distinguished Engineers to judge the outcome..."? > > /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren wrote: > On 10/17/19 5:35 PM, ikilpatr...@chromium.org wrote: > > On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren > > wrote: > >> *Secure contexts:* N/A > > > > Replying as requested from: > > https://twitter.com/ecbos_/status/1184690249324290048 > > Well, I just copy-pasted the email-template TYLin used in his > intent-to-ship for 'column-span' earlier, so I assumed "N/A" is > the correct term... :-) > > Anyway, I don't think we constrain new CSS properties/values to secure > contexts in general. As far as I know, we don't even have a mechanism > for doing so. So "N/A" seems appropriate. > > > > Subgrid is a new feature to CSS behind a new display value [...] > > No, 'subgrid' is not a new 'display' value. It's a new value for > the 'grid-template-rows/columns' properties: > https://drafts.csswg.org/css-grid-2/#subgrid-per-axis My bad, but the same principle applies. > > > Does > > https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ > > apply here? > > As far as I know, we never constrain new CSS features to secure contexts. > At least not on the property/value level. According to https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ you should be? "Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. " Or does the policy wrong and needs to be updated? > > /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
