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
> _______________________________________________
> dev-platform mailing list
>
dev-pl...@lists.mozilla.org
>
https://lists.mozilla.org/listinfo/dev-platform
>