No, what you have here is a slide deck about standard or standards-track features that includes features that don't all work cross-browser yet, and may change significantly before they do. When people respond like this to slide decks, I always wonder what they would have preferred? A video of the presentation, but no live version? Screenshots of the working draft text of the spec?
This is a slide deck for developers. It explicitly says what browser it currently works in and where it might break. Developers usually have more than one browser installed, which makes this not that big of a deal. It does highlight explicitly, however, that developers will then have a choice to make if they want to use those features and want them to work cross browser. They will either have to work to implement (or find an existing) cross-browser polyfill, or they will just have to be patient while the feature is specced and implementations deploy.
There is tension here, admittedly, because eager developers will always push new features that aren't available universally yet, because it allows them to do something new. This is why, for instance, in some cases Mozilla has moved away from vendor prefixing to instead exposing some proposed features in only alpha and beta builds, so that developers won't be tempted to use them in production (which means breaking changes in a spec will break already deployed websites) until the spec is settled. This hopefully will be picked up by other browser vendors (though, again, only for some features). I know some Chrome developers have been very receptive to this approach.
In the meantime, it's good to educate yourself (as a developer) and others about what is coming, especially because while something is still coming (and not here yet) you can still go join a w3c/whatwg mailing list and give feedback.
For instance, you could start with your Audio APIs question by looking to the Audio Working Group:
No. It doesn't fly. Have you ever wondered why there were standards, and why a standard is _called_ a standard?
According to this, "HTML5" is made for various specs to compete. Except, HTML is a standard. HTML5 is an upcoming standard (or so does it claims to be).
If everyone includes APIs in their _production_ browsers (in case you haven't noticed, most of the various features are actually in production browsers, despite what you wrote) that are incompatible, that's no standard, and there will never be a standard, no matter how you put it, as there will always be a never ending competition for the "new APIs". NEVER ENDING.
So, if vendors start implementing API that they don't call HTML(5), but just their own, well guess what? That's "webkit-HTML", and it happens to be exactly how I dubbed it.
So no. HTML5 is not wow, and yes, that site, like many others, is webkit-only, on production webkit browsers. That's un-defendable.
I'm not sure I understand the bad part you're objecting to.
Is it that webkit is implementing different parts of "HTML5" and related specs that haven't been finalized than other browsers? All the browsers do this, and it's a good thing. Not only are independent implementations required for w3c specs to even become finalized, it's also widely accepted that implementations of features (prefixed and possibly guarded by runtime flags or confined to non-stable versions of a browser) are often the strongest case you can make for adding something to a spec in the first place. This is a difficult tightrope to walk, as you can easily go too far out ahead of a working group, but it has served us pretty well in the last few years.
Or is it that this slide deck is using non-standard features to give a preview of what the standards working groups are working on? Here's a not very hypothetical hypothetical: if you were giving a talk on upcoming Javascript features in es6, and you wanted to talk about the yield keyword, a great way to show it in action is to add a 'type="application/javascript;version=1.8"' to your script tag, which allows the use of yield today in shipping Firefox browsers[1].
To be sure, you're not recommending that developers go out and build their apps around this right now, because it only works in one browser (maybe two if v8 has added yield behind their "Enable Experimental JavaScript", I'm not sure). But showing it in action is a powerful education tool.
Now, if you wanted to publish your slide deck afterwards, what would you do? A pdf of your slides is pretty lame, at least on its own. It was interactive during the presentation, there's no reason it shouldn't be interactive when playing with it online, but you'd have to warn that it only works in Firefox. You could add that static pdf version as well, but the code is already right there in the page, and this is a developer audience, so they almost certainly have Firefox installed no matter what browser they use for day-to-day browsing.
It's really not that big of a deal. Save the anger for actual attacks on the web.
I don't see any anger in my comments, simply disappointment. Let me explain it a last time in a very simple manner:
I'm no developer and I must use Chrome to see this website properly, and it's far from the only website with that issue. In fact, even if I was a developer, I should be able to view any site that's designed for production browsers properly, with any browser, as long as they're not buggy.
So, there's a standardization problem. You can keep trying to defend it and how it's all made in good faith - it might even be - but the end result is unfortunately, the same.
Comments
No, what you have here is a slide deck about standard or standards-track features that includes features that don't all work cross-browser yet, and may change significantly before they do. When people respond like this to slide decks, I always wonder what they would have preferred? A video of the presentation, but no live version? Screenshots of the working draft text of the spec?
This is a slide deck for developers. It explicitly says what browser it currently works in and where it might break. Developers usually have more than one browser installed, which makes this not that big of a deal. It does highlight explicitly, however, that developers will then have a choice to make if they want to use those features and want them to work cross browser. They will either have to work to implement (or find an existing) cross-browser polyfill, or they will just have to be patient while the feature is specced and implementations deploy.
There is tension here, admittedly, because eager developers will always push new features that aren't available universally yet, because it allows them to do something new. This is why, for instance, in some cases Mozilla has moved away from vendor prefixing to instead exposing some proposed features in only alpha and beta builds, so that developers won't be tempted to use them in production (which means breaking changes in a spec will break already deployed websites) until the spec is settled. This hopefully will be picked up by other browser vendors (though, again, only for some features). I know some Chrome developers have been very receptive to this approach.
In the meantime, it's good to educate yourself (as a developer) and others about what is coming, especially because while something is still coming (and not here yet) you can still go join a w3c/whatwg mailing list and give feedback.
For instance, you could start with your Audio APIs question by looking to the Audio Working Group:
http://lists.w3.org/Archives/Public/public-audio/
http://www.w3.org/TR/webaudio/
No. It doesn't fly. Have you ever wondered why there were standards, and why a standard is _called_ a standard?
According to this, "HTML5" is made for various specs to compete. Except, HTML is a standard. HTML5 is an upcoming standard (or so does it claims to be).
If everyone includes APIs in their _production_ browsers (in case you haven't noticed, most of the various features are actually in production browsers, despite what you wrote) that are incompatible, that's no standard, and there will never be a standard, no matter how you put it, as there will always be a never ending competition for the "new APIs". NEVER ENDING.
So, if vendors start implementing API that they don't call HTML(5), but just their own, well guess what? That's "webkit-HTML", and it happens to be exactly how I dubbed it.
So no. HTML5 is not wow, and yes, that site, like many others, is webkit-only, on production webkit browsers. That's un-defendable.
I'm not sure I understand the bad part you're objecting to.
Is it that webkit is implementing different parts of "HTML5" and related specs that haven't been finalized than other browsers? All the browsers do this, and it's a good thing. Not only are independent implementations required for w3c specs to even become finalized, it's also widely accepted that implementations of features (prefixed and possibly guarded by runtime flags or confined to non-stable versions of a browser) are often the strongest case you can make for adding something to a spec in the first place. This is a difficult tightrope to walk, as you can easily go too far out ahead of a working group, but it has served us pretty well in the last few years.
Or is it that this slide deck is using non-standard features to give a preview of what the standards working groups are working on? Here's a not very hypothetical hypothetical: if you were giving a talk on upcoming Javascript features in es6, and you wanted to talk about the yield keyword, a great way to show it in action is to add a 'type="application/javascript;version=1.8"' to your script tag, which allows the use of yield today in shipping Firefox browsers[1].
To be sure, you're not recommending that developers go out and build their apps around this right now, because it only works in one browser (maybe two if v8 has added yield behind their "Enable Experimental JavaScript", I'm not sure). But showing it in action is a powerful education tool.
Now, if you wanted to publish your slide deck afterwards, what would you do? A pdf of your slides is pretty lame, at least on its own. It was interactive during the presentation, there's no reason it shouldn't be interactive when playing with it online, but you'd have to warn that it only works in Firefox. You could add that static pdf version as well, but the code is already right there in the page, and this is a developer audience, so they almost certainly have Firefox installed no matter what browser they use for day-to-day browsing.
It's really not that big of a deal. Save the anger for actual attacks on the web.
[1] https://developer.mozilla.org/en-US/docs/JavaScript/New_in_J...
I don't see any anger in my comments, simply disappointment. Let me explain it a last time in a very simple manner:
I'm no developer and I must use Chrome to see this website properly, and it's far from the only website with that issue. In fact, even if I was a developer, I should be able to view any site that's designed for production browsers properly, with any browser, as long as they're not buggy.
So, there's a standardization problem. You can keep trying to defend it and how it's all made in good faith - it might even be - but the end result is unfortunately, the same.