5 ms·

"...the W3C has already become borderline irrelevant to the future of the web, as it has been far too slow to standardise everyday technologies that have been w

by magicmu 11y ago

"...the W3C has already become borderline irrelevant to the future of the web, as it has been far too slow to standardise everyday technologies that have been widely deployed in browsers for a considerable time" This is a bold statement, but one that I'm surprised to find myself agreeing with. I suppose now it's a matter of figuring out what should replace the W3C; things are only going to move faster.

Silhouette 11y ago
It is a bold statement, true, but I stand by it. A decade ago, if I wanted to look up how something in say HTML or CSS worked, I'd probably go straight to the W3C site and just read the spec. Today, my first ports of call are places like MDN, caniuse.com, or sometimes places like the Babel documentation or kangax's ES6 compatibility table. 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. 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.
- gsnedders 11y ago
  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 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 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.)
  - Silhouette 11y ago
    For what it's worth, I don't dispute at all that the quality of CSS specs from the W3C has improved over time. However, specs are means to an end, and the usefulness of any spec is inevitably dictated by the implementations that exist. As a professional, I truly wish this weren't the case, but as a professional, my job is to make a working site, not necessarily a standards compliant one. All too frequently, it is still not possible to do both at the same time, either because browsers don't implement W3C recommendations consistently, or because of the poor quality of implementation you alluded to yourself, or because even when browsers did provide a useful implementation yesterday someone broke it in an update last night and today I'm rewriting something a different way because platinum support customers started calling first thing this morning and get a same day response not a 6 week one. "Of course I understand that it's the update we just rolled out to our corporate standard browser that broke your standards-compliant and otherwise normally functioning site," said no customer ever. :-)
icebraining 11y ago
Didn't we already learn what comes after the W3C? Development of HTML5 was mostly pushed by the WHATWG, with W3C later rubber stamping it as the new version of HTML.
- Silhouette 11y ago
  On the other hand, that seems to be where ideas like "living standards" come from. I'm not sure that constitutes (useful) progress in this case.

by magicmu 11y ago

Silhouette 11y ago

It is a bold statement, true, but I stand by it. A decade ago, if I wanted to look up how something in say HTML or CSS worked, I'd probably go straight to the W3C site and just read the spec. Today, my first ports of call are places like MDN, caniuse.com, or sometimes places like the Babel documentation or kangax's ES6 compatibility table. 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. 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.

gsnedders 11y ago
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 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 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.)
- Silhouette 11y ago
  For what it's worth, I don't dispute at all that the quality of CSS specs from the W3C has improved over time. However, specs are means to an end, and the usefulness of any spec is inevitably dictated by the implementations that exist. As a professional, I truly wish this weren't the case, but as a professional, my job is to make a working site, not necessarily a standards compliant one. All too frequently, it is still not possible to do both at the same time, either because browsers don't implement W3C recommendations consistently, or because of the poor quality of implementation you alluded to yourself, or because even when browsers did provide a useful implementation yesterday someone broke it in an update last night and today I'm rewriting something a different way because platinum support customers started calling first thing this morning and get a same day response not a 6 week one. "Of course I understand that it's the update we just rolled out to our corporate standard browser that broke your standards-compliant and otherwise normally functioning site," said no customer ever. :-)

icebraining 11y ago

Didn't we already learn what comes after the W3C? Development of HTML5 was mostly pushed by the WHATWG, with W3C later rubber stamping it as the new version of HTML.

Silhouette 11y ago
On the other hand, that seems to be where ideas like "living standards" come from. I'm not sure that constitutes (useful) progress in this case.