What's with the negativity in here? This is a slide deck that was used by speakers at Google IO in 2011 to present a session about HTML5. They figured it may be useful so they shared it online so attendees and people who couldn't make it could see and play with the slides afterwards. It makes no sense to criticize these slides for not working in Firefox, Opera, on mobiles, or any other use case for which they were not developed. It's a slide deck. Be glad these guys felt like sharing their knowledge with you.
It's a set of slides about HTML5 written in HTML5. The slides not working properly on mobile devices with no fallback for non-webkit browsers show that the developers are either
a. Lazy
b. Incompetent, or
c. Used proprietary webkit technology,
none of which will inspire much confidence in the actual contents of slides (which I can't read anyway, since I'm on Opera Mobile)
They have a presentation about what's coming in HTML5 at a Google dev con and you are surprised they didn't go to the effort to make it work in browsers that, at the time, may not have even supported these features?
That's such sites which tip you as why HTML5 is not the synonymous of "proper, standard HTML implementation" anymore.
"You are running a Mozilla browser. While such browsers generally have excellent support for HTML5 features, this presentation has only been tested using WebKit browsers"
Exactly. What you mean here is webkit-HTML.
A big part of HTML5 is "we're saying this is going to be an HTML5 API and thats it".
For example, Firefox and Chrome have different Audio APIs. How that's standard?
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:
> For example, Firefox and Chrome have different Audio APIs. How that's standard?
This came about because both browsers implemented an experimental audio API to start discussion on what an audio API should look like. Since then a W3C group has been pounding out a standard API and browsers are working towards it.
If I recall correctly, the standards process itself requires multiple competing implementations for a single one to be chosen as a standard. Having multiple versions of a feature or API is therefore a "good thing" for getting new HTML5 features approved as part of the standard.
If you used this many gratuitous visual effects in a Power Point presentation I'd think you were an idiot with no sense of taste, but because it's being rendered in a web browser I think this is impressive for some reason.
The mobile browsers should allow to use the keyboard anytime and just send the events to the current focused DOM tag like any desktop browser does. Maybe as an another option in the browser menu.
I think everyone should keep in mind that this presentation was (seemingly) created in 2011, so a couple things might be out of date (e.g. BlobBuilder is now deprecated).
I am on the verge of breaking ground on a large-scale corporate project in which WPF/XAML is the tech of choice for UI. I have received criticism for even suggesting that HTML5 is "up to the job" but I feel like this completely validates my point.
Gah, I would pay HN monthly if someone tagged all such links [Best Viewed in Chrome-only] instead of me clicking through and fiddling with various things. As an Opera user, such kind of links are very prevalent on HN.
Or maybe it was just my fault for clicking on something with "HTML5" in the title.
[+] [-] primigenus|13 years ago|reply
[+] [-] mediumdeviation|13 years ago|reply
a. Lazy b. Incompetent, or c. Used proprietary webkit technology,
none of which will inspire much confidence in the actual contents of slides (which I can't read anyway, since I'm on Opera Mobile)
[+] [-] krzyk|13 years ago|reply
[+] [-] Zash|13 years ago|reply
[+] [-] robmcm|13 years ago|reply
[+] [-] indubitably|13 years ago|reply
[+] [-] zobzu|13 years ago|reply
"You are running a Mozilla browser. While such browsers generally have excellent support for HTML5 features, this presentation has only been tested using WebKit browsers"
Exactly. What you mean here is webkit-HTML.
A big part of HTML5 is "we're saying this is going to be an HTML5 API and thats it".
For example, Firefox and Chrome have different Audio APIs. How that's standard?
[+] [-] magicalist|13 years ago|reply
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/
[+] [-] doublec|13 years ago|reply
This came about because both browsers implemented an experimental audio API to start discussion on what an audio API should look like. Since then a W3C group has been pounding out a standard API and browsers are working towards it.
[+] [-] cmwelsh|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] brianwillis|13 years ago|reply
[+] [-] ryanbraganza|13 years ago|reply
[+] [-] ergo14|13 years ago|reply
Web and HTML5 is about standards, and my life would be easier if IE would not do the things it did in past, now I'm seeing the same from Webkit.
[+] [-] vrdabomb5717|13 years ago|reply
[+] [-] hayksaakian|13 years ago|reply
http://www.imgur.com/B19Rk.png
No right arrow key means that even if I can use 2/4 of those html5 features, i can't use your presentation.
[+] [-] hayksaakian|13 years ago|reply
http://imgur.com/CxOVj
[+] [-] jQueryIsAwesome|13 years ago|reply
[+] [-] md224|13 years ago|reply
[+] [-] Tloewald|13 years ago|reply
[+] [-] hcarvalhoalves|13 years ago|reply
https://gist.github.com/4471029
Then you want me to manipulate binary data with an array implementation this crappy?
[+] [-] shimms|13 years ago|reply
https://gist.github.com/4471254
[+] [-] reaclmbs|13 years ago|reply
Two different instances are not equal to each other
[+] [-] debacle|13 years ago|reply
[+] [-] acron0|13 years ago|reply
[+] [-] huhtenberg|13 years ago|reply
[+] [-] ck2|13 years ago|reply
Firefox ran it just fine.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] bestest|13 years ago|reply
[+] [-] est|13 years ago|reply
[+] [-] recoiledsnake|13 years ago|reply
Or maybe it was just my fault for clicking on something with "HTML5" in the title.
[+] [-] Roybatty|13 years ago|reply
[+] [-] lob4tt|13 years ago|reply
[deleted]