[question] Targeted browser-support & postcss-config

[benbender]

Hey,

as I'm considering using open-props in a project, I would like to ask:

• if there is a kind of targeted browser-baseline or something? I couldn't find and am unsure what kind of testing was done already and what is targeted here. Btw, maybe it would be helpful to add a browserslist-config to help with this kind of questions...

• I noticed that several postcss-plugins were disabled and I would like to ask why this was done? Especially if a project consumes the compiled css I would assume this might hurt browser-support?

Thanks in advance!

[WebMechanic]

agree. I believe browser baseline is simply: latest :-) but a list would be nice and some changelog of what happend between npm releases.

For the "new hot stuff" it'd help to have notes what browser actually support the thing today (and not constantly check caniuse) and maybe what PostCSS plugin would need to be enabled to make it work elsewhere. The disconnect of plugin package name and plugin id for the config makes finding the right one a bit tedious.

I found some things not working in SF13 (which I have to support), one of which is :where, or even in latest FF that need some PostCSS love or other workarounds. I also changed the list of PostCSS plugins to transpile for our browser demographics and make use of named media queries etc, which I believe is what one has to do anyway.

[benbender]

I'm in a kind of similar situation and would also love to see some clear definition of browser-support and - ideally - documented steps needed to improve support. Doesn't seem to make sense if anyone is doing research and fixing on its own... ;)

[argyleink]

browser support: Short quick answer, no IE because it's custom properties. More complex answer is caniuse :where(), which wraps the prop definitions, which is a more modern browser feature. if you need to target browsers before :where(), it's possible to get a build without the wrapping selector.

things get more complicated if you use the normalize stylesheet, as it's very modern and definitely in the bucket of "latest browsers". if you're just using the props, browser support isnt complex

postcss plugins: i turn many of them off in preset-env because they polyfill features much further back than :where or custom properties, essentially bloating the stylesheet/library with fallbacks that are highly unlikely to be needed / used. in user land, where you folks are importing open props, you have your own browserlists and plugins which target your own endeavors, those build passes can do your own controlled set of feature support. i feel it's best if the lib delivers a slim file and lets consuming authors choose what to polyfill, as i can't predict all of it.

overall, things are tested in latest browsers and this library in general is a modern css targeting library. custom properties are a clear dividing line for browser support, and :where() is just sugar to make it easy to overwrite/extend the props.

thanks for logging the issue, i'll start thinking of where I can add some of these notes for folks 👍🏻

[WebMechanic]

imho the normalize stylesheet is (visually) way too opinionated for any of my use cases, and that's fine. The color scheme's been settled anyway. I like that I can cherry pick what I need and what seems useful, i.e. the color ramps are not, timing functions and custom media sizes are, but the latter requires a specific postcss plugin and it'd be nice to learn in advance which one would do the job. A simple list of required and recommended plugins would help a lot -- and a changelog.

I hope purgecss, preset-env plugins and the JIT plugin will help to eventually keep the amount of unused vars to a minimum if not eliminate them from the final production build(s).

---

What I don't like in general (in any framework-ish packages) is having to literally override a buttload of things w/o an easy way to get rid of the stuff I am effectively replacing. Any framework is somewhat opinionated even those that claim not to be, which is why I don't use any, never hav in +25yrs. That's my first.

No IE support is good and was a selling point to pick this project. It implies no code bloat the rest has to consume only to instantly drop it. It sucks that we have to support SF13 mobile. It's our current IE.