If your business plan requires you to capitalize on more than 98% of the market, it's already a failure. It'll never happen.

As always, it's an "it depends" situation. If your userbase is largely luddites, then maybe you need to support 10+ year old browsers that can't be updated. Otherwise, you can probably just worry about people who are using computers new enough to actually update their browser once a year or better.

The tradeoff is code complexity and engineering time, vs having a larger market. And that's going to be an individual situation for every company.

I tried to purchase tickets for an event last week. I had to go through Ticketmaster as it was the only official way. They forced me to verify my account using a phone number, but whoever they were using for messages wasn't able to deliver a code to my number. I tried a few numbers from our household and they all failed.

Searching for this issue yielded a bunch of results, so it was definitely a known issue, but there wasn't anything I could do, really. To them, it's simple math. Another SMS provider that covers my (tiny EU) country might be more expensive. They might be avoiding scammers that used my mobile operator in the past. Whatever it is, it would probably cost them more than they lose in ticket sales.

Without some government entity to force them, they don't give a shit about me being able to see an event.

Of course, you do not know this exactly, but the point is that it's easy to look at the wrong statistic and come to conclusions that are not necessarily useful in some context. The lens matters just as much as the percentage, if not more.

CSS on a website, however, you CAN get partial credit (to an extent). It may not be perfect, but it's at least theoretically still providing some value partially.

I think knowing what kind of problem you're facing is really important when it comes to measuring percentage of "complete".

It may sound like a small deal to not carry one brand of chocolate paste but if some customers then also don't buy the 12 other groceries they need at your shop, it doesn't really matter that it's only 2% of products that were discontinued. Supermarket products are so stable not because nobody ever makes anything new but because changing a small percentage frustrates customers

If I can't order from some website, I stop trying. Maybe next week the ESR browser gets an update and it works again but by then I'm not clicking those links in the search results

If I'm one of the 2% then that's everything for me. Maybe I have good reasons to be in the 2%. And maybe, not caring about that is wrong.

I would rather have a website that only works for 2% of people for the right reason, than a website that doesn't work for 2% for the wrong reason.

I mentioned 3 years ago that Firefox at 2.2% is dangerously close the being unsupported on government websites, and at this point it's now at 1.9%.

https://news.ycombinator.com/item?id=36776603

https://analytics.usa.gov/ says "There were 1.66 billion sessions in the last 30 days." - so 2% is 33 million sessions if I did my math right.

I assume Firefox users over proportionally use privacy extensions.Thus they overproportionally won't appear on Google Analytics and similar places, which for some statistics reduces the numbers even more than reality.

"What, do you not live your life based on 99th percentiles?"

I tend to think of work as upside-based on downside-based. Most feature work is upside. 10% lift on conversions is great, 40% adoption is winning, and you're playing for the moonshot of 10x. Infra work is downside-based. 98% secure, 98% available, 98% acceptable performance -- that'll all failure. Winning means the thing works as expected and nobody notices.

Not everything sorts cleanly into upside vs. downside, but a lot does. Allocate your risk accordingly.

Arguably, if you only have a website, that won't work for anyone without access to the Internet. So then you should have a physical presence in each of those people's location, and arguably you shouldn't provide any improvements that give me more than physical presence does, so you should not have the website in the first place, since people without the Internet can't use it or you have to keep your website without any improvements over the physical office.

If you only have a website, arguably 2+ billion people currently wouldn't be able to access it.

And it seems odd to bring 150 mil people as an example, when the baseline should be at least 2+ billion with website only.

With CUDA you try to keep all threads doing the same thing. Sometimes that’s very difficult, but if each thread does the same thing 98% of the time, is that enough? Well since there are warps of 32 connected threads, you might expect the probability that any thread in the warp diverges to be .98^32, or 50% of the time spent with one thread in the diverged code. 50% still doesn’t sound that bad unless threads diverge at different times, and then 50% warp divergence might mean a 16x slowdown overall. 98% isn’t enough in this case.

On the flipside, if a client enters enough venues that refuse entry to them because of something the client can fix on their end, eventually the client will probably change themselves -- "If you meet one asshole during your day" and all that.

To bring the analogy back to browsers, if a website works fine for a client, they'll have no pressure to change anything on their end -- why upgrade from Windows XP when the site looks fine in IE6? Eventually the client is forced to upgrade -- normally by their operating system. That works, but what if the operating system adds another 2 years to their end of life -- do you just hang on and hope the shim / hacks you added hold?

(Of course, this assumes that each decision is independent, which, when you're talking about browser support for CSS, is certainly not the case.)

Close, but the other way round. Don't avoid a feature because it lacks good enough support. Write code to progressively enhance the experience if the feature is supported in the user's browser. If you're not willing to do that, then don't use the feature.

Progressive enhancement today means you can use pretty much any browser feature you want. You just have to do a bit of legwork with some @supports or JS prototype checking after doing the basic version first. It's not really much extra work.

So, 10% of android users dont have web features beyond, at best, June 2025.

caniuse.com does not track this - they lump all Chrome for android together in the latest version.

This is painful as someone who wants to make use of some very useful, powerful new features, but is targeting people who are most likely to have old, slow, not-updated devices...

The web has been doing this since, when, the 90's?

I use Firefox. In the last year, suddenly quite a few web sites have just stopped working on it for me. Firefox is over 2% market share.

But a single-spaced-typewritten page has about 500 words, so you were looking at five typos every single page. It was good at the time, but you still had to manually check every single word.

I used to work in company where we have spent a lot of time making custom fixes for our software in order to work-around wired hardware/software bugs on machines of individual customers. Yes, we provided service for remaining 2% or so, but in cost of slowing-down overall product development and not making our product better for remaining 98%.

With a website, you can have the "real" layout, but when someone is blocking your JS, you can fallback and still provide content.

We won't get every mobile application working on old browsers, but we can offer something to the end user. Even a page that lets them know they are missing out.

But CSS Nesting? We can have that and a fallback.

So I like the opposite approach. If there's literally one guy on the planet, and this article/app/idea changes his life... what would that look like?

That's a bit lower than I would be comfortable with, however not that bad, we have been even considering switching all our images to AVIF: https://caniuse.com/?search=AVIF

And google uses Webp all over the place and that's sitting at 96% https://caniuse.com/webp

Author's 98% take is a bit misguided.

The second biggest thing is progressive enhancement. The author picked a CSS feature (nesting) that is basically all-or-nothing: the site will basically be entirely broken for those 2% if you swap Sass for native nesting. Most features aren't like that; maybe the site won't look pixel-perfect on old browsers, or one bit of functionality won't work, but by and large it will still be functional. In those cases, I think it's a much easier decision in terms of where to draw the cutoff.

Yes, because all of us have website serving, checks notes, the entire world...

98% is probably in the neighborhood of 8% more than I'd require for browsers compatibility before deciding to use a new feature. At a certain people need to update and we do ourselves and our other 98% of customers no favors by catering to the lowest common denominator.

See also, the story of YouTube adding a banner pushing people to upgrade off old IE version being a large factor in people upgrading. Now, obviously, we aren't all running YouTube-sized sites but building for ancient browsers is, very often, a large waste of time.

In the age of evergreen browsers you have to go out of your way to be using something that's not at most a couple years out of date.

Of course 98% of sterilization is not enough for surgery or for precision in calculating your account balance but the category of landing page conversion a 98% would be astronomically high.

In some categories, certainty and percentages make a lot of difference--surgeries, accidents. In some, they don't--surveys, grades.

It just depends on the category.

This is akin to saying something as obvious as more percentages are more than less percentages.

in this sense, related https://danluu.com/p95-skill/

Well I wasn't very far off I guess! Perhaps "5 nines" is a good threshold for new CSS features too?

This reminds me almost precisely of the dynamics of pro sports in the US and how fans are getting priced out of attending games or even watching teams on TV as organizations shift to bespoke streaming platforms.

Suppose 98% users have not had any sessions crash. You want to build an addon feature that 10% of your users will buy and which will increase the revenue from those users by 30%.

Do you spend time building the feature, or trying to understand why 2% of users sometimes see crashes?

Just like the article says, it depends on if the product is an essential or a dessert.

If your product is a "essential necessity" one, then 98% is terrible for your software.

If your product is a "dessert", then for it's software 98% is awesome.

When expectation is 100%, telling me 98% success rate isn't enough. An example where the argument happens on Reddit, Macrumours and even on HN. When Apple's butterfly keyboard have issues. Apple Supporter was quick to dismiss the issue and point out the double entry is such a small issue because it is working 99.9% of the time. What they don't realise keyboard before that was practically 100%. That 0.1% error rate is infinitely more than 0%.

Another example is Internet connection When you are used to perfect Internet connection, just a small beep in disconnecting turns to be major annoyance. There are plenty of these examples especially with DOCSIS Cable modem. The modem theoretically is working 99,95% of the time, hence cable companies won't fix it. But Disconnecting 10 to 30 seconds every day is annoying enough.

I am not sure if there is a word or terminology for it so this could be better explained to people.

On the other hand, there are plenty of things where 80% is good enough, or doing above and beyond at 96% by getting 80% out of the original remaining 20%.

Full disclosure: I also argued against covid restrictions, but not with this terrible argument.

Your classifier might be 98% accurate and it may sound like a lot.

But if it sits inside a car, making thousands of decisions during every trip then you may be in deep trouble.

How do you justify this when you factor in cost and time?

this is your brain on data science. so absurd that i laughed out loud when i read "like a baby surviving a babysitter taking care of them" like what is that phrase doing in this sentence and argument

98% market share? Amazing. 98% browser support? There are 15 billion screens in the world. 2% of that is 300 million. Hardly a number we can ignore. Edge cases for those 2% should be considered and implemented

Hover text: You can do this one in every 30 times and still have 97% positive feedback.

I've seen this so many times. 99% of search results are good (so within 100 queries you'll hit at least one bad result with p≈0.63), 99% of dashboard panes load normally (so a dashboard with 20 panes is broken in nearly 1 in 5 loads), and so on. If your LLM gets 99% of tool calls right, nearly every session will contain a malformed tool call.

Probabilities are hard for humans, probably.

Websites are surprisingly hard to maintain long term, specially for a broad audience of devices. Developer Experience can lead to better UX, the easier it is to build/maintain, the more likely we're to do it.

Given how bad AI is at design plus all the unstoppable slop train, I expect websites to become much, much worse.

Isn't that a named law?

Don't look at the simple probability - look at probability * value.

I feel like we should be building for the 98% or even 95% and force the remaining to upgrade their browsers. I've built for the IE6 - IE11 era for a painful and long time. I do not give a shit if you want to use a 3 year old browser at this point. Go look at a blank screen.

I think either you argue for regulation, or you argue more honestly: asserting that the extra cost will likely never directly pay for itself, but it is some of the secret sauce that can a good product into a great one.

A better analogy would be a restaurant deciding not to cater to the 1% of the US population that have celiac disease (cannot eat gluten), or the 2% that have issues with dairy.

Just tell the AI to do it. It'll find a way. The maintenance burden for you will be minimal because the AI can keep the legacy compatibility bits in sync.

Sure, it's called a 'dress code'.

The "baseline" means nothing. The percentage in caniuse means nothing. The only number that matters is the number of Safari users stuck using a no longer supported Apple device that access your website. Of course Apple makes sure to hide usage stats of older devices.

Everyone complains about only having three browser engines out there, but I'll be happy to go down to two if that means freeing the world from Safari.

Whether 98% is acceptable, it depends on the cost of failure, not the percentage itself.

it that reduces development/maintenance cost by a lot, that's not a terrible deal.

"99 and a half won't do"

https://youtu.be/1QVJCjbgM-s

Holy Disciples

Trying to Make a Hundred

Software standards are way too low these days. If you can't do at least 5 9s in everything you ship get out of the industry and humanity will be better off.

https://www.mediawiki.org/wiki/No-JavaScript_notes

Objectively, I think it's impossible to work in the food industry and avoid food poisoning 100% of the time. One of the reasons I never attempted several of my food industry business ideas. I'm certain they would be at least profitable enough to keep going, would be rather trivial to access EU subsidy money in the €50k, but the amount of regulations and inspections terrifies me. And I'm sure at some point, some salmonella or what else would slip through and don't wanna deal with the consequences.

Easier with programming computers since a "bug" won't make people expell waste simultaneously through both incoming and outgoing food orifices, like it happend to me last time I ordered sarmale from a local restaurant. Like in the food industry a "bug" is literally that.

I've been in the two ends of this situation, in the 2% with older iPhones and Android devices, and in the 98% with new devices. The 2% cannot hold a tyranny over the absolute majority, and vice versa. Everything must be evaluated on a case-by-case basis.