HTML5Wow(htmlfivewow.com)
htmlfivewow.com
HTML5Wow
http://www.htmlfivewow.com/slide1
19 comments
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)
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)
first line of the deck clearly states, "If using Google Chrome, you will likely need the Dev channel to see all of the functionality in this presentation," which i take to mean, "if you're not using a fresh Chrome beta, this isn't going to work so well for you."
What is proprietary webkit technology?
It works on my Firefox (19.0a2) almost without errors.
The only one I see is not working correctly back button.
You are running a Mozilla browser. [...], this presentation has only been tested using WebKit browsers such as Google Chrome or Safari.
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?
Seriously. Google is doing what it can to snuff out Firefox.
They do it to Opera as well. Pretty much trying to bully out anyone they can in browsers. I get annoyed at their excessive "try Chrome" popups on websites as well. I don't care what browser anyone uses, but trying to push one's browser as the "one and only true faith" on every major service they provide is annoying.
With everything having full acid compliance and keeping up with modern day features, there's very few reasons not to support the most current browsers out there, especially when you're a company as large as google. Granted this site is using things like filesystem API[1] that only Webkit has so far I believe so it kind of comes down to "showing off the bleeding edge" in this case.
[1] http://caniuse.com/filesystem
With everything having full acid compliance and keeping up with modern day features, there's very few reasons not to support the most current browsers out there, especially when you're a company as large as google. Granted this site is using things like filesystem API[1] that only Webkit has so far I believe so it kind of comes down to "showing off the bleeding edge" in this case.
[1] http://caniuse.com/filesystem
Such as funding them with millions of dollars for their default search engine deal?
And then regularly threatening to remove that funding as they developed competing technology.
Google is not Mozilla's friend.
Google is not Mozilla's friend.
Huh? Google is not doing charity by paying Mozilla, the GP is off base there; they have a contract with Mozilla for getting to be the default search provider. There's nothing to threaten with. But maybe you're privy to some secret contract negotiations the rest of the world isn't?
Besides, there's a reason Google pays so much for that slot: there are others willing to pay a lot for it as well, and even more competitors if Mozilla is willing to take a smaller payment for it.
Besides, there's a reason Google pays so much for that slot: there are others willing to pay a lot for it as well, and even more competitors if Mozilla is willing to take a smaller payment for it.
Funding? Really? What about "paying", instead?
How much would Microsoft pay for Bing to be the default search in Firefox? Would be close to what Google pays, but it's likely to be much much more.
How much would Microsoft pay for Bing to be the default search in Firefox? Would be close to what Google pays, but it's likely to be much much more.
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?
"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:
http://lists.w3.org/Archives/Public/public-audio/
http://www.w3.org/TR/webaudio/
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.
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...
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.
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.
> 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.
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.
[deleted]
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.
Personally, I think a lot of it is impressive, but the cube animation gets old really fast.
A HTML5 presentation that works only in Webkit.
No thanks, I am not interested.
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.
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.
It only seems to work on Chrome right now. Safari doesn't support the FileSystem API, so it doesn't seem like even Webkit's enough.
I'm pretty sure some of it is broken in all browsers now because the specs for these APIs have all changed.
Nope
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.
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.
And on my netbook, I don't even see the arrow prompt because the page is too large by default. I have to zoom out.
http://imgur.com/CxOVj
http://imgur.com/CxOVj
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).
Apparently to experience the wow i need to hit a cursor key.
Everything looks great, other than the fact I'm still forced to use a broken language to interact with shiny new APIs:
https://gist.github.com/4471029
Then you want me to manipulate binary data with an array implementation this crappy?
https://gist.github.com/4471029
Then you want me to manipulate binary data with an array implementation this crappy?
So it uses lexicographic sort by default, just pass a custom comparator no?
https://gist.github.com/4471254
https://gist.github.com/4471254
or if he doesn't even feel like passing a custom comparator every time and just wants to default to increasing numerical order:
(function(){var a=function(a,b){return a>b},b=Array.prototype.sort;Array.prototype.sort=function(){return b.call(this,a)}})();
(function(){var a=function(a,b){return a>b},b=Array.prototype.sort;Array.prototype.sort=function(){return b.call(this,a)}})();
I'm aware of the solution. What I'm disputing is why sort does the least obvious, stupidest thing I can think about by default - specially since numerical is equivalent to alphabetical for the ASCII set.
Arrays in JavaScript are instances of the Array object
Two different instances are not equal to each other
Two different instances are not equal to each other
Yes, I get the idiossincracies. Triple equal operator also returns false.
What I don't get is how is it acceptable this language has the largest installed base in the world and you have to write boilerplate just to equality test two arrays.
What I don't get is how is it acceptable this language has the largest installed base in the world and you have to write boilerplate just to equality test two arrays.
> how is it acceptable?
Because developers feel that it is and have done so in past. Because things that required and unavailable have been put down in libraries that developers can import and utilize. Because there are many libraries that compete against each other to provide better interfaces for their users. Because they are used very widely and very successfully. Because it's simplicity has made it usable among the masses who may not have otherwise participated in content creation on the web if CS101 was a requirement. Because its benefits have outweighed its faults. Because when people suggest alternatives (Dart?) they realize that they need to make them compatible with JS because it is not only popular but also quite efficient now.
Google is doing the Internet no favors in trying to out-douche Microsoft in the web browser arena.
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.
You'd feel differently, if you'd see how slow this presentation runs on my super-duper (seriously) laptop.
I hate that we are back to the days of "works best on xyz"
Firefox ran it just fine.
Firefox ran it just fine.
[deleted]
[deleted]
"press → to move on"? Seriously? I want to use my mouse.
it seems that javascript now has global variables
PERSISTENT = 1
TEMPORARY = 0Gah, 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.
Or maybe it was just my fault for clicking on something with "HTML5" in the title.
So is WebGL part of HTML 5 because Mozilla and Google are implementing it? Would Google Native Client https://developers.google.com/native-client/overview be part of "HTML5" if Mozilla was implementing it?