 Hello. Hello. Hi. That's good. Really good. So this is HTML5 Rock's live episode. What are we in? I'm not sure. Four? Four? This is the office hours today. So we will be taking questions over Google Moderator and live too, if you'd like to join and ask questions over the Hangout. That'd be cool too. Absolutely. That's answering any questions that you have about developing with Chrome, for Chrome. Developing for the web is also a good one. Yeah. I was hoping to get to DevTools questions. That'd be cool. Yeah, we're pretty much open for anything you guys want to talk about, whether it be DevTools, whether it be open web questions, mobile questions, just in general. So we have a Moderator page set up. I think we've shared that out through the Hangout link. So feel free to start posting questions there. Feel free to join the editor circle. And then we can get you into Hangout. You can talk to us live. But let's start. Who the heck are we talking to here? Okay. I'd like to introduce yourself. Sure. My name is Paul Irish. I am a developer advocate focusing on tools, Chrome DevTools, and the larger ecosystem of tools that use Google Apps. That's cool. My name is Eric Weidelman. I'm on the same team, the Chrome DevRelations team, focusing mainly on open web platform stuff, HTML5 stuff, and helping people ramp up on that. Hey, I'm Boris. We're the same team. Mostly doing mobile stuff. Yeah. Forces are a mobile guy. So if mobile questions, you can ask directly to Boris. That's true. And Ernest Delgado, also in the same developer relations team, focusing on extensions. Ernest, where are you right now, man? San Francisco. Just someplace on the internet. That's right. Should we dive into the moderator? Yeah, sure. I'm done. Okay. So, yeah, again, if you have any questions, pop into the moderator. We have seven questions now and we want some more. So go in there, vote up other people's questions, ask what you want to think about. Over the weekend, I actually asked, for everyone building web apps, what's the hardest part? And got a lot of really good responses. Interesting. So we might actually talk a little bit about that. But if you have any, you know, have a response to that, post it in here, and then we can talk about it. Yeah. Cool. I guess we'll start off with some of these questions inside the moderator. The first one that we got is from Joey in San Francisco. What's up, Joey? Joey asks, about a year ago, Google announced it would be dropping into H.264 support from Chrome in favor of WebM with a status on that change. So the story here is that Google is committed to WebM. WebM is, we think, is the right direction for video online. Yeah, I think with a lot of this stuff too, right? I mean, this is only announced a year ago or less than a year ago. So it's going to take some time to completely transition out. But yeah, I think Google is very committed to WebM. As you've seen, we're continuing to contribute to that project. The code is open source. So it's just a matter of time, I think. That's my take on it. Yeah. Good. WebM is great for mobile too. All right. Nice question. All right, cool. So a circuit doctor asks about ARIA. So ARIA, also why ARIA? It's the, oh, I wish I knew what the acronym stood for. The why, or is that ARIA? It's assistive. Interaction? Interaction. Internity. Interaction. Okay. That sounds good. So it's for adding annotations to the DOM that are read by screen readers in the goal of making web apps a bit more screen reader and assistive device friendly. It's accessible, rich internet applications. That is. It's ARIA. Interesting. Okay. So a circuit doctor says, we'd love to hear more about why ARIA supports going forward, especially on Chrome mobile for Android. So we have a good size team that is focused on accessibility and Chrome also for Chrome OS. And so that team is very focused on having great ARIA compatibility. We've put out Chrome Vox, which is our screen reader. It ships by default on Chrome OS. And you can download it. I think from the web store these days for a regular Chrome. So that is our screen reader there. It uses the extension API. Yeah. Extension API? Yeah, there's like a speech synthesis extension API. Yeah. There's also Chrome Shades, which is a pretty cool extension. The goal of it is to basically give you the ARIA annotations in the form of text so that a lot of times, like as a developer, you want to be able to develop a site or app and you want to see kind of what the accessibility annotations are going to be. You don't actually want to listen to everything. It just traverses. The Chrome Shades actually gives you a textual view of things, which is really helpful when you're developing. As to ARIA support in Chrome, Chrome is committed to having great ARIA support. And the team is very passionate about it. And we're talking internally a lot about what is the best way for authors. Should they be using ARIA annotations, HTML5 elements, like nav and such. So nav is supported. It maps to the implicit ARIA mappings. We should bring up the can I use data on where ARIA is supported. Sorry about that. We had some technical difficulties on the producing, and these guys do a fantastic job. Sometimes, you know, notes go up. You can't help it. But where were we? We were showing can I use data, correct? Or ARIA, ARIA support. So you're just rejoining. We were talking about why ARIA and support in Chrome, where things are going. And Horace was bringing up the sort of support matrix for the story on that. One of the... Don't bring that up. We're critical today. None of this room. One of the other resources that's really good for ARIA is HTML5accessibility.com. The Stephen Faulkner and the Paciello group put this together. And it's a summary of HTML5, L1 support, their mappings to ARIA, and kind of browsing to all... It's a really good report on compatibility. So I use that a lot. And in fact, while we're talking about accessibility, the research and data that Stephen Faulkner and Jason Kis put out are just tremendous. One of the big challenges, I think, in accessibility to map what the spec says to what's actually in browsers to what developers should do. And developers just want to know the facts, right? And don't want to understand the... If you read the ARIA primer, it gets a little bit complicated. Yes, it's pretty great. But Jason Kis and Stephen Faulkner have a lot of really great data on accessibility and how to actually implement things well as a developer. So I'd recommend that. The question also asks, Sir Dr. wants to know about, especially for Chrome for mobile. Of course, any ideas? Yeah, but ARIA support, to be honest, I don't know right now. We're still in beta, so I suspect the answer may be not that great right now. But at the same time, we pretty much... We're moving very quickly to share a lot of code with Chrome. So, yeah. I'll have to follow up with that, with the team on that. Cool. All right, should we... Okay, I think I've just connected to the right hangout. Oh, good. All right. I took you out. I was apparently in that old one still. The support is going to bring this up. So here's the support matrix for ARIA. And you can see it's... You can see it? Yeah. Cool. So it's pretty good. Partial support, I'm not sure which part is the support. Yeah, especially with what that means. Yeah, typically on Can I Use, there will actually be a note towards the bottom describing portion support stories. But not in this case. Right, there's a lot of details here about ARIA. There's a nice test result page. Yeah. Yeah, probably worth checking out all this stuff. So yeah, apparently Android browser, I haven't checked this. So it's for it, even on ICS. But there's a good chance still that Chrome does because of the share code base. It's great to see Firefox now, you know. Yep. Future versions. Paul, you mentioned the extension to read the annotations. Can you say the name again? Yeah, so the name of that extension is called Chrome Shades. And I'm not really sure where about that is these days. The last one actually is like a separate... Oh, okay. Chrome Shades, one word. Chrome Shades? Okay. Yep. So yeah, as one word, you'll find it. The Chrome Accessibility team put that extension out. There's a really great talk, actually, by the developer of it at last year's Google I.L. about developing accessible web applications and walks through a lot of the common cases of like, I click and a dialogue comes up and we've got to make sure the keyboard focus is now within that dialogue so you're not tapping through everything that's underneath it. That's a very common gotcha with web apps. A lot of the accessibility stuff is like, it's the last 10% of your app, but it's a really easy last 10%. It's things like keyboard focus and... A lot of keyboard. And using buttons instead of links and stuff. And people just don't spend time thinking about it, but they should. They really should because it's just super easy to leverage. Yeah. In general, let's see support continue to grow in Chrome. Good. Okay, so anyone else that's just joined us, we're just answering questions today. If you have any questions, jump into the Google Moderator, ask something, vote up and down on other questions. And if you want to just come in live into the room. Yeah, we'll just chat with you. Absolutely. All right. Moving forward. What's next? We've got a question coming in from Seattle. Would you really like to see some info on using Google Closure, specifically how to manage a large project using modules and UI components? So I don't have a... I personally don't have very much experience with Google Closure. Google Closure is a library. So there's actually three parts. There's a Closure library, Closure Compiler, Closure Templates. And I guess actually now there's a Closure Style Sheets. Yeah, it's your system. And there's a linter built into the Style Sheets. It's a very large project. Closure is used by pretty much all the apps teams internally at Google. It's a very, very robust library. As to managing a large project, this was built for Google Apps. So all very large projects. There is a wonderful talk that was done last year at Google I.O. by Michael Bolin, B-O-L-I-N. And it was called something awesome. But it's about managing very large databases with Closure. And writing web apps for that. So I would just recommend watching that, checking out his slides. In addition to, he wrote the book on Closure. That's the book on Closure, yeah. The O'Reilly book. This is the best documentation out there for Closure. This is the I.O., Tom? Yes. This is the one, yeah. In the large. Yeah, exactly. It's a really good talk. So those are your two best resources. Very good. I imagine large projects. Maybe he's talking, I haven't actually personally seen this, but I'd love to see the Google Apps scenes relinquish other knowledge and building large-scale web apps. Maybe we can get them to write articles, write some five rocks or some things. Actually use Closure in the wild to make these large-scale products. Yeah, there's a lot of things happening with modules, for instance, where we're seeing AMD modules and people working with common-js modules for client-side code, figuring out ways to make that work. And Dojo and Closure, for instance, have had a solution for this years ago. And so it's interesting to kind of see now the external JavaScript community finding the same sources of patterns. So I think we could definitely get more information from these internal teams out. Certainly what they're doing. To return, does anybody have a live question? Chris, I think. Welcome, sir. Hey, Chris. Any questions? That's cool. All right. Any hangout? Hangout. Let's check out the moderator then. We had a great question. I love this one. When will all the current awesome and canary depth tools make it into stable? Indeed. All right. That's all you guys about this rule I came up with? I think you did. This was entertaining. The 7-Eleven rule. You guys are gonna like this. Yeah. The number is not at the store because I don't need to get sued or anything. Just two numbers. The 7-Eleven rule means that when a feature lands and shows up in canary, which is, you know, canary changes every day so it's a daily thing, from canary to stable is a minimum of seven weeks and a maximum of 11 weeks, assuming that the feature doesn't get held back. Sometimes, like 3D transforms and other things kind of just hung out in the dev channel for a long time. But I don't think there's ever been a thing in dev tools that has been held back. So from canary to stable, you're looking at somewhere between 7 and 11 weeks, which is, what, three months? Two to three months. So that's not too bad. Pretty, I mean, we ship generally about every six weeks. So to have something from when a developer finishes the patch to having it for all 200 million users of Chrome, seven weeks. And like Paul said, for larger features, right, I mean, they're gonna be baking probably in canary for a little bit longer, dev channel for a little bit longer, maybe behind the flag. So that's the current, some of the dev tools extension stuff. So they're new APIs and some of the features are behind the flag. So it just depends. If work is done in time, then yeah, that'll make it itself out in six weeks or seven weeks. Canary works well for developers. I used to run developer channel, and I kind of do. So I used to do dev channel and just testing canary stuff, but I moved to stable channel. Stable canary. Stable canary is something I do. Because everyone else has, you know, your users are running stable. So you want to be unstable, but you also want the nice depthless hotness and be able to test any new, you know, platform JavaScript features coming down the pipe through canary. So it goes side by side. Unfortunately, we don't have a canary for Linux, but there's a lot of packages that track essentially the dev channel, but some more aggressive. So there's solutions there. And there's a lot of people that write scripts to go and download the newest Chromium build. It's automatically installed on a regular basis. I have a really nice script that just downloads the latest version of Chromium, but we should share. Yeah, maybe we should. I think it's called Chromium. There's at least 10. There's at least 10. So there are solutions. If you want to get the latest, even more bleeding edge than canary. You can go to downloadchromium.apps.com. Yeah, that's just the latest. And that will be absolutely the latest. Works for every platform. And then there's more solutions for like setting up a Chrome job to do that or something. Uh-oh. Seems to be down. Download dash Chromium. Might be. Mmm. It was pretty cool. Hit download. And... Ah. Sometimes there's this nice... We wouldn't be able to see it on the Hangout, but there's this nice animation of the Chromium logo sliding down to the bottom left corner where the download starts. Wow. Yeah, exactly. And you hit it and it goes, and then your download starts. Yeah, it's really nice. So that makes your download better, huh? It's way better. Cool. It's written by a guy who had it free after use. Yeah, Francois Bouffaut. I'll give him any of those. He's a great guy. Traveling the world right now with his girlfriend. But before he did that, he was making this site. We have digressed. Let's start back to you, the moderator. Okay. Closure. It's the next question. Coming from Joey in San Francisco. The Chromium is very involved in the development process. It's an internal general opinion of the process. What's your opinion on Apple's cable approach? Proposes back in somewhat of wood. Same as process. I hope it's okay with you that I'm just going to get that last part of the question. But let's start talking about the first part. Chromium runs on the web. Google is all on the web. And so making the web awesome is really important to Google. And so Google is very committed to the same as process. And it's great to work I've attended a number of standard Z meetings with working groups and browser folks working out standardization and interoperability. And it's great and it's really important. Sometimes, so we're very committed to that. Sometimes there'll be a situation where we might prototype an idea as a Chrome extension API. A good example of this is notifications. Notifications with Chrome extension I don't know, sorry, like a year and a half ago or something like that. Got revised. And at the same time we, I think there was a working group that was started a new one with the charter of working out how notifications would work. It finished. The new API is different from what would originally landed in Chrome. And so basically, this was a good chance to prototype an idea that worked. And so now we have a better API that everyone can use. And so this new standardize, I think we actually standardize it. We had a co-editor of the spec was actually from most of them. And so now we have a good notifications API that can be fully Everybody's agreed on that, but it can be a standard process. Because I want to have a web app that can do notifications and I want to support all browsers for that. So I think similar stuff is happening with like speech input. We have like a Chrome extension that does that. But then there's like speech input. Working group, I think. It's like definitely a work in progress. Yeah, so I think we're partnering with a Yeah. So that's a great example. Maybe start with it. Let's start with an extension of the API, right? But now people decided there's a very much need for this out there on the web. So let's start a group around it. Let's get some consensus on the standards body. So we have a different browser vendors from WBC that come to include collusion and a great API. Yeah, that's cool. It's great to see that sort of turn into a prototype but move to the interplay between browser implementations and standards. I think it is really important to not only have an implementation so that a vendor can explore and prototype and see like, is this awkward, does this work. But also have, more importantly, have something for developers to work with and be able to give feedback and say like, this does not need my needs. I think actually, I was thinking about this recently HTML5 history, like push state. You know how you use push state and you'll be like, now we're going to push state and then you'll do first argument empty object, second argument empty string, third argument the thing that you actually care about, the new URL. And I feel like, you know, the feature is great but I feel like we kind of that API is probably the best. Yeah, that's true, that's a good point. There's nothing to be said for having this intermediate prototype in place. Yeah, this is super important too. And that feedback actually exists, right. There's engineers on, you know, coming to those projects and people look at the stuff all the time. And part of our job is to listen to the developers, right, and to prioritize things. If we're seeing that everybody's passing null and null, if there's two arguments of history, maybe that's not the right time. Yeah, and Paul, you created that page where you were giving instructions for developers how to participate at different levels and I think one of the sections was that these feedback for the standard part. Are you talking about HTML5 please? Yeah. Yeah. And so HTML5 please is trying to harness the community's knowledge on the best way to implement everything. It's bigger in scope than just HTML5. It has a lot of CSS stuff on it. But for everyone that's experimented with some of these newer APIs knowing like should I use a polyfill? Should I just use something else? Should I avoid it entirely? So it has a lot of recommendations for all different sorts of features. And so this is really great if you want to try out a new feature and you're interested in how to get wide capability across browsers or let it fall back. And also there's an edit link on the bottom right of every single item. And so if you have any feedback for how it could be better please just make a full request on GitHub and add to the questions. I think it wasn't this one. I think it's the move the web forward. Yeah, that's a good point too. movethewebforward.org These are popping up all over the place. We synthesized. Yeah, good call harness. So this one is... There's a lot of activity at the standards level between browsers and standards folks. But there's a lot of things that developers can do to not only be involved in that process but also to help all other developers understand how to make them make the most of web platform. So movethewebforward has a lot of ideas on regardless of your skill level, experience level or available time, kind of things that you can do to really push the web forward. Well, yeah, take a look. We'll be sure to capture a lot of these links and post them in the Google Hangout stream later on so you guys can follow up and read some of this great documentation from these sites. Cool. Should we turn back to the moderator? Let's see. There's one that's trending here I would say about the History API. We just talked about it. So recently we started working on the History API and have problems with the firing of the onpopstate events on History Push Date. I was wondering if this is known bug or a problem with my code. This is a really great question. Without seeing the code, I have no idea if it's your code. So I think what actually would happen was that Push Date was standardized. Mozilla said, you know what? Don't really totally agree with that spec and so they changed the behavior of the onpopstate event to, I think, fire initially, right? Fire at the beginning? Yes. Either a fire is really in or it doesn't. And and so Firefox asked for that. I believe, I don't know the statuses, I actually thought that this got resolved recently but I suppose not. In the meantime I would recommend looking into History.js History.js normalizes this behavior and gives you the onpopstate event if it's not firing. But yeah, this one is a little tricky and requires a little bit of So the semantics of the events have changed? No, it's not the semantics. It fires in Firefox when it doesn't fire in Chrome. That's true. On page later? Yeah. So yeah, but if you think this is a bug, feel free to post a link to a JS bin post or JS middle post and we'll have to take a look at it in the Google Plus stream and then we can help you to bug. If it is a bug we'd love to log it and make sure it gets looked at by some of the engineers. Yeah, typically a lot of times when you come across a bug the first reaction is to tweet about it from my name to Lee. Which is okay. I usually perish about it first. Oh yeah, that's true. And then you might go stack overflow and be like, some of this. Hopefully the points you get to is that you can reduce the bug down to about 10 lines of HTML and JavaScript. And when you reduce it down to 10 lines then we have a reduction that we can put on the Chrome bug tracker and get it in front of an engineer. And the smaller the reduction, the better. It's definitely super easy for someone to fire up a test page and test it out rather than just reading a bunch of sentences in the issue. In my case, I'll end up reducing something because I think it's a bug in WebKit or something and then find out halfway through direction that it's actually my fault. But if it is reduced then it's way better chance that we can get a quick fix to it. Either at the WebKit level or the Chrome level. That works well. There's a great article by Leo Verru on Smashing Magazine about filing bugs against browser vendors. How best to do that. So I would take a look at that. You can try to bring it up here. I think you got it. Then she'll... Smashing bag, you got optimize. That's good. Okay. Whoa, she read a lot. Yeah, yeah. Yes. I'll leave this shared out real quick. Boom. Yeah, we've been... A lot of times, if you do file a ticket just ping one of us on Twitter and be like, hey, I filed this. What we can do is we can go and start it, monitor it and also triage it, which means that we get the correct engineer CC'd onto the bug where they can take a look at it. So filing is great, but filing and pinging us so that we can get it in front of the right people is even better. Cool. But also take a look at this article. Oops. Cool. We'll be back to you tomorrow. Yeah, Boris, I got a question for you. Yeah. What was it like? What was the current state and future plans for touch and gesture support on Chrome on Android? Are there any changes? Yeah, so basically Chrome on Android well, you can talk about Android browser. Android browser got a much improved touch system in ICS. So now it actually supports proper multi-touch whereas in Gingerbread there was a few big problems. Basically you couldn't do it. But now you can actually have multiple fingers on the screen all being tracked, getting the events back. And that is true also for Chrome on Android. So we have a very similar touch support. We support the standard touch events. So touch start, agend, touch move or set of things that we support. Beyond that, we don't have support for gesture events which is something that is actually supported in WebKit. But we don't expose it up to Chrome. But it is available in mobile support. So on gesture events, on gesture start, on gesture end. What do you get passed? The payload for that event is the kind of gesture. So you get things like whether it was a pinch zoom or one. Essentially I believe that's how it works. The other difference with LoL Safari is LoL Safari has special things on the touch event payload. Like rotation. Which we don't support. But it's yet another way of getting that information through this system. So I think we are actively investigating what to do with the gesture landscape. There's also pointer events which consolidates mouse events and touches and stylus input. We are there's a lot of things to consider and a lot of spec considerations. Part of the problem is that Apple hasn't really standardized the gesture events. So it's kind of this gray area of what it would do with that. So yeah. So there may be big changes, but we don't have anything too strange to tell. Cool. You're welcome. But you put out some open source projects before that really helped with touch. Oh, thanks. So let's see. There was an HTML5 rocks article about touch. And there were also some tools. So one of the things with touch is it's really hard to actually test without having a device. And even if you have a device, you'd have to continuously load. There's ways of going about this more efficiently. It'd be cool to just use the trackpad in your laptop. But you can't wait. So anyway, there's a project that I did like a year ago. Hey, cool. We have this on air thing. Yeah. Anyway, so this is the article and I link to the library right there. Also, for just to mention quick look for the DevTools, about debugging touch events, the DevTools has... I don't know, probably in DevChannel or... Probably may not. But you know, we do... Anyway, if you're not familiar with the DevTools, some of their extra goodies that are hidden behind this little wrench in the bottom corner that Boris is showing. So he doesn't have it on. Ooh, I'm going to inspect this hangout. It's going to be interesting. Inspect the inspector. But yeah, the DevTools, the DevTools has actually support for testing... There we go. Hopefully you guys can see this. Whether... I believe it's about flags. You can enable some of these extra goodies that the DevTools team is working on. One of those is to emulate touch events here. So you can... If you're building a web app, right, you can emulate and debug touch events. Which is pretty cool on this part of the DevTools. There's some other good stuff in here too that hopefully in the future hangout we can cover all awesome DevTools stuff. But very helpful for debugging touch events for using a library or Boris's awesome library. A readings article. You want to try it before you buy it, so to speak. Yeah, lots of more mobile specific things, but I guess we won't go any better. Actually, where is it? The device metrics. There is a way to overwrite device metrics. Overwrite user agent. Super handy for mobile as well. And a nice bonus. You saw this, right? When you override user agent, it automatically populates the device metrics on the normal resolution of that device. No, I know that. That's super handy. Except the resolution by hand. Who wants to do that? When you can do... And you get everything. I just learned something new. I was researching the different device resolutions the other day and I had to input them manually. No? That's fantastic. Cool stuff. All right. I expected the inspector. OK. Vaccine moderator, shall we? Sounds good. Where are we at? We have a question about cis transitions. How many browsers require dash transitions to have transitions? Can you hear me now? We'll using easing cause any problems and we'll using 500JMS versus cause problems. So basically what's the status of transitions? How interoperable are they? Are they good? For what need better prefixes? I think the best resource on this is some combination of can I use HTML5 please, but more specifically css3please.com CSS3Please has all the prefixes that you're going to need for every CSS3 thing and next to that it specifies all the browser versions. So let's say that you drop support for IE8 or something if there needed a prefix for box sizing and IE8 that's gone and IE9 you would be able to make that decision. But for right now at least for transitions you need all Every browser needs vendor prefixes, right? WEDKIT, MAZ, OMS and the unprefixed version. Should people be using CSS directly or should they use something like an amazing preprocessor and not have to worry about vendor prefixes? So I agree with that, this is a good point. Because of those so you can go to CSS3Please every single time and remember that Android 2.2 needs a prefix but Android 4 doesn't. But no one wants to. Luckily all this knowledge is being baked into projects like Compass so that if I'm using Compass on top of SAS I can just say that I want to use box sizing or I want to use transitions and be able to get that with really nice syntax and not have to worry about all the vendor prefixes necessary. And they also do a great job of normalizing the differences, right? Like gradients WEDKIT gradients and linear gradients is a great example of a weird area right now where both syntaxes are important in WEDKIT the other one is syntax Safari and the newer one is syntax Firefox and Chrome and others are syntaxes. What are we talking about guys? Vendor prefixes with transitions? What do you mean now? Yeah, so there was the Customs line Customs line? Yeah, sure. Yeah, that's good. Yeah, so you couldn't do a bounce in WEDKIT now. That was a ticket where I just kind of like CC'd myself on the WEDKIT ticket and just waited. And then I got fixed and then I knew. That's all good. And there's one more tricky bit which is that you can't set a CSS transition on generated content in WEDKIT. So you had to do like a before after. People want this bug. It seems like a really awesome thing to do with generated content. What are you talking about? Oh, yeah. What are we talking about? Like an event that fires? No, I have before and after styles for my headline because I have like a little bat. When I hover over that badge, I want it to do some transition as it doesn't work. It doesn't work. It was funny. I was so excited to answer this question and be like, guys, it's the same everywhere. Transition is awesome. And then I thought about it. I thought there was a little bit to go these days. So that should go to age 15 as well. If anyone wants to volunteer. No, there's actually been a lot of content added to that. Thanks very much. Great. Beautiful. Anything else on transition? No. Oh, actually, you know what? While we're here, something that we're going to be talking a little bit more about soon, which is request animation frame. We're actually going to be shipping some new articles on request animation frame. It's an imperative API for getting the animation. And there's a change to the breaking backwards incompatible change. Is it? I don't know. I don't think it is. It's still a good change. When you pass a function to request animation frame, then it gets called. The first argument that it's passed is a timestamp. And that timestamp is like the milliseconds that you talk about. And from there, you can kind of get an idea of how long it's been, calculate any sort of thing. It makes a lot of sense in games and visualizations. That argument is being changed from a millisecond from a regular timestamp to using the high resolution timer. Is that the new spec? Yeah. So there's a new spec. So it's available currently in Chrome Canary as window.performance.webkitnow and it's method and it gives you back a floating point number of milliseconds since the page was created. So it won't be as big of a number as since 1970. And it's sub millisecond, right? Exactly. It has like 10 decimal places on milliseconds. So it's very specific. Right. So when you do a date, that's like millisecond. Yes, correct. That's just a millisecond in integer. But here milliseconds with a lot of specifics. And so this is what's going to be passed into any which gives you a lot more control. One of the challenges with the customization frame is that you want it to fire 60 times a second. So you only have 16.6 milliseconds to get in, do everything you're going to do and get out. And so we need a measure of time in that space that's more specific than 1.16 of the world. So high-res timer gives us that. We're going to be adding that and talking about how you can detect that this new value is being passed in. Basically, the perks that we're going for is just to see how big of a number it is. If the number is under one E12 then you can be assured that it is the high-res time there, rather than milliseconds from 1978. Interesting. You can also detect if there's a period in it. Can everybody join us in a half? Please mute. By the way, thank you. That's a great change. I think more percentage is always good. We should come up with some cool demos or something that shows the differences between the old versus the new. I didn't even realize that there was an argument. A lot of people do like they'll do like the time now is this. Are you getting in their method? Please take now. Yes, you don't need to. Right. So I think original versions there's discrepancies between Firefox and WebKit for a while, right? There wasn't a time stamp being passed or something in this sense maybe standard that some of that. No, Chrome didn't pass a time stamp for the first three versions. But now we do. There was originally an idea for an element argument where you would scope and say that this request animation is only for like this canvas and nothing else, but we ended up using the stack as the scratch. And I also got a question over stack overflow this weekend. Someone was like, actually it was on Reddit. And someone was like, I have a request animation frame or RAF running for Raphael and I'm also using another library or something that's using RAF as well. Is it okay that I have two RAF calls going on? The answer to that is yes. Request animation frame is actually designed with that use case in mind that you would have multiple animations going on. It would coalesce your request animation frame callbacks and congeal them into a single frame that it throws up. So that way, let's say So both of them in some need to be less than two seconds in that case? Ideally. Ideally. That's just a bit of extra things to think about. Yeah. That's true. Cool. Did you see there was this blog post about some guy that didn't like the current request animation frames? Yes. Dominic who made ImpactJS. Smart dude. Really good post. And ended up having a great discussion in the comments about it. And he favored a more set in or more type setup. I think there's a lot of cases where a set time up like API works better. It would be cool if we had both but it makes sense. It seems like it would be awesome if there was an argument we could pass in. I'm going to call myself a certain amount of time. People ultimately would do is they set a delta use time date that now to make a calculation request animation frame. I guess it's not really a big deal because I thought that this was the rate to change. I'm kind of excited. I never do anything. I just call the same thing. Which is just extra stuff. Yeah. Okay. It's enough. We have time for one more question? Let's do one more. Go with this one. The moose man from the internet. Cool. So his question is why are there new HTML styling elements being created such as mark and section while older ones are being deprecated? Center strike are good examples. We can just do this in CSS. That's a good question. It is a great question. I tend to agree with the mark. Mark's a little interesting. Mark? I had an argument about mark last weekend. I'm Mark's an okay guy. Let's see. I think the goal of a lot of what the new elements in HTML5 is that they all have semantic meaning. The purpose of the B and small tags in HTML5 have been changed. They now have some new semantic meaning. They mean footnote text supplementary annotative information whereas before it just meant we'll be in a small box. The semantics of these elements have changed. M tag is to be emphasized but spoken in a different voice more specifically. Mark is for the best use for highlighting a piece of text that is relevant to the search that the user just did. If I was writing an app where I search across a piece of text and then I want to highlight their search results, that's what Mark is ideal for. The reason why that makes more sense. When there's semantic meaning applied to elements, that means that screen readers can better highlight that to their users. And also hopefully search engine as well. So the whole thing is enhanced semantics means that we can have better support for beyond just people looking at a page. And so it's taking the value out of the visualness and into the meaning. Curtis? Yeah, sorry. I wasn't sure because I switched microphones and I couldn't talk before. So I think that also Mark doesn't have any implicit styling in the browser. So it's just that I'm not sure I think that people used to use Stan for the matter, but I think last time I played with it, I didn't recall it had any implicit styling. I can change it now. I can try now in DevTools if you want. I thought when I looked at it before that WebKit does have a default styling for Mark, I think it's sort of a highlight yellow. But you can absolutely change it because it is just an element you can style anyway. Yeah, and it just like they pull out all the changes, implicit, everything, all elements. So if you want you can restyle everything to be everything else. But that's not what you're supposed to do. So there is one of the cool things is you can actually in both WebKit and Mozilla, you can just look at the source of the browser. And there's the default user agent style shoot specifies what the story is like that dibs should be display block. It's pretty cool to read. And so I just looked it up and Mark in WebKit has a default background color of yellow and the color of the text is black. So there's some default styling and in fact normalize.css will give that styling to you for free so that if you're using normalize which is in Twitter bootstrap and HTML5 boilerplate you'll be getting the same rendering for a lot of these HTML5 elements across browsers. It's real good. Cool. Well we are all out of time, yes? Yes, we're all out of time. Thanks for joining us. Thanks for dealing with our technical difficulties but it's really great to answer so many questions. And happy to have you guys join us for the next time. Yes, I want to remind you guys on Thursday I'll be part of this hangout. We're doing a hangout at 1pm Pacific time on the track elements. The new speaking of semantics, the new track element for audio and media elements. So that'll be cool. We're inviting Sam.nin and spew the WebKit engineers working on it. And just to give a taste about track a lot of people think the track is just for subtitles but it's not. So much more. There's some really cool clever hacks of combining JSON in kind of a subtitle file to actually trigger off events similar to what you've seen in popcorn.js and things like that. So there's some really fun stuff to do with track so it'll be a great time. Yeah, we'll call those cool demos. So join us 1pm this Thursday for the next time. See you next time.