It uses webkit tags because they aren't standardized yet (or implemented in standard form).
This slidedeck is intended as a supplement to the html5rocks demos. Html5rocks has stable HTML5 code, whereas this one has a lot of experimental stuff that isn't quite ready for real use yet.
About half the demos worked for me. I'm running Chrome for Mac, with the Developer Channel. Will Canary Build (only available on Windows) run them all?
I'm just going to take this opportunity to shake my fist at Internet Explorer, because much of this stuff is useless on production websites (some things are usable with Javascript hacks).
Features that haven't been standardized are put in their own namespaces. For example, webkit-* and mozilla-* had conflicting implementations of CSS gradients for a while. After the standard was ratified, the prefix was removed. Safari still supported the old webkit-* syntax, and Firefox still didn't, just like before, but new pages could use the functionality without the prefix and it would work in both browsers.
Also, if webkit has settings or features that are specific to the library used, it makes sense to put those in a different namespace as well, to avoid pollution.
MSXML XMLHTTP. MSXML 2.0 released with IE5 was first to support it. It got copied first by Mozilla, BTW, then as AJAX caught on in 2004 Safari copied it too.
What is wrong with that? It's a vendor extension, like most new CSS and JS features are implemented. A draft specification for the Speech API exists since last October, if I'm not mistaken. So why would that not work?
Element.classList is a bit of an odd addition. No doubt it'll be useful, but wouldn't something more generic have served us better? Class isn't the only attribute that takes space-delimited values. (Or is there also Element.relList?)
If that sort of page is cool, please give me back an HTML4 page I can just browse through without wasting several minutes waiting for the content to appear.
This should bypass it. On the page, open up the console (right-click Inspect Element and go to Console tab) and type these 2 lines to remove 'to-build' class. Then you can read through the slides without having to wait.
j = document.getElementsByClassName('to-build');
for (k=0; k<6; k++) { for (i=0; i<j.length; i++ ) { j[i].className = j[i].className.replace(/\bto-build\b/,''); } }
PS I haven't done too much Javascript and someone else can probably write a shorter version, and I'm also not sure why looping just once isn't working.
A lot of these examples are not working for me (I'm running Google Chrome 12.0.742.112), especially the Audio example which I really wanted to use. I'm really excited about the features this presents, I just wish they worked on my browser.
I clicked the "speech input" element on the webpage and said "this is cool" and... the element showed "this is cool". It just works, no configuration or anything. This is so cool.
This presentation is pretty evil (or maybe incompetent?). It mixes up proposed standard features that are broadly supported, proposed standard features that are not well supported, and proprietary WebKit extensions that have no chance of being standardized as they are and presents it all as "HTML5". It also has code snippets that try to look like they'll work cross-browser but are actually broken in non-WebKit browsers due to relying on some of those extensions...
Google is pulling a Microsoft here. Back in the day, there was a lot of really neat stuff you could do only in IE. Like filters in CSS, etc. The problem was that you could only do it in IE.
Unless you're doing an internal facing site and restricting usage to Chrome, be careful. Unfortunate. Most of the stuff is pretty neat.
I know it's not the point but his audio synthesis sounds terrible, and that makes me feel like nit-picking:
- 8-bits at 20 kHz really?
- He's actually specifying 20480 Hz in the code, so it's not in tune
- He's using the range 255, but it's 8 bits _signed_ so it should be 127, so he's getting lots of distortion.
His wav header should be:
0x44,0xAC,0,0, // 44,100 samples per second
0x88,0x58,0x01,0, // byte rate: two bytes per sample
2, 0, // aligned on every two bytes
16, 0, // 16 bits per sample
and then in the synthesis:
var samplespercycle = 44100 / frequency;
var samples = new Uint16Array(44100 * duration);
var da = 2 * Math.PI / samplespercycle;
for(var i = 0, a = 0; i < samples.length; i++, a += da) {
samples[i] = Math.floor(Math.sin(a) * 32768);
}
> Chrome caps sampling at 60fps (no big, your monitor is ~60Hz)
No. My monitor here works up to 85 hz, a lot of LCD screen out there are capped at 75 hz. By limiting the framerate to 60 hz on a 75 hz screen you'll force it to look inferior to 60 fps because of duplicated frames (20% of them). It may actually matter in a game.
You all are bums. There are some excellent features to be up and coming. The point is not that some features do or don't work in some other browser. The point is you can point your users to an free, cross platform app they can download that runs you web-app with native implementations.
50 comments
[ 4.4 ms ] story [ 101 ms ] threadThis slidedeck is intended as a supplement to the html5rocks demos. Html5rocks has stable HTML5 code, whereas this one has a lot of experimental stuff that isn't quite ready for real use yet.
Edit: It's meant for Chrome 14.
Obviously, more of the feature demos worked in Chromium than in Firefox, but the presentation experience was smoother on Firefox.
Announcement: http://blog.chromium.org/2011/05/adding-more-yellow-to-mac-c... Download: http://tools.google.com/dlpage/chromesxs
And don't forget MIDI and Drect3D support was introduced in IE4. Before SVG, there was a trend of VRML in the industry and VML was added to IE.
And don't forget, the very first AJAX as made possible by the IE xmlhttp object.
TIME+dHTML was cool before Flash, even before these Web2.0 and HTML5 cool kids start yammering around.
And then Microsoft killed these features with their Silverlight.
Also, if webkit has settings or features that are specific to the library used, it makes sense to put those in a different namespace as well, to avoid pollution.
MSXML XMLHTTP. MSXML 2.0 released with IE5 was first to support it. It got copied first by Mozilla, BTW, then as AJAX caught on in 2004 Safari copied it too.
Also realised that some pages which looked blank loaded after about 2 mins.
"https://html5-demos.appspot.com/static/html5-whats-new/slide... (line 480) : slide.dataset is undefined"
Unless you're doing an internal facing site and restricting usage to Chrome, be careful. Unfortunate. Most of the stuff is pretty neat.
I know it's not the point but his audio synthesis sounds terrible, and that makes me feel like nit-picking:
- 8-bits at 20 kHz really?
- He's actually specifying 20480 Hz in the code, so it's not in tune
- He's using the range 255, but it's 8 bits _signed_ so it should be 127, so he's getting lots of distortion.
His wav header should be:
and then in the synthesis:No. My monitor here works up to 85 hz, a lot of LCD screen out there are capped at 75 hz. By limiting the framerate to 60 hz on a 75 hz screen you'll force it to look inferior to 60 fps because of duplicated frames (20% of them). It may actually matter in a game.
X.platform > X.browser