Show more

also the reason I'm up this late is I am grooving to Soft Music to Do Nothing To by @jjbbllkk@twitter.com while also finishing up the largest dang single cleanup task in publ ever holy hell github.com/PlaidWeb/Publ/pull/

even if I don't I feel like the last track I did is a nice little endcap to the collection anyway, and while I didn't do a full 30 songs this year I did do a bunch of stuff that was way higher-effort than previous years so I think I can give myself a break on this

I didn't novembeat yesterday becuase of thanksgiving, and I didn't today because I didn't feel like it. I'll try to do something for the last day of November though

Oh hey, free shipping on my @threadless@twitter.com store until December 9! busybee.threadless.com/ Use code HOLIDAYSHIP19d09f65

Feel free to reply to this rant by tagging companies whose websites have problems like these. For example, this particular rant was brought on by @Threadless@twitter.com.

Remember that one of Google's unofficial slogans is to "move fast and break things."

That's great for them, when they have the resources to fix them. But the stuff that gets broken could very well be *yours*. Don't rely on their benevolence.

Chrome plays very fast and loose with standards. It doesn't even remain consistent *with itself* a lot of the time, and if you're doing a thing that works on Chrome but doesn't work on another browser, it is very likely to break when Google decides to change some feature flag.

Anyway, absolutely the worst thing you can do for interoperability is to only build and test on the latest version of Chrome and then consider it a user error for someone to run into a problem on another browser.

And if your console is showing a lot of errors, *those are bugs and should be fixed*.

Even if the errors are "unimportant" things, and especially if there's so many of them you can't figure out what the actual problem is!

Also, some advice to support folks: if someone says your site doesn't work in their browser, don't suggest they change browser; instead, test the site on that browser and check for errors in the JavaScript console or the like.

Both have different JS implementations from each other as well as from Chrome. It is easy to write code that works in v8 but fails in JavaScriptCore or vice-versa, but code which works in both tends to work everywhere.

Firefox is generally the strictest about adhering to the current web standards, and keeping their experimental stuff experimental until it's ratified.

Safari is WebKit-based, so it has roughly the same layout engine as Chrome.

When I build a thing, my standard practice is to develop on Firefox, test on Safari, and do a quick spot-check on Chrome. This covers all of the bases for my purposes.

This increases your support burden because you have to worry about multiple versions of browsers (and not everyone can update to the latest), and it also means that you might get blindsided by something breaking when that browser updates.

This isn't good for anyone.

Show more
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!