I know, I'm shocked as well!

Totally agree.

I'm not aware that it's a thing that has ever actually happened (though admittedly it would be hard to know if it did). But it's definitely something people are concerned could happen.

Here's one example (and I've heard others express similar concerns): bsky.app/profile/zach...

But IMO anyone who understands how to use progressive enhancement is likely not going to be confused or dissuaded by Baseline labels.

The primary audience for Baseline labels are people that *don't* fully understand progressive enhancement and aren't actively looking to try out new features.

The specific concern I've heard is that adding Baseline labels to blog posts and reference documentation will scare people off from using "limited availability" features, even if those features can easily be used as progressive enhancements now...

If you want to find out what Baseline target makes the most sense for your site, there are a number of tools to help you determine that: bsky.app/profile/deve...

And if you work at a company that doesn't have a browser support policy, talk to them about Baseline! #WhatsMyBaseline

Using Baseline 2023 as my browser support target means I can safely adopt TONS of great features, including:

- :has()
- Container Queries
- CSS Nesting
- linear() easing

Any many more: webstatus.dev?q=baseline_d...

I believe this will lead to FASTER feature adoption on the web, not slower.

I also bet there are many features you can safely use now that you may not realize. For example, on my personal website, 98.2% of my users are on browsers that support all of Baseline 2023.

Here's what my data looks like:

BUT, if your company has a browser support policy, the decision is simple.

This is why I'm excited about Baseline.

Baseline makes it easier for companies to decide on a browser support policy. And with Baseline data now exposed in so many tools and resources, devs can easily follow that policy.

In this situation, most devs will give up. Or worse, many won't even try at all because they don't want the hassle.

I've seen this play out many times, even with features that have been available for 5+ YEARS!

Unfortunately, if a feature is not already in the codebase, it will face resistance.

Even if you convince your immediate teammates, is that enough? Do you need sign-off from a manager? Your CTO? Who is the final decision maker?

And what if your code breaks a customer, will it get reverted and then you'll just end up having to rewrite it anyway?

Here's the scenario:

You get assigned a ticket, research a solution, and find a new Web API that does exactly what you need. But in the PR your teammates ask:

- Are you sure we can use this?
- Did you check browser support?
- Is this used anywhere else?

Now you’re on the hook to justify it.

In my experience, one of the main reasons devs don't use new web features is NOT lack of browser support, it's because their company doesn't have a clear browser support policy.

Without a clear policy, the path of least resistance is to just NOT adopt any new features, even widely available ones.

TBH my significant other is questionable at times. When we first met she told me she likes hiking. Later she clarified that she "likes hiking, just not up hill".