← Back to context

Comment by ryandrake

1 day ago

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.

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.

  • But again you're flattening all browser compatibility into ancient browsers that 10 people use and saying closing the end of that gap is far too difficult to justify the time and expense required, but what exactly are we talking about there? What broke? Can people on IE6 get the majority of the content but the subscription popup is broken, or does the page fail to render entirely and leave them completely high and dry?

    It's impossible for me to engage with this thought experiment without thinking of hundreds, perhaps thousands of sites I've been to (their provider rhymes with Rare Mace) where literally nothing works without JavaScript, and I don't mean animations are broken or images look funny, I mean the website is a white fucking screen because literally everything is loaded in via esoteric new JS frameworks which aren't firing because the engine choked on an analytics package and died before it even got that far, and that site is showing...

    ... text. Formatted text. With perhaps some pictures. And animations nobody outside of marketing cares about.

    So like, is your site broken because it's legitimately cutting edge shit, doing difficult work, and providing an answer to a complex user problem? Okay cool, IE6 support is probably not a high priority, I agree. Or, is it an utterly run-of-the-mill ad for your company's services, that was made incorrectly by people who don't know what they're doing, and/or have overengineered it beyond recognition of the actual problem it was trying to solve? If it's that one, then put your shiny toys down, rebuilt it simply and with regular tooling, and THEN see how your IE6 compatibility is doing.

    I'll tell you this much: I've NEVER tested for IE6 on my personal website. I just did. Navigation is a bit wonky and my blur filter effects are broken, obviously. But you can still read my posts and navigate about.

At what point is a good point to call it a day though?

Unless I am very specifically being paid for it, which I would love to be and I would enjoy doing because I love CSS, there are features that would rather make my experience, and the experience of the entire site better over the course of a decade+, such as nesting. Nesting has changed everything about CSS for me with project organization that makes changes significantly easier, AND significantly easier to pass off to another person. Now that it's at about 90% browser compatability[0] I actively use it in every single project I can, but it's still not supported if you haven't updated your browser in 3 years or use a random oneoff browser that may come with your knockoff smartphone.

It is an excuse, but it's also an honest question. Granted, not all projects are created equal, some of them are for people looking for bleeding edge technology, where it makes sense they would have their browsers updated. Some are government websites that should be accessible to 100% of everybody even if they're looking at your page on a 14 year old psp.

[0] https://caniuse.com/css-nesting

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.

  • 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.

    • > I get that asking a commercial website to be as basic/supported as that website is a big ask.

      The trick isn't to get a commercial website to accept a site that basic, it's to get the website to test for capabilities and if it can't confirm them serve only the basic version. Websites should be every bit as fancy and obnoxious as they want as long as they fail gracefully.