I don't think that's true at all: there's far more relevant work going on at the W3C than there was a decade ago.

Pretty much the only thing the W3C was working on that affected web developers a decade ago was CSS 2.1 and a couple of CSS 3 modules (Backgrounds & Borders and Selectors come to mind but nothing much else).

Yes, admittedly, it's still more-or-less just CSS work that actually happens at the W3C (with increasingly large amounts of work happening at the WHATWG covering the majority of the rest of the platform, HTML and DOM especially), but the number of CSS modules being worked on is vast, and the quality of the specifications is far greater than it was a decade ago.

As for:

> I really wish this weren't the case, because the lack of standardisation and vast numbers of browser idiosyncrasies makes development much more onerous and less reliable than it should be. But the W3C just couldn't keep up, and for now the browser developers seem to be mostly ignoring it as a result.

Per above, the quality of specifications is far greater than it was a decade ago, and it is (despite the perception of many) still the case that specifications are most of the time always nearly-complete before anyone ships anything (typically the incomplete parts are the bizarre edge-cases that no web developer is likely to ever run into, but there is a real attempt to avoid undefined behaviour), and there's definitely more involvement across the various standards orgs from all browser developers than there was a decade ago, W3C included.

The increasing number of browser "idiosyncrasies" is mostly a result of ever-increasing complexities in implementations (partly down to the increasing complexity and size of the web platform, partly down to new features being retrofitted into implementations that weren't originally designed to do anything like the new feature, and partly down to lack of a good shared, between all vendors, testsuite for CSS).

I am remain hopeful that we're moving towards somewhere better when it comes to interoperability across browsers. web-platform-tests (https://github.com/w3c/web-platform-tests) has got us a good, high-quality test suite for the platform minus CSS, and is run by most but not yet all browsers on a daily basis (and I think it's realistic to hope that by the end of 2016 it'll be run by all browsers on a daily basis, and that for many it will be the place they write tests, hence test suites will basically become shared rather than done separately with different coverage holes for bugs to slip through). csswg-test (https://github.com/w3c/csswg-test) is slowly starting to move towards a point where it'll be as widely run as web-platform-tests (please don't make me think about this too much, I'm finally making progress there, making the same arguments as five years ago but now with the evidence from web-platform-tests that it actually works).

And finally:

> I can't remember the last time I read anything on the W3C site. I do find myself there now and then, but sadly, it is simply irrelevant to most of my daily web development work. What matters in a world with ever-moving goalposts is what browsers can actually do right now, which today basically means which of the evergreen browsers have support currently, which of their LTS releases also have support, and what the situation with IE and possibly older mobile browsers is, as validated by actual testing in each case.

Really that makes it sound like half the problem is the fact that the spec documents give no informative data about what browsers support what features. There's definitely been talk about trying to do something better here, but it's a hard problem: you need some way to gauge support and quality of implementation, across all browsers and across all features. I think there's mostly agreement that caniuse is actually too coarse to really be put anywhere near a spec (because specs are rarely implemented as atomic units—there's normally different statuses for different sections), and that just grabbing test suite results isn't that useful either (because you can fail large numbers of tests due to obscure bugs, or because you've only implemented the awkward 20% not the easy 80%, so you're actually closer to shipping complete support than someone who supports the easy 80%).

(As a disclaimer: I've been around the W3C and WHATWG for quite a while (coming up to a decade), have been employed/contracted for several browser vendors, and was one of the early pushers to get high-quality test suites shared across all browsers.)