Web-Facing Change PSA: Update CSS backdrop-filter to use mirror edgeMode
Robert Flack
Contact emails
fla...@chromium.org, michae...@google.comSpecification
https://drafts.fxtf.org/filter-effects-2/#backdrop-filter-operationSummary
The backdrop-filter CSS property applies one or more filters to the "backdrop" of an element. The "backdrop" basically means all of the painted content that lies behind the element. A common filter is a blur allowing designers to construct "frosted glass" dialog boxes, video overlays, translucent navigation headers, and more. This was initially implemented the same way as a regular blur, but sampling beyond the edges of the element allowed colors from the edges to bleed in. The spec was changed to sample pixels outside the backdrop edges by duplicating the pixels at the edge. This however, results in extreme flickering of content as it enters the backdrop edge. The latest spec change mirrors the backdrop when sampling beyond the edge which allows for a smooth gradual introduction of new colors at the edges without overweighting on single lines of color.
Blink component
Blink>CSSTAG review
NoneTAG review status
Not applicableRisks
Interoperability and Compatibility
The specific visual result of a blur backdrop-filter is currently quite different between Chrome, Firefox and Safari, as such this developers could not rely on any interoperable behavior today. This change visually aligns closely to Safari's filter - if not identical, so should bring those two in rough alignment. We agreed upon this new behavior in the CSSWG resolutions for the new edgeMode[1] and using this edgeMode for backdrop-filter[2]. [1] https://github.com/w3c/fxtf-drafts/issues/527 [2] https://github.com/w3c/fxtf-drafts/issues/374
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1051)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/372) This change is visually very similar to the blur being applied in Safari which doesn't have the flickering issues that our current duplicate edgeMode has.
Web developers: No signals There have been many negative signals about the current duplicate behavior that this change resolves (all duplicated into the main bug): https://issues.chromium.org/issues/40040614 There is positive sentiment for Safari's behavior on https://issues.chromium.org/issues/40666159 and https://issues.chromium.org/issues/40040614 which this change in behavior aligns with.
Other signals:
Ergonomics
There are no known ergonomic risks.
Activation
This should be an improvement to the quality of blur backdrop-filters that developers are already using and further allow developers to adopt them without worrying about the flickering edge cases of the duplicate filter. Developers don't need to do anything other than use the backdrop-filter property.
Security
There are no known security risks. This is replacing one sampling algorithm with another.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
As a change to the visual blur, there is no specific debugging support.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
YesFlag name on chrome://flags
chrome://flags/#backdrop-filter-mirror-edgeFinch feature name
BackdropFilterMirrorEdgeModeRequires code in //chrome?
FalseTracking bug
https://issues.chromium.org/u/1/issues/40040614Estimated milestones
| Shipping on desktop | 129 |
| DevTrial on desktop | 127 |
| Shipping on Android | 129 |
| DevTrial on Android | 127 |
| Shipping on WebView | 129 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
None