It is usually possible to progressively enhance your websites with support for new features.
My strongest pet peeve is “this is impressive but what browsers support this?” comments. Why can’t ppl just enjoy smth & then be optimistic about making a change / pushing features to implementation instead of being giver-uppers like that. It’s depressing.
I replied to this, but don't think I was particularly clear. I'm with Sarah, and many people who help with the development and popularisation of new CSS features: rapid adoption of these things is critical because of the way browser vendors and the CSS Working Group measure if their new CSS tech is worth further development: they measure use in the wild. If it's not used, it's unlikely to be developed further.
So yes, it is important, and it is usually possible to progressively enhance your websites with support for new features, leaving something that isn't a broken mess for those who can't see the new features.
In an ideal world, that's all that matters, and you go do that. I try and do that wherever possible too.
So why the apparent disillusion?
For most web developers, it's about working within a fixed budget and spending time and money where the most value for the clients money is.
Because we don't all operate in the same constraints what seems reasonable to one group is not reasonable to another.
The crux of the matter, when you're doing work for clients, is that implementing CSS features has a monetary cost either for the client or for you the developer. And with partially-supported CSS features, only a limited sub-set of the website's audience will experience any benefit. There is no getting around the fact that additional time must be spent in learning what the new feature is, how it can be used, then how you should use it, and then in implementation. This all takes time, and either you bill the client extra for that extra time, or you take a hit on your rates because you're spending additional time on the job but not charging for that time.
For some stuff, this is utterly trivial. There's little impact in deciding to use calc in your stylesheets to help deal with tidying up some stuff, for example. But that dynamic changes when the time to implement and visual impact scales go up.
Every client I've ever worked with in the last 15 or so years has a finite budget, and if I as a developer say there are 10hrs left in their budget, and I can either:
- Make the layout look extra spiffy with CSS Grid for 50% of your visitors OR
- Build a neat dynamic form UI everyone can see - which you don't need, but would be more swishy for everyone
Guess which one matters to the client more? Especially when I have to explain to my client how they can explain to their board of directors that, no, I can not make the site look as nice on their office PCs running the corporate mandated IE11 as it does on their home iMacs because it's not technically possible. The board of directors just want a website that looks like the visual they saw a month ago, which was the last time they checked in on the state of the project with the person they put in charge of it.
And that's why so many developers say: "New CSS is nice, but I'm not using it until the majority of users can benefit from it".
It's not about theoretical ideals, it's not about the practicality of progressive enhancement as a technique; it's about working within a fixed budget and spending time and money where the most value is. That's rarely the new shiny stuff only a limited subset of visitors can benefit from.
Can the new shiny be faster to develop with? I'd contend that once you know all the caveats of the technique, maybe. But likely not, because you still have to do all the work you would have done without it, for all those people who can't see it.
Why is this frustrating for everyone?
No-one wins when the barometer for future CSS development is based on the adoption rate of cutting-edge CSS techniques.
Because both the spec developers, the browser developers, and the web developers all want to see the new shiny succeed, and not implementing the new shiny early on stops that from happening.
Because the Working Group and the browser vendors rely on real world use as an indicator of success, it becomes an almost impossible catch 22. Most web developers I know can't be persuaded to risk using partially supported features unless their particular project has an unusually large well of money to put into it, and the WG and browser vendors feel it's foolish to spend their time nursing new technologies that they can't be sure people will use and see little evidence of uptake.
Neither the web developer nor the WG/Browser vendors are being irresponsible here - in fact they're both doing the right thing as far as their respective employers are concerned, by attempting to spend that budget wisely. But put the two together and it's not a good way to get progress for either group.
That's frustrating.
The misery of expectations
In this dynamic, the only way to score a "win" for the client, and a "win" for the future development of CSS, is for the developer to suck it up and bare the cost of these new features. The actual monetary and time cost of them.
It's possible you may think that developers should learn this stuff in their free time - but this comes very close to the work-work-work mentality that leads to burn out among so many of us. It's an expectation that to advance in any way, that advancement must be done in your free time. That's a dangerous attitude and one I whole-heartedly fight against. Too many people have crashed and burned because well-meaning groups place unrealistic expectation on developers. And just as many have crashed and burned from the same "you should live and breath this life or GTFO" attitude by people who aren't well meaning.
And that's why many developers don't feel like using the new fancy until it's supported almost everywhere.