Would be nice to ship it unprefixed.
There are some WPT that could imported in css/filter-effects.
Do we know what blocks it being unprefixed?
The main issue of contention was https://github.com/w3c/fxtf-drafts/issues/53
Is this (https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-500010730) comment from Tab still the current status:
> Yeah, the core idea is that unless/until WK actually describes their behavior, which they were tasked with doing at the last meeting, we're going with the current spec (Chrome) behavior. And if they don't do that reasonably quickly, Firefox will likely follow the spec, and begin fully locking in that behavior.
So the status quo is this bug (unprefixing the property) is blocked on a task to spec our behaviour?
Mozilla is re-enabling backdrop-filter in Firefox Nightly
Firefox 103 shipped backdrop-filter last month:
Created attachment 461954 [details]
issue 53 - rendering in Safari, firefox, chrome
> There are some WPT that could imported in css/filter-effects.
Currently there are a number of backdrop-filter tests which are failing in Safari TP 152
A number of them would pass if backdrop-filter was unprefixed.
They seem to be imported already
and most of them marked as FAIL.
In Comment #5, the ship has sailed.
> So the status quo is this bug (unprefixing the property) is blocked on a task to spec our behaviour?
Both Chrome and Firefox are shipping the property unprefixed.
The current spec is https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty
One of the issues which was given is illustrated in
See the screenshot issue 53 - rendering in Safari, firefox, chrome
Only WebKit behaves differently.
What would be good to understand is how many tests are failing/passing when unprefixing with the current implementation which depends on Core Animation.
The last comment on the issue 53 was made on Dec 23, 2019 (almost 3 years ago).
I wonder if Dean or Myles have an opinion on the path forward here.