Open JayPanoz opened 8 months ago
Unlike minification, I think it is sensible for upstream ReadiumCSS to vendorise and configure browser targets (i.e. not expect ReadiumCSS consumer to do it themselves). That being said, I'll put this here just in case: https://github.com/parcel-bundler/lightningcss
Browserslist configuration – Lightning CSS supports opt-in browserslist configuration discovery to resolve browser targets and integrate with your existing tools and config setup.
It looks fine for the Kotlin toolkit, however the Swift toolkit still supports down to iOS 10 (soon iOS 13). It looks like this API is not fully supported before iOS 14?
@mickael-menu Yeah I’m not particularly a fan of it anyway and will roll back this specific dependency to see what happens. It’s use doesn’t bring any benefit whatsoever as we did not design ReadiumCSS to use it anyway. As a backup, there’s maybe browserlist I can add to PostCSS config.
Not that I don’t want to change tooling but the use of PostCSS was quite minimal, and solely for design/authoring purposes i.e. making ReadiumCSS more customisable by developers.
I'm submitting a question.
Short description of the issue/suggestion:
Having upgraded dev dependencies without too many issues locally – actually it went even surprisingly smoothly – I became aware the target has moved for some PostCSS plugins.
The most noteworthy difference in transpired CSS being the use of the
:is
pseudo class through pluginpostcss-custom-selectors
:So, basically, the
:is
pseudo class is widely available across major browsers from January 2021 (Chromium-based browsers).Thanks to the push to evergreen browsers in the last couple of years, support should be less of an issue in 2024 but I wanted to make sure that would not break ReadiumCSS for anyone out there.
It would be of great help to mention any special need and/or if that would be no issue.