Yeah, when I read the article I thought "Great, more paternalistic advice that pretends we have infinite resources/time/money."

Anyone who has ever done website or mobile development knows there is a huge array of browsers and platforms, and supporting the very long tail of configurations is sometimes nearly impossible, let alone almost never cost effective. When I last ran some web apps, we'd see substantial numbers of errors just due to f'd up (or sometimes outright malicious) browser plugins. I'm not checking every random configuration of browser plugins against my website to ensure they all work.

Like you say, it really depends, which is why I hate blanket directives like the article gave. If suddenly 2% of people couldn't log into gmail, that would be a huge deal affecting 10s of millions of people. As the adage goes, "You're not Google", and for a lot of small e-commerce websites trying to fix someone on some decade+ old browser just doesn't make sense (and, as another comment mentioned, these users are often the least likely to convert in any case).

▲

throwaway173738 an hour ago | parent | next [-]

He wasn’t actually giving a blanket directive. The article was suggesting that you think about whether 98% is actually good in your use case by doing the math and thinking.

▲

Eridrus an hour ago | parent | next [-]

Yeah, but the guy writing the article seems to be bad at math and thinking.

Can I imagine a venue kicking out 2% of their former clients on some criteria? Absolutely yes.

Kicking out 2% of website visitors may still be totally reasonable if the cost to serve them is meaningful, or if they are less than 2% of revenue.

His defense for 98% being bad is that some CSS thing people were arguing about only had 70% coverage on his website.

Our b2b dashboard didn't support Safari for a while at all and it was entirely not an issue because everyone had a simple workaround to just use Chrome and the dashboard wasn't really the main product.

	▲	alwa 4 minutes ago \| parent [-]
		I’m familiar with some venues that only admit around 2% of those who seek to attend… as I recall they command something of a premium from those “lucky” enough to make it through the door…

▲

hn_throwaway_99 an hour ago | parent | prev | next [-]

Except there was 0 analysis of the cost/benefit of supporting the end of the long tail, instead it was just economics-free shaming. Of course, you want to see who those 2% of users actually are. But nowhere in this article did I find any advice I'd actually want to use in a really business scenario.

▲

s3p 36 minutes ago | parent | prev [-]

I mean the name was "98% isn't much" and the article made it sound like 98% isn't good enough

▲

ryandrake an hour ago | parent | prev [-]

Respectfully: To me these just sound like excuses.

I can write a web page that works correctly on all browsers. We all can. That web page won't do much of anything, but it's possible. So, there is a baseline "target subset of HTML/CSS" that gives you 100% coverage. From there, it's purely developer choice: When you add something, are you choosing technology that is widely available and supported, or are you choosing to throw 0.N% of users under the bus for some benefit (development speed/comfort)? Obviously, it's a trade-off, and no final product is going to work on 100% of configurations. All these choices deliberately made during development add up to the product you deliver at the end of the day. All I'm asking is that we recognize browser/platform incompatibility/inaccessibility as choices and not some inherent property of software.

When a developer says "it's too expensive to develop this for a dozen configurations" that just means they have already chosen to make their applications inaccessible, and are justifying it after the fact.

▲

dfabulich 7 minutes ago | parent | next [-]

The inherent property of software is that the only way to be sure your software works on a particular platform is to test on that platform.

There is not a baseline target subset of HTML/CSS that reaches 100% coverage that can be statically verified. HTML tables usually work in old browsers, but there were subtle bugs in old versions of Internet Explorer, bugs that you're especially likely to hit if you're using tables for layout (because you can't use modern CSS layout features). The only way to be sure that you didn't trigger one of those subtle bugs is to test your web app on ancient browsers.

The cost of reaching the last 0.N% of users rises with each platform you add to your test matrix. It costs money to test your web app on Internet Explorer. It costs even more money to fix bugs that only affect Internet Explorer.

I think you can't deny that doing that work is expensive. The question then has to be whether that work will repay itself somehow. But the last 0.N% of users will only provide ~0.N% increases to your revenue. Unless your revenue is astronomical, you can't afford even one full-time engineer to test and fix bugs on 0.N% of browsers.

▲

anoneng an hour ago | parent | prev [-]

This goes to show you’ve never been anywhere near the actual development cycle of a real-world front-end web application. “So, there is a baseline "target subset of HTML/CSS" that gives you 100% coverage.” Oh really? Which subset? Which “HTML/CSS?” And 100%? Absolutely laughable.

	▲	drdeca 14 minutes ago \| parent [-]
		Do you know any browsers which don’t support https://motherfuckingwebsite.com/ (if you remove the google traffic tracking js that’s iirc tacked on at the end of the page (or maybe I’m thinking of better mfing website (which adds a tiny bit of css)? Idr.)) ? I get that asking a commercial website to be as basic/supported as that website is a big ask. I don’t think the other commenter was saying that such websites should reach 100%, only that they should start from there and sacrifice only as much as is necessary.