On Tuesday, June 9, 2020 at 3:01:23 PM UTC-7, L. David Baron wrote: > On Friday 2020-05-29 12:50 -0700, Erik Nordin wrote: > > Intent: > > > > As of Nightly 79 (shipping in release 7/28) I intend to turn > > backdrop-filter on by default for all systems on which WebRender is enabled. > > > > Here is a list of systems and their current status with regard to shipping > > WebRender: > > > > https://wiki.mozilla.org/Platform/GFX/WebRender_Where > ... > > More Information: > > > > The backdrop-filter pref will be set to true on all systems, but > > backdrop-filter’s functionality will not be available unless WebRender is > > also enabled and available. > > > > Developers can check for backdrop-filter’s availability via CSS.supports() > > or @supports. Developers can still explicitly turn off backdrop-filter by > > disabling its pref in about:config. > > > > If WebRender were to crash and become unavailable, backdrop-filter will > > also become unavailable. Subsequent calls to CSS.supports() will reflect > > this change, as will subsequent parses of CSS StyleSheets that use @supports > > rules. > > > > Note, however, that any backdrop-filter-related information that was > > collected prior to this event may now be incorrect until the page is > > refreshed. > > 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*.) > > 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 think it's bad for the following reasons: > > 1. 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. > > 2. 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. > > (I'd note that I've expressed this concern to Erik, Sean, and others > in the past, but also encouraged them to send this intent because I > think this should be a broader discussion.) > > -David > > -- > 𝄞 L. David Baron https://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)
Thank you all for the feedback and clarifications. Based on Bobby's suggestion, I think that it would be reasonable to move forward using the EARLY_BETA_OR_EARLIER option, described here: https://wiki.mozilla.org/Platform/Channel-specific_build_defines _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
