What are the factors you consider when deciding whether or not to use a modern CSS/JS feature?
Like, suppose the browser support is 95% according to caniuse. How do you decide if that’s good enough or not?
Like, suppose the browser support is 95% according to caniuse. How do you decide if that’s good enough or not?
Comments
If my audience is tech, let the bleeding edge rip. 😂
But that site is more for developers, similar to yours.
Work I got to support pre flexbox gap.
Is the feature central to your app’s function?
Who is your target audience, and what devices/browsers do they use?
How critical is accessibility, and does the feature enhance or hinder it?
Are there suitable fallbacks or polyfills?
After we sunsetted IE11, we drew the line at Safari N-2, but some restaurants complained about having issues with iPhones.
After carefully reviewing stats, we moved to N-3, that is Safari 15 today, and that has been our sweet spot for a while.
If it is a personal project I usually don't pay much attention to it, but if said project gets used by others and they require a feature to work on their browser, then I would try and make it work for them.
IE, Opera mini, and other small ones I don't care about for any of my projects
But for some high value features I make an exception. The EyeDropper API is a good example, so much value for so little effort.
I still use both, but a feature can be 80% or 98%, I'm still considering critical path first and foremost.
Eg, I would avoid &&= and ||= even though they are well supported, because few devs use them.
Is the new feature worth the extra cognitive load for the next guy?
< 95%: use it but with fallback
< 98%: use it, but don't implement fallback if it is hard or expensive
<= 100%: don't bother with fallback
when i first integrated grid, i had both a flex, float/div or table fallback.
now, i just have a flex fallback. even now they are only 1% off of global usage. i also pay attention to market location which is higher
p much why :has() went straight into the game (production work) but @layer is still not training with main squad yet, for example.
I think that’s more useful to people fighting the browser.
Here’s a quick Codepen to demo how something could look depending on support.
https://codepen.io/sturobson/pen/VwdENNx/d9009ca412a392e499d3d005ab05ef66
https://bsky.app/profile/sturobson.com/post/3lbpke4y6cs2y
2. Is it widely supported accordingly to Baseline?
3. Audience of a project.
Baseline made my life a lot easier. I rarely look at the caniuse nowadays.
2. Is it scalable or reusable across the site, or is it just a one-off? (Not necessarily an immediate no but a good question)
3. Is it accessible?
4. Has it been used in enough visible cases that side effects or bugs are already known?
If using the modern API is affecting less than the threshold, then I just go for it.
accurate, but still rude.
I still got burned with a client that had an older version of MacOS
2. Was doing it the previous way genuinely too difficult?
3. Does the new syntax help or hurt with readability, or makes things less explicit?
The first one is obvious. If I gotta support something like IE, then cya!
Lastly, if it hurts readability or obfuscates behavior in some fundamental way, I'll avoid it...
However in B2B you might have some say over what browser your users should use for your product.
For internal stuff I use whatever is available in the latest version of Chrome.
The audience are audio pros and plenty of studios are still running old cheese grater Mac Pros with old versions of macOS.
At my job, we need to support old browsers so I will only use a new feature if the website works without it or I can provide a fallback.
For side projects, I just use it 😅
Backend engineer problems >.>