On a practical point as a web developer, in this case CSS subgrid is a part of the wider CSS grid feature. It seems odd to make parts of the CSS grid feature available in insecure contexts while other parts (subgrid) are unavailable. I would argue this decision should have been made for the CSS grid feature as a whole, and apply consistently to all aspects of the CSS grid feature, so we don't end up with the compatibility nightmare of bits-and-pieces of features being available in some cases but not others.
On Tue, 22 Oct 2019 at 09:54, James Graham <ja...@hoppipolla.co.uk> wrote: > On 22/10/2019 00:07, L. David Baron wrote: > > On Monday 2019-10-21 16:01 -0500, Mike Taylor wrote: > >> Hi David, > >> > >> On 10/21/19 7:22 AM, L. David Baron wrote: > >>> (That we haven't applied the policy that much because we've granted > >>> exceptions because other browsers have shipped the features reduces > >>> the effectiveness of the policy and its ability to meet its goals. > >>> This is the sort of policy that is most effective if it applies to > >>> the largest number of thngs, both because it has larger effects and > >>> because it sets much clearer expectations about what will be limited > >>> to secure contexts. I think it's worth considering reducing that > >>> exception to the existence of actual web compat problems from the > >>> secure contexts limitation.) > >> > >> Can you unpack this a little here? > >> > >> Are we saying we would ship features in non-secure contexts because > sites > >> theoretically rely on that behavior due to another browser shipping as > >> non-secure before we did? (This sounds like the current rationale for > >> exceptions, I think). > >> > >> Or are we saying we would ship a feature by default as secure and be > willing > >> (compelled?) to move to non-secure if we discover sites rely on other > >> significant market share browsers not requiring a secure context for > said > >> feature -- once our users reported the bugs (or we did some kind of > analysis > >> beforehand)? > > > > I'm saying that we've been doing what you describe in the first > > paragraph but maybe we need to shift to what you describe in the > > second paragraph in order for the policy on secure contexts to be > > effective. > > Shipping a Gecko-first feature limited to secure contexts, when we don't > have evidence that other browsers will follow suite, runs the risk of > sites breaking only in Gecko once the feature is widely deployed. > Although we can always change the configuration after breakage is > observed, the time taken to receive a bug report, diagnose the issue, > and ship the fix to users, can be significant. This is a window during > which we're likely to lose users due to the — avoidable — compatibility > problems. > > I would argue that in the case where: > > * There is no compelling security or privacy reason for limiting a > feature to secure contexts > > * There is reason to suspect that other browsers will ship a feature in > both secure and insecure contexts (e.g. because limiting to secure > contexts would be significant extra work in their engine, or because > their past behaviour suggests that the feature will available everywhere) > > the trade-off between nudging authors toward https usage, and avoiding > web-compat hazards should fall on the side of minimising the > compatibility risk, and so we should ship such features without limiting > to secure contexts. > > Alternatively we could have a policy that allows us to initially ship > Gecko-first features meeting the above criteria as secure-context only, > but that requires us to remove the limit if other browsers start > shipping to their development channels without a secure-context limit. > That minimises the compatibility risk — assuming we follow through on > the process — but adds extra bureaucracy and has more steps to go wrong. > I doubt the incremental effect on https adoption of this policy variant > is worth the additional complexity, and suggest we should use this > approach only if we misjudge the intentions of other vendors. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
