HTML5 Rocks Updates

I'm not too familiar with it myself, but if I had to hazard a guess it's because setting an element to display:fixed breaks it out into its own root stacking context[0], and browser zoom affects every stacking context[1]. Would love to hear from someone who's actually familiar with what's going on though. [0] http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-posit… [1] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z…

For anyone wondering "why do we need jQuery plugins for simple things like this?", you may be interested in position: sticky. Here's an article: http://updates.html5rocks.com/2012/08/Stick-your-landings-position-sti… Worth noting that this hasn't actually been adopted as part of the spec, but it certainly would be a welcome addition in my opinion. This plugin looks well-done, but I'm looking forward to a day when we don't need JavaScript to control layout like this.

To review, it would seem that while you have a blog post from ian hickson making a passive reference to deprecating smil. Indeed he followed up by removing the feature from the ACID3 test. But the damage was already done: evidence of actual standards activity and implementations from as recently as June 2014 show instead an active merging of css animation with svg animation into a single consistent model called "web animation" [1] the implementation of this merging effort in chrome's blink rendering engine [2], and a rationalisation for this webanimation effort that promotes not a removal of the svg animation features (which are already implemented in everything but IE), but an expansion of their powers, being advocated by both google and mozilla [3] Just because IE is lagging behind doesn't mean this feature is cut. Just because Ian Hickson says the feature is deprecated doesn't mean that it is, or that browser devs will follow whatever he says. What it does mean though, is they are attempting to cut the feature's dependence on "SMIL", while retaining the currently implemented features. so I think that whatever works in browsers now, you can more or less rely on that working in future browsers as well. So yes, my suggestion is still useful and it's still awesome. And if you use css animations inside the svg (which totally works) instead of svg-smil animations, you can even get it working in IE10 [1]: http://dev.w3.org/fxtf/web-animations/ [2]:…

Please post the full code and configuration you are using. Your results don't match what I have seen nor the expected results. Some notes: - Socket.IO supports several different transports, including AJAX. To have persistent connections you need to make sure that you are using WebSockets (native or Flash) as your transport. Are you certain that you are actually using WebSockets? Socket.IO attempts to automatically pick the best transport and unless you verify, the only difference you will see is lower performance. - You need to compare Socket.IO using AJAX as a transport, vs raw AJAX so that you can control for how much overhead the Socket.IO library (client and server) is adding to the test. Actually, comparing all the Socket.IO transport options would be useful. Doing a Socket.IO disconnect is not a good way to trigger a non-persistent transport in Socket.IO; you are likely causing both client and server to do a bunch of extra cleanup (Socket.IO has some advanced features that require tracking connections/channels/etc). - If Socket.IO is using WebSockets as your transport, then your "Socket.IO non-persistent" test is still testing WebSockets, not AJAX or one of the other real non-persistent connections. I would not be surprised that WebSocket connection setup and teardown might be slightly slower than AJAX connection setup. HTTP connection setup has been around since the beginning and had a lot of time to be optimized. WebSockets are relatively new and connection setup…

Chrome for Android has a feature where if you visit the same site a few times in a two week period (or some sort of heuristic like that), the site can have it prompt you to add it to your homescreen: http://updates.html5rocks.com/2015/03/increasing-engagement-with-app-i…

Fortunately, Transferable Objects (which didn't arrive until a bit after Web Workers) solves this :) http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-F…

> That's just a stupid choice made by (so many) web developers. Sometimes it's stupid, sometimes not. Disabling zoom removes the 300ms delay added to most interactions on mobile devices [1]. You can alternatively use fastclick.js [2] or swiftclick.js [3], but that's an extra lib/http request to load. [1] http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away [2] https://github.com/ftlabs/fastclick [3] https://github.com/tmwagency/swiftclick

As far as I can figure out, on chrome it's just a web service -- and doesn't work on Debian Chromium as they stopped shipping google api keys (which makes sense, part of the point of using chromium over chrome is to have some measure of independence from google). Just thought I'd mention it here, in case anyone else were about to run off and try stuff like: http://updates.html5rocks.com/2014/01/Web-apps-that-talk---Introductio… only to be disappointed :-/ Note that on Debian/Ubuntu you can for example do: sudo apt-get install festival echo "I speak nothing, because I no verbs." | festival --tts if you need to get your computer voice fix.

This is inaccurate. Nowadays, the 300ms goes already away if you set the meta viewport tag with width=device-width etc [1] [1] http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away

You can now transfer typed array data using the newest postMessage API. http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-F…

Note that Android no longer applies the 300ms delay regardless of viewport scalability. http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away There are a number of plugins to remove the 300ms delay from other touch browsers. Here's one: https://github.com/ftlabs/fastclick

Check out this demo: http://html5-demos.appspot.com/static/webaudio/createMediaSourceElemen… - article: http://updates.html5rocks.com/2012/02/HTML5-audio-and-the-Web-Audio-AP…

If you use Web Workers, you are going to have to use message passing. There is no other way to communicate with a Worker. There are no truly shared objects between js threads. However, it is still possible to post binary data to a worker and back again without making a copy of it, by using Transferable Objects [1]. You simply have to provide an array of the arraybuffers to move as the second paramter to postMessage(). The caveat is that the data is no longer available to the posting thread after the postMessage call (TypedArray length will be zero). [1] http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-F…

It uses the Webkit Speech API[1], and (from what I can tell) it's constantly listening[2] [1]http://updates.html5rocks.com/2013/01/Voice-Driven-Web-Apps-Introducti… [2]https://github.com/TalAter/annyang/blob/master/annyang.js#L91

You could use an transferable typed array buffer instead of copying an array of integers from the worker thread. Looks like the array is under 4mb, so copying doesn't take very long, and you only do it once, but if you're going to use a worker you might as well. http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-F…

In my humble opinion the best solution for layouts is CSS is the CSS Grid Layout Module[1]. Both powerful and easy to grasp. Sadly, it works only in IE (from version number 10, I believe)[2], but others[3][4][5] are getting there. And, of course, there's a polyfill[6]. 1) http://www.w3.org/TR/css3-grid-layout/ - specification; 2) http://ie.microsoft.com/testdrive/graphics/hands-on-css3/hands-on_grid… - examples; 3) http://updates.html5rocks.com/2014/03/Get-on-the-CSS-Grid - Chrome/Opera/Blink; 4) https://bugs.webkit.org/show_bug.cgi?id=60731 - Safari/Webkit; 5) https://bugzilla.mozilla.org/show_bug.cgi?id=616605 - Firefox; 6) https://github.com/codler/Grid-Layout-Polyfill - JS polyfill.

I'm doing: https://github.com/jawj/pigeonsim (now with speech recognition + geocoding, supporting a beam-me-up gesture). Web speech API: http://updates.html5rocks.com/2013/01/Voice-Driven-Web-Apps-Introducti…

Would it be possible to use this to render the current state of a canvas to the console? That's something I'd find very useful for debugging. Edit 1: Looks like they build the memes exactly that way. It still needs to convert the canvas to a data: url first, however, which might be a bit slow? Edit 2: Looks like there might be a better, but non-standard and non-portable way of achieving that in WebKit browsers: http://updates.html5rocks.com/2012/12/Canvas-driven-background-images

this is essentially built into css now, with position: sticky http://updates.html5rocks.com/2012/08/Stick-your-landings-position-sti…

For people who are not familiar with Devtools "A Re-introduction to the Chrome Developer Tools" by Paul Irish http://paulirish.com/2011/a-re-introduction-to-the-chrome-developer-to… "7 MINUTE VIDEOS: JAVASCRIPT CONSOLE PROTIPS & NEWISH DOM APIS" by Paul Irish http://updates.html5rocks.com/2011/09/7-minute-videos-Javascript-Conso…

For the second issue, please read http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-posit…

Came here to say this. http://updates.html5rocks.com/2012/02/Detect-DOM-changes-with-Mutation…

The pointer lock API should be in Chrome and FF. http://updates.html5rocks.com/2012/02/Pointer-Lock-API-Brings-FPS-Game… https://bugzilla.mozilla.org/show_bug.cgi?id=633602 https://developer.mozilla.org/en/API/Pointer_Lock_API

Quick, painless, and makes mailto useful: http://updates.html5rocks.com/2012/02/Getting-Gmail-to-handle-all-mail…

And if you want to open mailto links in Gmail with Firefox (and Opera I guess): http://updates.html5rocks.com/2012/02/Getting-Gmail-to-handle-all-mail…

For those interested the API it's using is navigator.registerProtocolHandler. http://www.w3.org/TR/html5/timers.html#custom-handlers http://updates.html5rocks.com/2011/06/Registering-a-custom-protocol-ha…

well, this method downloads a file without a .png at the end (and most users are overwhelmed with the task of renaming a file) think there is something coming with BlobBuilder and FileSaver, but i haven't hat time yet to give it a spin http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSa… and an example here http://updates.html5rocks.com/2011/08/Saving-generated-files-on-the-cl…

The abuse considerations were what led us to implement the engagement check. An API for this would absolutely be spammy. If everyone is going to be calling it on every page-load, and if the browser is (predictably) not going to allow that to show every time (see window.open()), then why provide an API when we could just treat meeting the criteria we'd look for anyway as the same thing as calling such an API? That's what the Chrome system does: you've implicitly called "addToHomescreen()" on every page load where your app meets the criteria. When we allow it to show is still mediated by the browser. Chrome 44 is going to allow a measure of control: http://updates.html5rocks.com/2015/03/increasing-engagement-with-app-i… The event is cancelable, meaning that if you don't want it to show on a particular page, it'll trigger again on the next. We'll also be adding a way for you to delay the load; cancel and re-trigger inside the same page. The way to think about it is that you sometimes get a golden ticket. We'll give you the ability to spend it when you want in the near future, but making you do an API call when the intent is already clear just seemed like bad design.

So, there is a cheap way to communicate between the DOM thread and web worker threads. It's called Transferable Objects. The technique involves postMessage()'ing a Typed Array's ArrayBuffer as your message payload. Rather than making a copy of the bytes in your sending thread's Typed Array, the byte buffer is "detached" from the sender's ArrayBuffer and "attached" to a new ArrayBuffer on the receiver thread. This allows you to do huge bulk operations on a worker thread, generating megabytes of data for the DOM thread and not taking a penalty of allocating memory, copying the data, and garbage collecting a big allocation on the sender thread. Transferable Objects are not as useful as, say, being able to access the DOM from a worker thread. But there are many tasks that ultimately feed DOM updates, are data intensive, and could be mostly offloaded to a worker thread with the final update payload fed to the DOM thread via Transferable Objects. http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-F… The DOM/Layout/CSS is a crufty document engine. Is it reasonable with today's hardware to have a 60Hz scroll rate benchmark of quality? I think expanding mobile main memories and CPU advances this decade will make it more reasonable. How about framelocking us to 30Hz on mobile, could we be satisfied with that? Makes me wonder if there is a way to framelock a browser scroll with requestAnimationFrame(). -- edits clarifying ArrayBuffer

First I would ditch any notion of teaching back end programming and focus on front-end only [0]. The things you can do with, and are required to learn and master to be good with, HTML/CSS/Javascript are so extensive and deep that alone could be overwhelming to people new to web development. So, first and foremost just focus the course on frontend technologies (and feel free to use things like Coffeescript or Clojurescript instead of Javascript, they probably make better teaching languages than the wtf-laden JS). Also, if 2/3 are non-CS majors, you're going to need to teach basic problem-solving and analytical thinking skills. Teach and reinforce the basic problem solving process of taking a complex problem (or programming objective) and breaking down into its component parts, solving each, finding multiple solutions if possible, then building it back into a whole again. Set expectations of multiple possible answers, of hacking at the problem till you start grokking it, etc. It's not about getting that one right answer, it's about getting something that works then continually improving it. Learning programming carries a lot of frustration which can be very off-putting and demoralizing, so ingraining the expectations, problem-solving skills, and habits needed to overcome that is crucial (and also a super general life skill). Look into using platforms designed for teaching like Processing [1] and its JS version Processing.js [2]. Also see if you can find…