Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-webkit- prefix removed from backdrop-filter even though Safari needs it #537

Closed
schuetzm opened this issue Jul 10, 2023 · 5 comments
Closed

Comments

@schuetzm
Copy link

schuetzm commented Jul 10, 2023

Safari doesn't support unprefixed backdrop-filter:
https://caniuse.com/css-backdrop-filter

Unfortunately, LightningCSS removes the necessary -webkit- prefix when both the prefixed and the normal version are used:
Playground

Funnily enough, if there's only an unprefixed backdrop-filter, it outputs both the prefixed and the unprefixed version:
Playground

I would expect both inputs to result in the same output including both the prefixed and unprefixed declaration.

@christianmartinnies
Copy link

I observe the exact opposite behaviour as it is added twice after a build.

Source:

dialog::backdrop {
  opacity: 1;
  backdrop-filter: blur(0.125rem);
}

Build:

dialog::backdrop {
  opacity: 1;
  -webkit-backdrop-filter: blur(0.125rem);
  -webkit-backdrop-filter: blur(0.125rem);
  backdrop-filter: blur(0.125rem);
}

@LeoniePhiline
Copy link
Contributor

LeoniePhiline commented Jul 26, 2023

Previously duplicated -webkit-backdrop-filter rules now completely removed: Regression in lightningcss 1.21.0 (diff)

All results produced with pnpm exec lightningcss --targets 'defaults' input.css -o output.css after pnpm i -D lightningcss@1.20.0 / pnpm i -D lightningcss@1.21.0.

The following duplicates -webkit-backdrop-filter rules (minor inconvenience) with lightningcss 1.20.1 and completely removes -webkit-backdrop-filter rules (breaking Safari compatibility) with lightningcss 1.21.0:

Source

Side note: This source is parcel output. Parcel, invoked with --no-optimize added the autoprefixed line.
This parcel output is now sent through lightningcss-cli to simulate use of @parcel/optimizer-css.

.cc-bottom {
  -webkit-backdrop-filter: saturate(250%) blur(8px);
  backdrop-filter: saturate(250%) blur(8px);
}

Good result in lightningcss 1.20.0 and below

The duplicated -webkit-backdrop-filter line is a nuissance, but does not break anything.
#403 reports this duplication.

.cc-bottom {
  -webkit-backdrop-filter: saturate(250%) blur(8px);
  -webkit-backdrop-filter: saturate(250%) blur(8px);
  backdrop-filter: saturate(250%) blur(8px);
}

Bad result in lightningcss 1.21.0+ (diff)

The missing -webkit-backdrop-filter line breaks Safari compatibility.
#537 reports the incorrectly removed prefixed lines.

.cc-bottom {
  backdrop-filter: saturate(250%) blur(8px);
}

Missing tests

Added failing test: https://github.com/parcel-bundler/lightningcss/pull/553/files#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R12798-R12816

Initial analysis

Auto-generated src/prefixes.rs is correct, with 589824 indicating "Safari 9.0.0 and higher", and no upper bound:

https://github.com/parcel-bundler/lightningcss/blob/master/src/prefixes.rs#L557-L562

@jur-ng
Copy link

jur-ng commented Oct 26, 2023

On the latest version (1.22.0) I now see the following behavior:

source:

.toast {  
     backdrop-filter: blur(30px) !important;
    -webkit-backdrop-filter: blur(30px) !important;
}

result:

.d7fzDW_toast {
  -webkit-backdrop-filter: blur(30px) !important;
}

And source:

.toast {  
     backdrop-filter: blur(30px) !important;
}

result:

.d7fzDW_toast {
    backdrop-filter: blur(30px) !important;
}

So basically the non-prefixed version is removed when I also include the -webkit prefixed one, and the webkit prefixed one is not autimatically added when I have just the non-prefixed one :/

EDIT As a workaround I now downgraded to 1.20.0 as having two -webkit-backdrop-filters is better than having one or having it remove the normal backdrop-filter. Could you maybe look into this though @LeoniePhiline ?

EDIT2 It does not happen in the playground so I guess this might have something to do with my default Vite config? I only enabled CSS modules.

EDIT3 Nope it definitely seems like a bug when no target is specified, you can check the difference in this playground between 1.22.0 and 1.20.0

@brycewray
Copy link

FWIW, observing the same with filter vs. -webkit-filter and have also tested in the playground to which @jur-ng linked above.

@LeoniePhiline
Copy link
Contributor

@brycewray This issue is closed. Try opening a new one, with a repro project and/or link to a repro in the playground.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants