One other note: I don't think we should be too concerned about the specific multiple-graphics-backends situation arising frequently in the future. The goal is to have a single backend (WebRender) going forward, and last I checked the plan was to completely drop all other backends within the next 12 months.
Gating this particular feature on Nightly and Early Beta for now seems like a reasonable compromise. On Fri, Jun 12, 2020 at 9:51 AM Sean Voisen <svoi...@mozilla.com> wrote: > Thanks David and Martin for the feedback on this proposal. I'll try to > address the various questions and concerns below: > > To that end, is there a plan for making this capability uniformly > available? > > > > We don't have any plans to implement backdrop-filter on other graphics > backends. This property has been sitting behind a pref while we have waited > for a larger WebRender rollout. It may be worth noting that WebRender is > now at 73.9% of Nightly and 85% of Windows 10 on Nightly. > > When we last investigated, the effort to support this feature on the other > backends was significant. Generally, I don't believe we should be devoting > engineering time to supporting new CSS features on the legacy backends > unless the cost is low. In addition to the initial development, we have to > concern ourselves with the maintenance cost until these backends are fully > deprecated. > > It's worth calling out here that shipping platform features for only some > > of our graphics backends is something new for us. (It's possible we've > > done it in the past, but I'm not aware of us doing it *intentionally*.) > > > > This is new, and we should evaluate it on a case-by-case basis. I don't > think shipping backdrop-filter this way should set precedent for other new > CSS features. Because it's primarily for cosmetic enhancement, and not > generally used in a way where lack of support breaks the functionality or > layout of a site, the nature of backdrop-filter lends itself better to > shipping to a subset of users. A counter-example might be conic-gradient, > which might be used for some critical part of site UI, such as a color > picker. I don't think we should ship something like this to a subset of > users. > > We risk creating Web compatibility problems for our own users. While > > shipping the feature to some of our users will probably reduce web > > compatibility problems for that subset of users, it will also probably > > *increase* Web compatibility problems for the remaining users, since many > > developers who *do* care about testing on Firefox may produce content > > that's broken for those users. > > > > Usage across the web is still relatively low, but it is growing. (Chrome > stats [1] show 1.83% usage, but it's hard to know how much of that is > meaningful in a way that sites look broken without the feature.) Non-WR > users won't see anything different on sites that use backdrop-filter than > they do now. Content that uses backdrop-filter now is already "broken" for > all our users in that respect. The biggest compat risk likely stems from > sites that place text on a blurred background image, which may render the > text less readable without the effect, and again is already what all > Firefox users see. I suppose it's a question of how much this risk will > increase until we have WR everywhere. > > It makes the idea of targeting and testing on Firefox more complicated for > > Web developers. We're at risk of being ignored by Web developers; being > a > > more complicated and fragmented target increases that risk, especially > for > > the smaller fragment(s), and also makes Web developers dislike us for > > creating more complexity for them. > > > > This is a risk I'm concerned about. It may be upsetting for developers who > test in Firefox on a WR-supported machine and incorrectly assumes that > backdrop-filter will look the same for all users. It's unlikely that they > will create a "broken" experience for users, but the site will look > different. We can and do plan to mitigate this through blog posts and > outreach (use @supports), but the risk will still be there. > > One path forward is to gate this feature in Nightly and early beta to > collect more feedback and data on our implementation. I'd prefer this > slower rollout to none at all. As of now the pref is off for everyone. > > Cheers, > Sean > > [1] https://www.chromestatus.com/metrics/css/timeline/popularity/508 > > On Tue, Jun 9, 2020 at 6:18 PM Martin Thomson <m...@mozilla.com> wrote: > > > On Wed, Jun 10, 2020 at 8:01 AM L. David Baron <dba...@dbaron.org> > wrote: > > > It's also something that I think we shouldn't be doing, at least not > > > without a clear and relatively short timeline for having the feature > > > available across all graphics backends (whether by implementing it > > > for more backends or by no longer shipping those backends). > > > > I agree with David's reasoning here about this being potentially > > harmful, but I do recognize the value of prototyping or experimenting. > > This doesn't seem to be either of those though. > > > > To that end, is there a plan for making this capability uniformly > > available? > > _______________________________________________ > > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
