You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Replace light-dark @mixin with native light-dark image support #1865
We should therefore be able to replace our uses of @mixin light-dark with native light-dark(), and remove the postcss plugin, and stylelint overrides (e.g. #1861)
However, currently the postcss-light-dark plugin adds a @supports (color: light-dark(red, red)) block which would expose light-dark(<image>, <image>) on browsers which don't support it.
Setting preserve: false on this plugin will allow us to make the switch now, until postcss-light-dark detects image support and uses an appropriate @support block.
We also need to force the postcss-light-dark plugin on, until upstream supports light-dark(<image>, <image>), otherwise it'll stop transpiling once light-dark(<colour>, <colour>) is Widely Available (and we drop support for Firefox 115).
I don't know if MDN considers CSS support for all currently supported browsers important but if so and if it's treated as supported (as it's technically still a supported browser on certain platforms) Firefox 115 ESR does not support this CSS rule and is the last officially supported Firefox version of Windows 7-8.1 and macOS 10.12-10.14 until at least March 2027.
@danielhjacobs yes, 115 is pinned in our browserslist so tools like postcss automatically transpile our CSS into a version compatible with it. We also target Baseline Widely Available, and even the normal light-dark() is still only Baseline Newly Available.
Ensuring compatibility with older versions is exactly what this paragraph is about:
However, currently the postcss-light-dark plugin adds a @supports (color: light-dark(red, red)) block which would expose light-dark(<image>, <image>) on browsers which don't support it.
And this ensures that in the meantime we always just use the transpiled result, with no @supports blocks:
Setting preserve: false on this plugin will allow us to make the switch now, until postcss-light-dark detects image support and uses an appropriate @support block.
But you've made me realise a good point: once light-dark() without images is Widely Available (and we drop support for 115), we'd stop transpiling all light-dark() uses, even image ones, if upstream hasn't updated to support them yet, so we need to force the rule on too.
Activity
danielhjacobs commentedon Sep 8, 2026
I don't know if MDN considers CSS support for all currently supported browsers important but if so and if it's treated as supported (as it's technically still a supported browser on certain platforms) Firefox 115 ESR does not support this CSS rule and is the last officially supported Firefox version of Windows 7-8.1 and macOS 10.12-10.14 until at least March 2027.
danielhjacobs commentedon Sep 8, 2026
https://support.mozilla.org/en-US/kb/firefox-users-windows-7-8-and-81-moving-extended-support
https://support.mozilla.org/en-US/kb/firefox-users-macos-1012-1013-1014-moving-to-extended-support
LeoMcA commentedon Sep 8, 2026
@danielhjacobs yes, 115 is pinned in our
browserslistso tools likepostcssautomatically transpile our CSS into a version compatible with it. We also target Baseline Widely Available, and even the normallight-dark()is still only Baseline Newly Available.Ensuring compatibility with older versions is exactly what this paragraph is about:
And this ensures that in the meantime we always just use the transpiled result, with no
@supportsblocks:But you've made me realise a good point: once
light-dark()without images is Widely Available (and we drop support for 115), we'd stop transpiling alllight-dark()uses, even image ones, if upstream hasn't updated to support them yet, so we need to force the rule on too.