I do want to recognize that the Safari/WebKit team are working hard, and I do desperately want them to succeed! Chromium’s domination is bad for everybody, and building a popular browser that’s focused on privacy & security, as they appear to be trying to do, is a fantastic goal. That does not mean their current approach deserves our blind support.
I’m sure the Safari team are working on the issues below already, and I think it’s likely that the problems fundamentally derive from management decisions about company priorities rather than the team themselves.
Well, this is a grim collection from Dave:
There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.
It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”
I love this example of paying it forward:
A great long-term perspective from Rachel on the pace of change in standards getting shipped in browsers:
The pace that things are shipping, and at which bugs are fixed is like nothing we have seen before. I know from sitting around a table with representatives from each browser vendor at the CSS Working Group how important interop is. No-one wants features to be implemented differently in browsers. This is what we were asking for with WaSP, and despite the new complexity of the platform, browsers rendering standard features in different ways is becoming increasingly rare. Bugs happen, sometimes in the browser and sometimes in the spec, but there is a commitment to avoid these and to create a stable platform we can all rely on. It is exciting to be part of it.
Jake’s blow-by-blow account of uncovering a serious browser vulnerability is fascinating. But if you don’t care for the technical details, skip ahead to to how different browser makers handled the issue—it’s very enlightening. (And if you do care for the technical details, make sure you click on the link to the PDF version of this post.)
I like the idea of “design bugs”:
Every two weeks or so, a group of designers would get together for a couple of hours to fix what we called “design bugs.” These were things that didn’t hinder functionality and wouldn’t have been filed as an engineering bug, but were places where we were using an old component, an existing one incorrectly, or a one-off alteration.
Rachel is maintaining this (short) list of browser bugs with CSS Grid, inspired by the excellent Flexbugs.
Grid shipped into browsers](https://gridbyexample.com/browsers) in a highly interoperable state, however there are a few issues - let’s document any we find here.
A list of known bugs (and workarounds) in flexbox implementations. This is going to be handy to refer back to.
I like this idea. It would be nice to see it catch on…
- Report a bug for any website or browser.
- Our team of volunteers diagnoses the bug.
- We send a fix to the site owner or browser.
Scott has created a one-stop-shop for documenting browser bugs in mobile devices. Feel free to add to it.
Some of the best neologisms in programming, many of them to do with bug-fixing.
Garrett has launched his bug-tracking web app. Looks lovely.