Tip:
Highlight text to annotate it
X
>>Arne Roomann-Kurrik: All right. Welcome to HTML Showcase for Web Developers. Or as
we like to call it, the wow! >>Eric Bidelman: And the how!
>>Arne Roomann-Kurrik: My name is Arne Roomann-Kurrik. This is my friend, Eric Bidelman. And we are
Chrome developer relations, and what means is we wander the Earth like the Incredible
Hulk and help out developers who are writing apps, extensions, and websites for Chrome.
So basically, what we do is talk about HTML5 a lot.
You can see our Twitter handles were up there. Oh, actually let's go back there.
>>Eric Bidelman: Sure. >>Arne Roomann-Kurrik: Our Twitter handles
are actually up here. Follow us if you want. I like to post updates about Chrome Extension
APIs and kind of updates to Chrome. Eric likes to post pictures of cupcakes, furry animals
with moustaches, that kind of thing. Whatever floats your boat.
So a year ago, I was actually up on a stage at Google I/O and talking about HTML5, and
back then it wasn't kind of like the huge buzzword that it is today. It wasn't so overused.
We talked about a lot of different technologies, and if you were lucky enough to get a seat,
you learned about canvas elements, audio elements, video elements, local storage, Web SQL database,
worker threads, drag and drop events, desktop notifications, new CSS styles, CSS transforms,
CSS transitions, CSS animations, maybe hotel/restaurant management, web fonts, flexible box model,
and some of you got your associate degree in building a paint application or accounting.
In all seriousness, we're just kind of doing this to emphasize we covered a lot last year.
The video is still online. It's a great resource, if you followed that bit.ly link, bit.ly/HTML5io2011
you can actually see it and give kind of a ramp-up on this.
So -- but today we're not going to really do that. We're not going to cover the basics.
In fact, we just want to show you some demos. I'm betting these demos are actually going
to make you say some amazing things. What are they going to make you say, Eric?
>>Eric Bidelman: Wow! >>Arne Roomann-Kurrik: Yes, they're going
to make you say wow. >>Eric Bidelman: Hopefully.
>>Arne Roomann-Kurrik: Hopefully. We're not there yet.
>>Eric Bidelman: So we're also going to -- like Arne said, we built these demos, but these
are complex demos. These are a lot of HTML5 capabilities working together. And this whole
entire slide deck -- right? -- HTML5 app, all the code is going to be under HTML5wow.googlecode.com.
All the demos, all the slide deck. I just want to mention there's feedback links.
There's Twitter handles at the bottom. There's a Moderator link. If you have questions during
the entire presentation, go ahead and reference those.
>>Arne Roomann-Kurrik: Yeah. That feedback link is live right now. You can give us feedback
on certain points in the presentation, that kind of thing, so we'd really appreciate it
if you took the time to kind of rate us and how we're doing.
>>Eric Bidelman: Yeah. >>Arne Roomann-Kurrik: Okay. So today we have
three topics in our presentation. We're going to break it down. Basically we found different
categories that would work out for us. So file, graphics, audio.
But without really going too deep into that, let's start with the first one.
Eric, I'm going to hand it over to you to talk about file APIs and HTML.
>>Arne Roomann-Kurrik: Absolutely. Thank you, Arne.
So let's talk a little bit -- before we dive into the file capabilities of HTML5, let's
talk about binary data in HTML5, because the sad -- the truth of the matter is, we're dealing
with binary data all the time, right? Web applications, music applications, photo applications.
And so it was very, very painful before. This is a little snippet. I call this black
magic. You can call this a hacker trick. But what we had to do to pull down an image as
a binary file was use HTML XTP requests, right? HTML XTP requests. And then have this little
override mime type. Arne is going to highlight certain sections of code.
Set up the mime type, the text plain, user defined char set. This is well-documented.
We've been doing this all over the place. And then inside of the ready state change
-- right? -- we process the response text just as a binary string and do some crazy
character code manipulations, hacks, streaming manipulation. Stuff that's hard and it's very
error prone and luckily with HTML5 we have better tools now.
So we're going to cover a few different topics, so how do you import data? How do you import
files into your application and then do something useful with them? You don't have to import;
you can create. So there's interfaces now in HTML5 that you can use to create binary
data on the fly. Manipulate existing data. So this is actually
a new data type that we can use to manipulate this data.
We can store that data. IndexedDB, file system APIs, we're going to cover those.
And then publish that back out to the cloud. So XHR, you don't have to just send strings
anymore. You can send files, you can send array buffers, you can send form data types.
So binary data hearts HTML5. I'm not going to cover typed arrays today,
but these are very important. These are -- were introduced by the WebGL specification, and
these are a very more performant. They're going to be used to work with binary data,
file types. We're using them all over the place within the presentation.
And so what the browsers can do is optimize based on your data type. So you have an 8-bit
array, you have a 32-bit float array. These are all over now.
So I don't know about you, Arne, but if you remember the snippet before -- right? -- we
did the character code hacks with XHR. This looks much cleaner, right?
>>Arne Roomann-Kurrik: Let's really good. >>Eric Bidelman: Yeah. So I want to point
out a couple portions of this. XHR has been extended and the first thing
-- the way it's been extended is the response type. We don't have to pull down our data
from the server anymore as a string. We can say, "Hey, give me an array buffer, give me
a buffer of bytes that I can process as this response type."
We don't have to listen for the on-ready state and do this, you know, crazy state checking.
We can just listen for the on-load. Give me the data when it's done.
And here's a great example of doing a typed array, so an unsigned 8-bit array we're using
and just filling that array with our response. And we're not processing the response text;
we're processing a new attribute, the response, and that's going to give us this blob, this
image, as a binary file. And then you can manipulate that just as a
JavaScript array, which is really cool. So that's the new hotness.
Let's -- let's -- without further ado, let's dive into the file capabilities.
So the first might not -- I mean, look right. This is our old friend. This is the file input.
But the really important and cool portion of this is that one attribute that Arne is
going to highlight at the end, the multiple attribute.
So if you've ever created a photo application -- right? -- an upload application, you've
had to probably instantiate a bunch of these inputs in JavaScript and then send files,
your photos, one at a time. So instead, we have a little demo of this.
This is just a file input that Arne's going to run, and what Chrome is going to allow
him to do with this attribute, just one attribute, is select multiple files, not just a single
file. So he's going to select a bunch of image files.
Apologies that it's so close to lunch. And what you get back is a file list. You
get basically an array of file objects that you interface in HTML5 with metadata. So what
is the name of this file? What's the mime type? How many bytes does it take up on disk?
When was it last modified? This is really great stuff in order to do
some preprocessing or some interesting applications before you send your code to the server.
And the code for this -- right? -- I'm just setting up an event listener on the input
and you get back -- in the target of this event, we'll get a files list, and this is
the list of files, and then we'll just loop through those and present the metadata to
the user. It's very straightforward but very cool.
Of course it's not just files. We can actually select now directories using the same file
inputs. So with the Webkit directory attribute, Chrome is going to allow us not to select
files, but an entire folder, and Arne is going to demo this, if he backs out of this folder.
Chrome's going to recursively traverse this folder and give us a file for each of the
files, and see at the bottom here -- I'm just printing out that Webkit relative path so
that's also a property in this file object. And we're printing out the files as they appear
within this folder hierarchy that he's selected. You can see there's a few folders within this
folder. Of course that's cool but we can also use,
you know, a little bit of string manipulation, a little bit of JSON, and a jQuery plug-in
to present that as a sort of a file hierarchy and a tree structure, and so he's just navigating.
This is the exact folder that he selected as it was appearing on disk. Cool.
Very exciting stuff. So you can upload an entire folder now.
You can import using a file input. That's our old friend. You can also use drag and
drop. So HTML5 has -- has native -- native drag and drop capabilities now. And so Arne
is selecting image files -- right? -- from my hard disk and he's just going to drag these
onto the Web application using HTML5 drag and drop. Chrome allows this.
And at the bottom there, we just -- we read the image files as data URLs and then we just
set an image source tag, applied some nice CSS transitions, transformations, pretty cool
photo gallery there. But the code for that -- right? -- a couple of lines and we have
the ability to actually import files into our app using drag and drop.
Nice. Okay. So let's see all this sort of working together.
So this is soon to be a photo gallery application, and what we've done here is I'm going to describe
this and Arne's going to sort of drive it. Basically what he did, if you want to run
that one more time Arne, this is going to send an XHR. It's going to pull down a zipped
file, all in the client. It's going to uncompress that zipped file and then read the image using
-- >> We are now activating 400,000 devices on
a daily I see. >>Eric BidelmanThis is using typed arrays
and some of the new capabilities of XHR, and then of course we applied some CSS transitions
and transformations here to present the photo gallery. I'm getting hungry.
>> Last year at Google I/O, we announced we were adding 100,000 users on a daily basis
-- >>Arne Roomann-Kurrik: I guess we're competing
for your attention. Sorry about that. >>Eric Bidelman: So just to show you what's
happening, that's an HTML5 progress bar that we're updating. That's a new tag as well and
then we're unzipping the file. You can see the uncompressed output there.
So the blueprint for the photo gallery, you know, not too complex. There's -- there's
the XHR stuff. There's a Webworker that's doing the decompression. I'm not going to
go into the code of it, but again, it's going to be available on that project page. We'll
show you that link again at the end. All right.
So that's importing files. That's how you get binary information into your application.
Now, how can we use it? What can we do with those files? We saw the metadata. Of course,
there is the flower reader object. This is going to give us the ability to asynchronously
read the file into memory. You instantiate a new file reader object.
You can pick your poison. You can read it as a binary string. You can read it as a data
URL. These are really handy. Read the text file. Or just give me the raw bytes, pull
up an array buffer. You are passing the file object through the
blob, and that's the same one you got from the drag-and-drop event, the same way you
got from the file input. At the bottom here, we can see that we can
actually slice and dice this file. A good example would be something like Gmail, right?
You have this huge attachment. You don't want to just send one request. You can cut this
file up into multiple chunks and spawn off multiple AJAX requests and then put the file
together back on the server. A lot of really cool options for you.
Of course, we don't have to just read the file. We just want to use the file, right?
We can use the data URL. Most of you are probably familiar with data URLs. Not going to cover
them too deeply. The basic format is data colon. You can construct
these on the fly. The MIME type and then we'll Base 64 encode the content, the string content.
If you use the file reader object as a string, a binary string, you can use this and present
it to the users. >>Arne Roomann-Kurrik: What's this function?
>>Eric Bidelman: BTOA is the new method that's been implemented to basically encode string
data. You don't have to use a library anymore. That's great.
I just want to point out. Arne just opened a link, and what he opened is a data URL.
We haven't Base 64 encoded it. You don't need to Base 64 encode the content. If it is not
binary, you don't have to. He opened up a text HTML data URL, and it
is basically a text area with some styling, with a placeholder, a border radius, right?
And we constructed a cloud IDE on the fly. See if your code compiles.
>>Arne Roomann-Kurrik: Yes! >>Eric Bidelman: Nice! That was a link he
opened in the browser. You can share data URLs. I can email him this data URL. He can
open it in his browser. So they are persistent. One less network. That's great.
The downside, though, is a 30% overhead. So if you have binary content in a large file,
you're Base 64 encoding that, you will have some overhead.
However, the create object URLs, blob URLs are something new to the Web platform as well.
Basically, there is this new method, window.URL.createobjectURL. You path the file object. This is the same
file object you got from the input file type, from the drag and drop. And then you call
this. It will create this blob URL. The scheme for that is sort of blob -- the
origin of your application and then this random hash that the browser, Chrome creates.
I can't share this link. I can't send a blob URL to Arne because his browser is not going
to understand that. This is generated by my browser.
I just want to point out, if you want to bring up the About page for this, there is some
really handy pages in About About. These are all Chrome's About pages. And there is one
for blob internals. These are all the blob URLs that we're creating.
We are actually using these all over the place in this presentation. You are actually instantiating
a memory reference every time you do this. There is a revoke object URL, be sure to call.
So this doesn't come for free. But you can remove them on the fly. That's pretty cool.
So they are temporary. They are a handle to the content. They are not "the" content, a
data URL in the content itself. These are just a handle. You can use these as a source
attribute. You can use them as an HR attribute all over the place just to use the file. Very,
very handy. So a really neat example of using a blob URL is the inline Web worker. Normally,
right, you instantiate a Web worker with an external JavaScript file that has all your
worker code in it. What we can do instead is inline our script
tag, our code inside of the main application and it will just use -- instead of text JavaScript,
we'll use JavaScript Worker or any other MIME type as long as the browser is not going to
parse that as a script lock. So there is our worker code. At the bottom, in our main application,
we use the blob builder API. The blob builder is going to allow us to create blob data,
basically a file on the fly. We will pen the inner text of the script tag inside of that
blob builder and then we will call our work by creating a object URL. We will pass this
handle to this file we just created instead of referencing an external JavaScript. Very
cool example of using the blob URL. So what's the support for this? Actually pretty
good. All the file APIs, Safari, FireFox, Chrome, you can see IE and Opera are sort
of semitransparent. That's because they have both announced at various levels support.
IE9 has a lab, and then Opera has announced recently that they will support a lot of these
files APIs, too, in their next release. All right. That's importing files. That's
getting stuff in. That's manipulating it. Now what can we do with it? We can do store
it using a FileSystem API. This is a random API in Chrome that we have implemented. It
allows you to do read-write access to folders, files, on this Sandbox FileSystem. There is
a new property -- call that you can make, request FileSystem. And you pass it persistent
storage or temporary storage based on your application's needs, the size of your expected
sort of Sandbox that you are creating. The API is asynchronous, so you are passing callbacks
all over the place and passing a success in most cases and then an error callback in case
something goes wrong. Really easy to open this sort of read-write access in Chrome.
Of course, once you have this open, a good thing to do would be open a file or create
a file. You can obviously fetch a file. It will create this logfile, for example.
So in our callback -- in our success callback, we will get this FS, this root object. This
is just a directory object representing this sort of hierarchy of our FileSystem we are
interacting with. We pass the file name, logfile. This options parameter will be create. So
we will just create it. It doesn't exist. What we will get back is a file entry object.
The file entry object has various properties on it, so what's the name, what's the full
path in this sort of hierarchy that we're creating. Is it a directory? Is it a file?
The really important one here is the fileentry.file. You can call this method. What you get back
in the callback is actually a file object, the same file object you saw in the input
file, the same one you saw in the drag and drop. This stuff is appearing all over the
place, and there is a lot of interapp between these different APIs now.
Arne is highlighting various other properties you expect from the platform, copy, give me
my parent, move, remove. It is a very powerful API.
I want to just quickly point out that you can write files to you. I'm not going to cover
this code. There is a file writer object that you create.
So once you open this Sandbox file, you create this writer and you can write that file object
to this FileSystem. Without further ado, let's show this stuff in action because I think
it is worth a demo. All right. I introduced you to the HTML5 terminal.
We replicated a shell, basically, in HTML5, thanks to the FileSystem API. We wrapped the
API's calls with familiar UNIX commands. This is just a Web application. Arne can LS. We
have one file in our FileSystem. He can add more. Of course, we can drag and drop. We
are just writing these using the FileWriter API. Let's do an LS again. Boom.
Let's look at some food, Arne. I'm getting hungry.
>>Arne Roomann-Kurrik: Really? >>Eric Bidelman: Yeah.
>>Arne Roomann-Kurrik: Okay. >>Eric Bidelman: We'll open a burger. Delicious.
So this is just opening it up in the browser. We have an Open command. We can cat that file.
We will cat a text file. This is using the FileReader API to read the contents of the
file. [ Beep ]
HTML5 audio. So Arne makes a few mistakes, we can implement a bell sound when he presses
delete. >>Arne Roomann-Kurrik: Just so you know.
>>Eric Bidelman: Yeah. There's theming. We have some basic theming. Let's change it to
cream. Cool. If he presses "refresh," this is using local storage. It will save his theme.
I don't know if you want to save that preference. I like the black personally myself.
What else do we have, Arne? Zoom in a little bit on that.
This is just using CSS3 and replicating a CRT sort of monitor.
[ Laughter ] It is completely superfluous.
>>Arne Roomann-Kurrik: It is the most gratuitous thing I have ever seen.
>>Eric Bidelman: Sometimes you got to take the extra step.
What else? Wget. We can do -- HTML now has the ability to do cross-domain XHRs. We can
pull down html5rocks.com and just read and print the source code to the terminal here.
I think that's it. Is that it. That is HTML5 terminal show. Again, FileSystem
API is working together. A lot of stuff going on. So we install this application as a Chrome
Web store app. That I didn't explain. Web audio API file drag and drop, we'll cover
some of this in a bit. Very cool. Thanks to the FileSystem. That's one, two and three
ways now to generate URLs. You saw Arne when the burger picture opened.
That is using a new URL scheme. That's the FileSystem URL. That goes along with this
API. You have blob URLs. You have data URLs. A third way to use a file directly is a FileSystem
URL. So you can call the fileentry.toURL. Arne is highlighting this. It is the origin
of your application and then sort of the relative path within the Sandbox. You can use it as
an image source, a script source. Very cool. You can take your entire application offline
in the FileSystem. There is a resolve local FileSystem URL call.
So if you have one of these saved file URLs, you can pass it to this method and then it
will give you a file entry object that you can manipulate with the API. So a lot of back
and forth. Cool. So FileSystem APIs, right now only in
Chrome. And this is a particularly exciting API, right? You are going to be storing things
offline. You will be generating binary files in your applications. We open the other browser
vendors will implement this pretty soon. >>Arne Roomann-Kurrik: Eric, you are telling
me with this really advanced API that's coming out and really kind of -- people are working
on it, the best you can do was a terminal that looks like it was from the '70s?
>>Eric Bidelman: We took a step backwards in computer graphics, didn't we?
>>Arne Roomann-Kurrik: Yeah. We really blew the goat on graphics there.
>>Eric Bidelman: Do you have anything that can --
>>Arne Roomann-Kurrik: Yeah, I think I have some stuff prepared. Do you want to jump into
that? >>Eric Bidelman: You do, fantastic. I will
turn it over to Arne. >>Arne Roomann-Kurrik: Yeah, just in case.
I am going to talk about graphics on the Web. When we are talking about the graphics on
the Web, there is a lot of different approaches that you can take to get, basically, the same
effect, which is, basically, drawing something onto the Web page or animating something over
time and making it kind of move. There's three different approaches I like to take when I
think about this. The first is declarative. Just tell the browser what to do and then
it does all the heavy lifting for you. Otherwise, I could script things. I could actually do
the drawing myself and do, like, animation frames and that kind of thing. Or there's
even low-level access to hardware. And we'll talk more about those.
But, you know, starting with declare -- declarative approaches, when I say "declarative" on the
Web, most people think CSS. I just want to kind of talk about SVG for a second here.
SVG, if you are not familiar it, is a vector file format that's kind of specified using
XML. What this lets you do is to draw lines and
shapes and fills and use styling and all that stuff in a way that actually is, first of
all, human kind of readable, human constructable and, then second of all, scales with resolution.
So if you actually show this path that I'm kind of running here and you can actually
see on the right, we have a raster version of that same path.
You can see there is a quality difference between the browser kind of rendering in SVG
because it is using vector scaled up to a larger resolution versus a bitmap which is
just pixels and kind of stretched and blurry when we blow it up.
So moving on. SVG has a great kind of property of having its own DOM. So just like the Web
page has its own DOM, the image has its own component elements that you can change and
modify and the browser will do all the rendering. You can see here that Eric is selecting some
text that's been supplied to a path using SVG. That's amazing because we can define
the path and we can define the text and the browser just takes care of all the rendering
for us. The great thing is we can actually wire it up with the text input. And as Eric
is demonstrating right now, we can actually change the image dynamically.
Think about how powerful that is. Nice roller coaster.
Think about how powerful that is if you need to localize "we" into 40 languages or whatever
or if you want screen readers to access the text and the image and so on.
The great thing about this is that this SVG syntax is actually in this page itself. We
are not referencing an external file. The SVG notation is actually part of the HTML5
document that we're loading. You can do that. You can just put SVG tags in and then put
SVG notation in between. But going back to what I mentioned before,
most people think of CSS when we mention declarative stuff. There's so many new features in CSS3,
like, I really can't possibly cover them all in a single presentation, even a section of
them. So here's just a bunch of interesting things.
But we're kind of focusing down here. Let's talk about one of my favorites, the animation
key frames tab. And you can see here that we have a spinning Chrome logo. And the way
we've defined that is actually having this new key frames notation. We specify a "from"
state and "to" state. And then when we want to apply that animation to an object from
the DOM, we just basically say which animation, how long is it going to take, how many times
do you want to do it. And then we have this kind of cubic bezier function here which lets
you specify how the animation behaves. This is really great because it shows you how powerful
the declarative approach really is. Why don't we kind of open a little bit more
into that. What we have here is a little tool that we've kind of done to represent the timing
function. Eric, why don't you load the linear timing
function right now. >>Eric Bidelman: Sure.
>>Arne Roomann-Kurrik: There are some presets that are available as part of the spec. You
can see here that the linear kind of just rotates the circle at a constant rate.
Now, open up ease-in-out. And if you do that, it will be slow and then
fast and then slow again. So again, you have these presets that let
you kind of dictate how animation works. If you're familiar -- well, if you've been watching
the slides, you've actually seen the rotation that we've been doing, and that's all done
using this kind of -- this kind of syntax, so it kind of has a little bit of a shape
to it. Of course you can specify custom points, so
Eric here is kind of defining a custom animation. It looks very strange. I don't know if anyone
would ever use that. >>Eric Bidelman: I'm using that in my next
app. That one right there. >>Arne Roomann-Kurrik: Okay. But again, just
to show you how the -- as you define the custom function, you can actually get a wide range
of different animations just out of a declarative approach. Looks like you're having a lot of
fun there. >>Eric Bidelman: Yeah. Sorry, we'll move on.
>>Arne Roomann-Kurrik: Okay. So another kind of unsung hero of, you know, new CSS stuff,
I think, is 3D transforms, and we really like this because, you know, hardware acceleration
is now being like featured prominently in some more browsers and we're really getting
some interesting stuff out of it. And you see that the slides themselves have
a 3D effect to them, and we're doing that all in CSS.
So just to show you how that kind of works, we have two nested elements here. We have
a green box surrounded by a blue box, and as Eric is showing, you can just select the
number inside of it. It's just DOM, you know, divs, and if you move -- if you actually activate
the next sample, what we're doing is we're actually rotating the green box out 45 degrees
along the x-axis. Now, the x-axis being, you know, from left
to right. You can actually rotate out on that plain, and by applying a CSS transform.
Now, what we're going to do is rotate the parent element, and we actually rotate it
along the y-axis, so it rotates kind of away from, you know, the viewer. And what's interesting
about that third example is that it's not popping out of the parent like you would expect
it to. Looking at the second element, if you saw that rotated out, you would expect that
to kind of have its own coordinate space. And the reason for that is that by default,
CSS kind of maps the 3D transform against the flat plain of its parent element. But
you can break that. You can actually construct models and objects in 3D by applying this
preserve 3D transform style onto the object itself.
So it lets you create 3D models using CSS notation, which is fantastic. It lets you
do some really cool stuff. Let's put some -- some of this together.
So we have our old friend, the spinny Chrome logo guy, and what we're going to do is build
up a DOM. So we have a container element and we're rotating that on its own axis, so along
the y-axis, kind of slowly. And then we're going to start putting panels
into that DOM. And those panels are each rotated 90 degrees off of each other.
So you can see here, as Eric kind of unhides them, they're actually building up a model
in 3D space that's rotating around this Chrome logo that's in the center of that container.
And so they all get the inherited rotation of their parent element, and all we have to
do is really just specify, you know, how they interact with each other in space.
Now, it would be really cool if we could do some interactivity in this model. So the same
way that you would take a hover state for maybe a link, an anchor link, we can actually
have a hover state for each of these DOM elements, and then we apply a transition between them,
you know, which tells the browser just if you ever change one of these properties, just
animate it linearly, or whatever. Then we can actually have a fully interactive model
that's defined entirely in CSS. There's not a single line of JavaScript running this demo
right now. That's really powerful. You just kind of define the constraints and the browser
takes care of all the rest. So let's move on.
Of course sometimes you do really just want to script something. Sometimes you just want
to draw something. So we have the canvas element.
And this is kind of like an image tag that gives you a JavaScript API that you can draw
into. And you can do some really cool stuff. Like, for example, what we're doing here is
just drawing kind of the state of the model that we're running, and then we're clearing
it, and then we're drawing it again and incrementing the model itself.
So we're getting an animation because we're just drawing a bunch of frames. Yeah, you
can move on. >>Eric Bidelman: All right.
>>Arne Roomann-Kurrik: So -- but what do we do when we're doing animation?
Well, we would normally just have a loop running. We'd use this -- probably one of my least
favorite JavaScript calls, window.set timeout, and we'd be calling the draw function over
and over again. And the reason why like window.set timeout -- well, one of the reasons -- is
that you specify milliseconds onto this function. We have 10 here, and you can see that the
animation is actually only running at about 20 milliseconds.
So, first of all, it lies to us. You know, this is the most untrustworthy function because
it doesn't actually get called when we ask it to. Second of all, I don't like it because
most people do drawing inside of it, but the browser doesn't know that we're doing drawing.
So what happened is some really smart folks decided that they wanted a new function that
would be specific to animation and they introduced the request animation frame function call.
And why don't you switch over to the new hotness right now.
>>Eric Bidelman: New hotness! Wait a second. Nothing changed.
>>Arne Roomann-Kurrik: Yeah. That's a very good observation, Eric.
>>Eric Bidelman: Yeah. >>Arne Roomann-Kurrik: This is actually because
it kind of behaves the way that set timeout was demonstrating, but now we have a contract
with the browser, and the contract is: Only call us when you want to draw something.
So when the browser's ready to draw, it calls us and then we do our little update and we
say how many milliseconds it's been and then, you know, we move on. So we're happy with
that. But let me show you how the browser can optimize
this a little bit. So Eric's going to kind of pull out of full-screen
mode here. He's going to open up a new tab. And what we have is the title of the existing
tab kind of updating in time as the animation frame call is happening.
So if you zoom in there, open up a new tab and focus it.
Okay. So this call has actually been frozen and
the reason for that is because the browser knows that we're doing animation in that callback,
and it doesn't bother calling it when the page that we're trying to do the animation
on is not visible. This is really powerful for things like mobile
devices, items with limited CPU that might want to run multiple demos, maybe even battery
life, that kind of thing. So why don't you go back and show them what
happens when you use the old approach. So we're just going to switch back, again,
using windows set timeout. Remember that we're requesting 10-millisecond updates. We're not
getting that. But then when you open up a new tab, it still updates.
Now, Chrome is actually really efficient in this case. It understands that the tab in
the background might not need to be updated as often. So it actually slows down the interval,
the max -- or the minimum interval for windows.set timeout when the tab is not active but you
can still it's still being called. And that's once a second that you might be drawing a
complex 3D model or something like that. So again, the request animation frame just
kind of helps us have a contract with the browser and really just kind of enforce that
contract and allow it to optimize itself further. So moving on, you have this canvas API, you
have this request animation frame, and then you have this great draw image function.
This isn't really anything special, but what I really like about it, what a lot of people
don't kind of realize, is that you can draw anything from any kind of image element, including
images, other canvas elements, or even web video, HTML5 video, into a canvas, and you
can actually do things like draw sections of an image.
So you only need to load one image if you're doing an animation function.
You can see here that we have a whole sprite sheet, and what we're doing is we wrote a
little bit of a game that's just kind of animating it and drawing it over and over again.
Just to show you how responsive this is, Eric is kind of drawing with his mouse this terrain.
Little Chrome man here is jumping up and down. Oh, you're giving him a hard time, man.
>>Eric Bidelman: He can use a workout. >>Arne Roomann-Kurrik: Okay. But just to show
you again how powerful the canvas APIs can be, how performant they can be, why don't
you click on that background a little bit. Kind of scroll down.
You can see we're drawing a full motion video directly into this and we're still maintaining
that same fluid frame rate and it's all done in JavaScript, all done using the canvas tags,
but it just looks really cool and there's a lot of potential there to do things like
2D games. Of course, you know, the last time I played
a 2D game was a while ago. >>Eric Bidelman: Yeah.
>>Arne Roomann-Kurrik: Oh, no, that's not true. I played Angry Birds the other day.
[Laughter] But, you know, kids like the 3D now. I'm sure
we'll see something in the future like 3D something.
>>Eric Bidelman: TVs? >>Arne Roomann-Kurrik: TVs. Yeah.
But, yeah, so we have 3D support in the browser now, because the kids like 3D.
So anyway, Eric, I think we have a demo of what the future of 3D in the browser is.
>>Eric Bidelman: I think we do. >>Arne Roomann-Kurrik: Any of you guys who
might have gotten lucky enough to have some glasses --
>>Eric Bidelman: Now is the time, if you were lucky enough to score some glasses.
>>Arne Roomann-Kurrik: You know, every time I go to the theater now, I need to put on
these glasses, so we just figured Chrome is just going to support that as well.
>>Eric Bidelman: Absolutely. >>Arne Roomann-Kurrik: All right. Eric, activate
the demo. >>Eric Bidelman: Yeah. Activating demo.
>>Arne Roomann-Kurrik: Okay. And now activate the motion controller.
>>Eric Bidelman: Activating motion controller. >>Arne Roomann-Kurrik: Oh, yeah. Yeah. This
is -- welcome to the future of 3D in the browser. >>Eric Bidelman: Ooooh.
>>Arne Roomann-Kurrik: Ooooh. Ahhhh. No, I'm just kidding.
This is actually not the future of 3D in the browser. We're actually just demoing another
input event right now. Just kind of threw it in there. It's the device orientation event
handler, and this just lets you kind of just have, you know, any sort of piece of hardware
that's running your browser, like a mobile device -- in this case, a Macbook which has
a tilt sensor in it -- can actually send events into your DOM page. So you can use this for,
you know, more game inputs or things like that. Really cool with animation, really cool
when you're running models like this. Hopefully you guys are seeing some 3D effect
there. But we actually do have a real 3D support,
we don't need glasses for it, and we're calling it WebGL.
And this is a variant on OpenGL -- Actually OpenGL ES 2 -- which is the same sort of technology
that you'd use to program 3D in like a mobile browser or tablet. And you can run this directly
in the browser, as you saw in the keynote today.
So again, just show them how dynamic that model is.
And we're responding to DOM events because WebGL is actually scripted through JavaScript
so we can take advantage of all the DOM kind of event model and all that stuff to have
input into our games or simulations or whatever. And you can see up here the code snippet is
actually a WebGL shader which runs on the GPU itself.
So it gets uploaded to the GPU and it runs on hardware. So you can see it's very fluid,
it's very dynamic. You know, this isn't the greatest demo, so let's -- let's see a little
bit of a better one. >>Eric Bidelman: Absolutely.
>>Arne Roomann-Kurrik: You can see here that we're taking a Chrome logo and we're just
deforming the hell out of it, and, yeah, as Eric is kind of pushing those pixels around,
keep in mind that this is running on the GPU of the Macbook itself, and we're kind of getting
this really cool animation, really cool visualization. Again, just using that power of JavaScript
and hardware shaders. So again, we saw a really cool demo in the
keynote of WebGL. Don't really need to spend too much more time on it.
Probably a little bit too complex to go into here.
So why don't we see if we can maybe improve the command line a little bit.
>>Eric Bidelman: Okay. Let's take a look at that again.
>>Arne Roomann-Kurrik: Okay. So, yeah. Is there any command we can run to kind of give
it a little bit more style? >>Eric Bidelman: Uh... there's a 3D demand.
>>Arne Roomann-Kurrik: Yes, I like that. >>Eric Bidelman: We can try that one.
Let me run a special populate command first. Let's try 3D. Hold onto your butts!
[Laughter] >>Arne Roomann-Kurrik: This is UDIX. I know
this. Whoa! [Applause]
>>Arne Roomann-Kurrik: Whoa. This is awesome. >>Eric Bidelman: Arne and are big movie fans,
if you can't tell. So, yeah, yeah. You want to explain what's
going on here? >>Arne Roomann-KurrikYeah. Actually, I'm getting
a total vibe that this looks like two web applications communicating via window.post
message and sending messages back and forth. >>Eric Bidelman: Sounds like somebody built
this. [Laughter]
>>Arne Roomann-Kurrik: Actually, yeah. So I think that's exactly what we're doing here.
We have the same terminal application. We have a WebGL simulation programmed by Ilmari,
one of our awesome coworkers, and what we're doing is we're actually just sending window.post
messages back and forth between the I-frames that are kind of running each of these demos.
You can see here that the simulation is WebGL. It's running really fast. It's dynamic. It's
responding to Eric kind of doing some -- oh, looks like you're in your home directory.
>>Eric Bidelman: Oh, my cupcakes. >>Arne Roomann-Kurrik: We found his secret
stash. Yeah. That's really cool. But, yeah, very dynamic, very smooth and fluid.
>>Eric Bidelman: Wait. But, Arne, there is a curious top secret directory in your user
directory. >>Arne Roomann-Kurrik: Oh, what's in there.
>>Eric Bidelman: It says "HTML4 rocks." >>Arne Roomann-Kurrik: Oh, no, no, no, no.
Delete that, delete that. >>Eric Bidelman: All right. Let me get that.
>>Arne Roomann-Kurrik: Yeah. We don't want that. They told us to get rid of confidential
stuff in the -- >>Eric Bidelman: You know, it's not letting
me for some reason. >>Arne Roomann-Kurrik: Oh, I know this. This
is UNIX so use pseudo. >>Eric Bidelman: Okay. Let me try that.
>>Arne Roomann-Kurrik: Oh, no, o. Close it, close it. Shut it down, shut it down.
>>Eric Bidelman: Oh, shutting down, shutting down, shutting down.
[Laughter] >>Arne Roomann-Kurrik: Yeah. So we, again,
have a blueprint here. "Image is broken." But anyway.
>>Eric Bidelman: The blueprint is top secret. >>Arne Roomann-Kurrik: We use window.post
message, WebGL to do the rendering and all that stuff. Now, Eric, you were playing some
interesting -- oh, there we go. >>Eric Bidelman: There it is.
>>Arne Roomann-Kurrik: You were playing some interesting audio at the very end of that.
>>Eric Bidelman: We have an audio section. >>Arne Roomann-Kurrik: Oh, amazing!
>>Eric Bidelman: Yeah. I too have prepared some content.
So yeah, so the whole multimedia story wouldn't be complete without talking about audio, right?
And, you know, many of us probably know HTML5 also is BFF -- best friends -- with audio.
You're seeing a lot of this theme come up. What we can do now, though, is be able to
play things from the file system API, right? We write audio to the file system API and
play it. We can generate audio. So there's a new API that we'll talk about that you can
use to generate audio in real time in JavaScript. If you don't want to generate it, you can
analyze an existing sound file. So this is really cool for real-time analysis of played
music. So I just quickly want to recover -- right? -- everybody knows about HTML5 audio. You
know, there's an audio tag. It's native to the browser. There's no plug-ins. This is
really exciting. Pass it your source files. All is well and good.
This demo is probably the least sexy you'll see today, but this is illustrating really
a cool concept and that's being able to generate audio using the file APIs we talked about.
Arne is going to generate wav files, w-a-v files.
This is the same file system that we open with the terminal, right? So that all the
images are still there. He's just generated two wav files using a nice JavaScript library
for that using typed arrays. Go figure. And then we can play that -- this is the file
system -- you want to scroll up a little bit? >>Arne Roomann-Kurrik: Yeah.
>>Eric Bidelman: We're playing that. We're saving that data, those files, to the file
system and then reading the file system URL that we talked about, and then rendering that,
just populating the audio source tag with that URL.
So really nice example of this stuff working together very nicely.
So that's HTML5 audio, but I really want to focus on a new API in Chrome which is the
web audio API. So the way this API works is that you -- you
basically have this audio context that you construct, very similar to canvas actually,
and you manipulate the sort of nodes and system as you go.
So if you're just wanting to play a sound, of course this is an API for sound so we can
play a sound. Go figure. But you create this audio text context with this new property
in the window object, and then if we're just going to play a sound, we just want to construct
these nodes. So we're going to construct a source node
and just pass that off to our destination. We're just going to play the sound. And the
way that works is by creating a buffer source. So we'll pull in our MP3 file or our audio
file using XHR, and then we'll populate the buffer with that array buffer data that we
got. And then we're just interested in playing
the sound so we'll connect the source right to the destination and then calling note on
at time zero will just play that immediately. [Beeping sound]
So it's a bell. Not too exciting but, you know, we can use this exactly as we would
HTML5 audio. Let's see something more interesting.
So generating sound. This API allows you to generate sound inside of JavaScript. I'm doing
DSP.JS. That's a library that was written for the Mozilla audio API. They have their
own API. But you can use that also with this API in Chrome.
So I'm generating a sine tone, and instead of loading up an audio file, we're just going
to pass that off. We're going to create a buffer, pass that buffer, that sine wave,
off into our API, and then connect the source to the destination. We're just going to play
this audio file. At the bottom here, we have two canvases.
So Arne is going to play around with frequency. This is all real time as he's doing this and
Chrome is generating the sound. And we're rendering that frequency data out to the canvas
tag, which is the oscillation. So you can change different types using that
DSP.JS library. What's happening on the right is actually
a Webworker so we're calculating the FFT -- right? -- the spectrum of the audio file -- the audio
sound, on the right side, so that's why there's a little bit of a delay. We're passing out
data, doing the calculating, it's coming back, and then rendering that out to Canvas.
Having fun? >>Arne Roomann-Kurrik: Always.
>>Eric Bidelman: Of course, we can generate sound. We can play sound. But what's really,
really amazing about this API -- the Web audio API is you can analyze existing sound. So
I kid you not, in ten lines of code, maybe 11, 12, depending on what you are counting,
you can analyze a sound file and then present that to your users with some kind of visualization.
We will do the exact same thing. We will create an audio context. This time we are interested
in analyzing it. We will create an analyzer node. We'll create a JavaScript node. The
JavaScript node is going to fire events at us, and we will be able to process -- as audio
is processing in the system, we will be able to take that and do something with it.
In that event -- Arne will zoom in here. Do you want to highlight the portions of the
code too? >>Arne Roomann-Kurrik: Oh, yeah.
>>Eric Bidelman: Cool. We are using a typed array. This is will be
more performance for us the frequency bin is going to be filled by this "get" frequency
data call. It is going to fill this array with frequency data. We can use that. We will
see a couple of demos of that for visualization. Same thing again, we are just connecting these
sort of blocks that we are creating. So we will create our buffer. We will load the file
in. And then we'll connect source to analyzer, analyzer, the JavaScript node that gives us
the events, and then the JavaScript node to the destination.
So let's see a demo of that. >>Arne Roomann-Kurrik: you are going to show
them the prototype? >>Eric Bidelman: Yeah. Is that okay? We are
working on a new computer. >>Arne Roomann-Kurrik: Last time it didn't
work out so well. >>Eric Bidelman: We'll show them anyway.
This is Gal 9000, a new prototype, another operating system Google is working on. If
you want to zoom in on this. This is just a DIB. This is all markup with rounded corners,
linear gradients. I apologize, it looks better in the lab tap. He has got a radial gradient
that's producing the red-block effect and the dot in the center, multiple backgrounds,
right? The only image on this page is that reflection at the top. Probably wondering
how -- what this has to do with audio. >>> Good afternoon, gentlemen and ladies.
I am a Gal 9000 computer. I became operational at the Googleplex in Mountain View, California,
on the 4th of May, 2011. My instructor was Eric Schmidt.
>>Eric Bidelman: We can create an artificial life form to talk to us. This is actually
Arne's voice. We have loaded up an MP3 file. And what's going on is as this file is playing,
we are analyzing using the API, this Web audio API.
In the center there, you can see his voice and that's a Canvas tag. We are rendering
Canvas based on the amplitude of each of the samples we get. That's what's doing the flickering.
Also CSS3, so we are changing the radius of that CSS3 gradient. That's what's producing
that effect on the red-to-black. >>> The Web audio API is really quite nice.
>>Eric Bidelman: I like it. All right. Turn off the prototype.
>>Arne Roomann-Kurrik: I'm afraid I can't do that, Eric.
>>Eric Bidelman: Nice. So that's Gal. Again, Web audio API, Canvas. What else? Typed
arrays, again, this stuff is showing up all over the place in these complicated APIs.
Let's see some more visualizations we can do using the analysis portion of this API.
Go ahead and press start. [ Music ]
I will start of talk through this. But it is audio so you got to listen to it, too.
Arne, you are going to deejay? >>Arne Roomann-Kurrik: Yeah.
>>Eric Bidelman: Arne is going to deejay this. This is again analyzing the sound file on
the fly in realtime, and then we will are just rendering each of those bins. We are
moving through that typed array and then rendering that to Canvas.
This is this cool little half circle. That's a filter -- an SVG filter over this Canvas
element and a gradient that's used as a mask. Let's go ahead and hit "next."
Boom, CSS3 animation. It is just Canvas, so we can change the coloring of what we are
presenting, change the gradient there. Arne, do you want to go to options and play
around a little bit? [ Music ]
So, again, we can render this data any way we want in Canvas. You don't have to use WebGL.
You can use CSS3. You just saw a demo of that. We are just presenting it a different way.
You can do time or frequency domain analysis, time domain. Analysis.
You can speed up the playback rate. Go ahead and do that.
Nice. Let's go to the next slide. So this is the HTML5 logo. Again, Canvas but
it has been overlaid with the HTML5 logo as the webkit mask there. You can take that one
step further, and Arne introduced us to some really great transformations in CSS. So we
can apply a 3D transform to this entire thing and in realtime it is still going. There is
a little bit of flicker, and we are using Chrome dub channel. So leading-edge stuff
here. Let's go ahead and show the next visualization.
So Chrome, little beat detection library. We can beat detect Chrome. CSS reflection
on the bottom there. Kind of a cool effect. Are you having fun by yourself? Can we invite
some people to this party? We have people streamed in.
>>Arne Roomann-Kurrik: I have an idea. I can invite my special guest.
>>Eric Bidelman: Bug Droid. We can animate Bug Droid. He's just markup as well with rounded
corners. His ears are going. His leg is twitching. He is really getting into it just using CSS3
transitions and animations. But, if we turn this up, if we get really
excited, we get a fist pump. Yeah! Just CSS and using the API to analyze the
sound file on the fly. I'm just getting that data and rendering it as the amplitude changes.
All right. So that's -- yes, thank you. [ Applause ]
So that's the Web audio API. I only showed you a small portion. There is effects. There's
panning. There is convolution. There's all kinds of stuff. You can imagine when you have
microphone access, then the device API, when that comes out, the ability to talk into a
microphone and do auto-tune in the Web browser, that's going to be really cool.
So support right now, just Chrome. But FireFox is sort of -- actually I didn't tilt it. But
FireFox has their own API. A lot of these demos should work in both of the APIs. So
they are very similar but, again, with differences. >>Arne Roomann-Kurrik: I don't know about
you, Eric, but I'm full, I'm stuffed. >>Eric Bidelman: Full on what?
>>Arne Roomann-Kurrik: Knowledge. >>Eric Bidelman: Yeah, that was a lot of stuff.
We went pretty quickly. 13 minutes to spare. So let's just sort of recap what we covered
because we did cover a lot. Bleeding-edge stuff in Chrome all available on dub channel
today. First, I started off with the file APIs. How
do you get binary data in your application? How do you work with it? How do you manipulate
it? How do you store it using the FileSystem API and the terminal demo?
>>Arne Roomann-Kurrik: Then I talked about graphics. Again, the three approaches that
I like to think about: Declarative with CSS and SVG, scripting with JavaScript and the
Canvas element, and then accessing low-level APIs through WebGL.
>>Eric Bidelman: Yep. And then I rounded out the picture with multi-media story. Put gold
in your pocket with the Web audio API. There is a lot of great stuff.
>>Arne Roomann-Kurrik: A lot of gold in your pocket.
>>Eric Bidelman: A lot of gold. You might not be able to walk out of here.
>>Arne Roomann-Kurrik: We have a lot of resources. Again, they are all linked to this presentation.
You will find links to the presentation after the session. We have it all hosted on a code
hosting project and all that stuff. We have it hosted at htmlfivewow.com. But it is not
open yet. We will turn it on after we get done.
>>Eric Bidelman: Yep. >>Arne Roomann-Kurrik: Once again, please,
you know, find the feedback link. It's goo.gl/ac8n7, all lowercase. We really appreciate the feedback.
We get a mandate to come back and again and do some more crazy stuff if you guys like
us. So I think that's it. Thanks for being a great
audience. [ Applause ]
I'm going to launch this Moderator. >>Eric Bidelman: Go for it. Time for questions
if people are interested. If you have any questions, step up to the mic. We will start
rattling off the Moderator questions here. Yeah. So as -- Yeah, as we kind of -- as people
trickle out, I know you are probably eager to get to your next session lunch.
>>Arne Roomann-Kurrik: Or lunch, yeah. What software Web technology are you using for
your presentation? That's actually a great question. We didn't really emphasize it. We're
using HTML, JavaScript, CSS. We just wrote it all by hand. It is part of
that open source project. And we'll be happy to go over that. We will probably post tutorials
about how we built stuff on html5rocks.com. Live question?
>>> You guys had that request animation frame function. So when you switched the tab, it
obviously stops, right? >>Arne Roomann-Kurrik: Yeah.
>>> What happens when you hide the element or you set it invisible, does it stop as well?
>>Arne Roomann-Kurrik: Yeah. In Chrome's case, it doesn't currently.
>>> Okay. >>Arne Roomann-Kurrik: At least from my quick
testing on it. But that's part of the idea behind the specs, so I think it is just not
implemented yet. Eventually, it should be that if you hide the Canvas element, you don't
need to make any sort of callbacks or change your game code or anything.
>>> Okay, great. >>Arne Roomann-Kurrik: That's exactly what
it's intended for. >>Eric Bidelman: So similar question: What
slide -- How are we doing the slides? It is all going to be open source.
There are sort of HTML5 -- other people are doing different HTML5 slide decks here at
I/O this year and on html5rocks, there is sort of a template and you can take that and
use that in your own slides as well. This particular one uses CSS3 transforms and transitions.
>>Arne Roomann-Kurrik: You can down arrow. Yeah?
>>> In the audio demo, what were you guys using to do the FFT?
>>Eric Bidelman: The FFT is calculated in the API itself. So there's' the API call for
that. >>> Oh, awesome.
>>Eric Bidelman: The API, I didn't explain, it exposes a lot of low-level functionality.
If you have ever done the Mozilla API, everything is basically in JavaScript and you get events.
This one, you do the FFT -- there is a call for it and panning effects and convolution
and all that cool stuff. >>> Awesome. Do you know if that will be offloaded
to the GPU in the future, if possible? >>Eric Bidelman: Good question. Right now
it is all CPU. It is brand-new, just landed. Hopefully, yeah. Sure hardware sell everything
if we can. >>> Yeah, exactly. Cool, thanks.
>>Arne Roomann-Kurrik: I guess we will do another one online.
>>Eric Bidelman: Sure. >>Arne Roomann-Kurrik: HTML5 on Droid devices.
Google does support HTML5 on Android devices. The Android browser can render HTML5, so...
I don't know about marketplace. We don't really talk about marketplace right now. So I don't
know. I'm not sure I follow. >>Eric Bidelman: Maybe somebody in the Android
section can answer. >>Arne Roomann-Kurrik: I'm sure that's a good
question for the Android sessions. >>> With the HTML5 audio and video tags, if
the browser doesn't support a particular codec, is there extension abilities to install that?
>>Arne Roomann-Kurrik: That's actually a good question. Right now I don't believe so. I
think that Native Client in that case might be an interesting technology to use because
Native Client is an open source project that's Google's kind of helping develop.
You can write C code and compile it in a way that's secure, has a Sandbox and run it on
arbitrary HTML sites. So in that case, if you had a custom codec,
you could probably implement it using Native Client and draw out to a Canvas element or
something at high speed. I would imagine that would be the approach
to take. I don't know of any, like, extensions that could let you do that.
>>> Thanks. >>Arne Roomann-Kurrik: Sure.
>>Eric Bidelman: Moderator question: Has there been any work letting Web applications handle
multiple windows? If I understand the question correctly, just being able to open up multiple
tabs maybe in your Web application, there is actually a really great use case for Shared
Workers here. So Web Workers, there is a version called Shared Workers that you can basically
fire up this worker. It is sort of a background process, if you will, that you can use to
manage multiple -- the same state across multiple tabs and communicate inner-tab communication.
>>Arne Roomann-Kurrik: It is like having an invisible window that can talk to any other
window on your domain. So, yeah, that's actually really useful for that kind of thing.
>>> One more question. So you guys were getting file handlers and folder handlers and stuff.
Is there any way to persist folder handler, let's say, to a next session or through a
cache or something like that so you don't have to get the user to give you the folder
handler? >>Eric Bidelman: It is a great question. Right
now, this sort of HTML file system API is a Sandbox per app, per origin. You can't write
files outside of this location. There is an API that's been spec'ed out that's not been
implemented called a FileSaver API. This will allow you to do things like open
the user's -- with permission, of course, open the user's "My Pictures" folder and read
and write data to that. Right now it is just a spec. Nothing has been implemented.
>>Arne Roomann-Kurrik: In terms of extending those handlers, not right now, I think there's
-- like, I have seen some vague discussion about it, just -- it would be nice to have.
I think people are going to think about it. Right now the FileSystem stuff is where the
focus is. >>> Because of the Sandbox, there is no way
to sort of have the location of the file without the user's interaction access that folder?
>>Arne Roomann-Kurrik: Not like a persistent handle to some shared directory on your FileSystem
or something. >>Eric Bidelman: For example, you saw in the
demo -- the FileSystem terminal demo, he was dragging in files and that's how we got them
in. We are actually duplicating -- there is two copies. There is the original folder and
then there is the one we are duplicating into the FileSystem. There is always that interaction
right now. Or you can import them if you had the zip
file. That photo gallery demo, if that was not local, that was on a server, you could
download that and then save that to the FileSystem as well. There's different options.
>>> Okay, thanks. Great talk. >>Arne Roomann-Kurrik: Schizophrenic question.
Let's see. Rendering HTML5 versus Android apps. We're not in any position to say that.
I think Google is supporting both apps. We have got lots of talent.
>>Eric Bidelman: The beauty about HTML5 is you can run it anywhere, right? There is Web
apps and all these platforms run those. >>Arne Roomann-Kurrik: And Android apps are
one thing and then Web apps are another. >>> Hey, guys. Whoa.
I'm working on an HTML5 game and in one of your other sessions, you guys recommended
using Sound Manager 2. In what instances should I be using Sound Manager 2 over -- or Web
audio API? >>Eric Bidelman: So kind of a different use
cases. Web audio API is going to allow you to do effects on audio and things like that.
I just showed you only portions of it, right? Sound Manager is great -- a great option right
now for using sound across browsers. Audio -- there has been a lot of bugs in Chrome
for HTML5 audio that have been recently resolved. But as far as audio is concerned, Flash is
great. Sound Manager is great. We definitely recommend it. Chrome can run Flash. Why not,
if that's the best option for you. >>Arne Roomann-Kurrik: I think the major concern
that Sound Manager was trying to address was that the audio tag had no contract between
when you wanted a sound to play and when it would actually play. It wasn't meant for low
latency or no latency audio effects. So in the case of -- so people started using
that and it was really kind of intended for streaming or that kind of thing. So people
started using that for sound effects. It wasn't really suited. That's why we have that other
API that Eric was demoing, that it is really kind of more inline with what Sound Manager
is trying to achieve, which is like, I have a game and I clicked a key and I want to play
a sound right now. The latency is a lot better. I think Sound Manager's support is just much
wider at this point. >>Eric Bidelman: That's really a good point.
So if you want your users to use Chrome and use the audio -- this web audio API, there's
that note-on function. When Arne was pressing the button, the bell called note-on at time
zero. You can actually schedule when stuff things.
So the API was designed for low-latency things like games -- right? -- button clicks, beeps,
and stuff. >>Arne Roomann-Kurrik: Sequencers.
>>Eric Bidelman: Sequencers, all that stuff, yeah.
>>Arne Roomann-Kurrik: Yeah. >>Eric Bidelman: So I mean if you want to
stick with that API until it becomes standard across different browsers, there's a specification
out there right now, but Chrome is the only nav implemented.
>> All right. Thanks, guys. >>Eric Bidelman: Yeah. Sure. Okay.
Well, again, "Will this presentation be online somewhere?"
Yes. HTML5wow.googlecode.com. "Is Google's Panda algorithm set up to be
looking and liking HTML5 compared to just standard HTML?"
Don't know the details of Google's crawling algorithm. It does understand -- webmaster
tools actually does understand micro-data and micro-formats. I think it presents different
things based on what you have on your page, right? If you have a --
>>Arne Roomann-Kurrik: Yeah. >>Eric Bidelman: -- like a music site -- right?
-- you can do albums, it will understand that and parse that out.
I don't know about the semantic tags. Keep in mind that a lot of this stuff is still
changing, so yes, the -- all the browsers now have HTML5 semantic tags mostly implemented,
but a good example of this changing is the H group tag, if you're familiar with that.
They kind of pulled it out, put it back in, pulled it out. So the specification is still
changing. Until I think that really solidifies and everybody is, you know, solidified on
something, then I don't know if Google will update itself, but honestly no idea.
>>Arne Roomann-Kurrik: I think -- yeah. >>Eric Bidelman: "What is the link to the
presentation?" So the presentation itself is HTMLfivewow.com.
>>Arne Roomann-Kurrik: Where five is spelled out.
>>Eric Bidelman: Where five is spelled out, so f-i-v-e.
>>Arne Roomann-Kurrik: But it's under a password right now.
>>Eric Bidelman: Yes. Sorry. >>Arne Roomann-Kurrik: As soon as we get off
stage -- >>Eric Bidelman: Yeah. For anybody viewing,
it will be up as soon as we get off stage. "The time and frequency domain analysis was
amazing. Is that processed via some JavaScript library?"
So the time and frequency domain is part of the API, so there's a call on that analyzer
node that I created. Analyzer.get frequency data as a time domain or frequency data as
a sample domain. And so, yeah, that's part of the API itself.
So just to contrast, the Mozilla API I think you have to do all that processing in JavaScript.
This one you basically just fill an array and then use that array. You saw me render
that array to canvas. That's what was going on there.
"Terminal seems to be awesome." It seems? It is awesome! "Is it available on Chrome
store or G-lab someplace. I couldn't find it. Maybe you'll share it." Yeah. So we -- there's
a tutorial on HTML5rocks.com that has the file system API access and that's sort of
the v1 of this. We've definitely done some new stuff and capabilities for this presentation.
I will put this up on the Web Store. One thing that we didn't discuss was you saw Arne at
the beginning type "install." The terminal was installed, and that's installing the application
as a Chrome Web Store application, and it actually -- that's needed right now because
in order to use -- in order to write data to the file system, you need to have either
a flag running on Chrome, unlimited quota, or something like that.
Most users don't know how to, you know, start Chrome with a flag, so if you have the unlimited
storage bit in your manifest file for your Chrome Web Store app, that's what allows you
to do the read and write right now. As soon as Chrome expands and it has a sort
of a quota system, then we'll have the ability to -- to -- any Web application can use the
file system API to write data. So yes, I -- the short answer is I will put that up on the
Web Store someplace. >>Arne Roomann-Kurrik: I think we're out of
time actually. >>Eric Bidelman: Are we out of time.
>>Arne Roomann-Kurrik Yeah. >>Eric Bidelman: Okay. Well, thanks again.
Thanks for being a great audience. [Applause]