info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Intent To Ship: backdrop-filter
1,511 views
Skip to first unread message
L. David Baron
Jun 9, 2020, 6:01:23 PM6/9/20
to Erik Nordin, dev-pl...@lists.mozilla.org
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)
> 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)
Martin Thomson
Jun 9, 2020, 9:18:15 PM6/9/20
to L. David Baron, Erik Nordin, dev-platform
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
> 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).
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?
Sean Voisen
Jun 12, 2020, 12:51:27 PM6/12/20
to Martin Thomson, L. David Baron, dev-platform, Erik Nordin, Andrew Overholt
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
>
address the various questions and concerns below:
To that end, is there a plan for making this capability uniformly available?
>
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*.)
>
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.
>
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.
>
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
>
Bobby Holley
Jun 12, 2020, 1:05:22 PM6/12/20
to Sean Voisen, Martin Thomson, Andrew Overholt, L. David Baron, dev-platform, Erik Nordin
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.
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.
eno...@mozilla.com
Jun 17, 2020, 7:24:20 PM6/17/20
to
https://wiki.mozilla.org/Platform/Channel-specific_build_defines
Chi Hiremath
Sep 1, 2021, 10:42:39 AM9/1/21
to
Erik Nordin
Sep 1, 2021, 7:06:57 PM9/1/21
to
Despare int
Jun 5, 2022, 3:09:26 PM6/5/22
to
The polyfills aren't that useful to achieve the same effect.
Sebastian Zartner
Jun 6, 2022, 5:38:07 PM6/6/22
to
On Sunday, June 5, 2022 at 9:09:26 PM UTC+2, Despare int wrote:
> It's mid 2022, when are we finally expecting this to be enabled by default? Chromium supports it by default since 76+
> The polyfills aren't that useful to achieve the same effect.
I expect that will happen soon. At least there are only a few issues left blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1578503 and they are actively being worked on.
> It's mid 2022, when are we finally expecting this to be enabled by default? Chromium supports it by default since 76+
> The polyfills aren't that useful to achieve the same effect.
Having said that, I am not a Mozilla employee and also just following the implementation. So some official statement would definitely be appreciated.
Sebastian
0 new messages