Browsing Posts tagged html5

Update - Feb 2015

After implementing Scroll n' Scrub on one of our own websites here's a few things I learnt along the way. In the end we opted for a video piece that was exported into single images as "frames", we reduced the frame rate and heavily optimized the images for decreased image count and faster load times. Very similar concept to animated "flick books". Different frame on each page, as you flick through the book the illusion of animation is created. In this analogy, scrolling is our paradigm to flicking through the pages.

The hardest part was seamlessly getting the images to load in the background as the user scrolled/animated. We didn't want to pre-load all 320 images upfront with more traditional Javascript, it kind of defeated the purpose of a seamless animation. In the end we opted for a "double buffering (Slide #25)" technique using the canvas tag. Two canvases are created, one hidden/off-screen; the other being the actual canvas the animation takes place in. Loading images into canvas is surprisingly easy.

Animation was handled through Javascript's requestAnimationFrame(); (rAF) method, but a polyfill was used for cross browser compatibility. rAF has the advantage of leveraging GPU instead of regular client-side processing/CPU.

Some simple Javascript scroll calculation was used to compute user scroll as a % of total scroll, based on total number of frames. As the user scrolled images were preloaded into the canvas off screen and painted onto the main canvas once they were loaded. This had the benefit of reducing "black-outs" or "tearing". These were issues we came across using regular JS preload techniques and then injecting to DOM. If an image (frame) had only half-loaded as the (user) scroll requested it, it resulted in some undesirable flickering or "blacking out". With the canvas technique, the image was only rendered once fully loaded creating a much more seamless animation.

We also added in some gravity to the scroll "Kinetic Scroll" for good measure based on this work by Ariya Hidayat, it uses the same computation as the iOS kinetic scroll.


Scroll n' Scrub™. A phrase I feel sums up this technique beautifully, a technique I'm noticing a lot more on the Internet that introduces some really stunning and immersive front-end presentations.

With numbers for IE8 slowly dwindling and front-end support for this browser falling, front-end developers can now really begin to look forward to some true cross-browser HTML5. IE9, the lethargic example of modern browsers, finally allows front-end developers to introduce some of the more exciting features of HTML5.

This particular technique focuses on the ability to "scrub" HTML5 video using Javascript events such as defaultPlaybackRate(), playbackRate(), and currentTime(). (

The concept is simple. Take a well directed, orchestrated video. Hide the controls and turn the vertical scroll-bar into the play seek bar. As a user scrolls the video plays forwards or backwards to create a truly immersive experience.

Combine that with some well-timed and placed div overlays, some parallax action and you have some really compelling webpages.

As part of the B2G (Boot 2 Gecko) or, as it's more commonly known, FirefoxOS project (Mozilla is creating an HTML5 operating system), they have created the pdf.js library.

pdf.js is an HTML5 technology experiment that explores building a faithful and efficient Portable Document Format (PDF) renderer without native code assistance.

pdf.js is community-driven and supported by Mozilla Labs. Our goal is to create a general-purpose, web standards-based platform for parsing and rendering PDFs, and eventually release a PDF reader extension powered by pdf.js. Integration with Firefox is a possibility if the experiment proves successful.


So, you may have been wondering why PDF's viewed in Firefox are no longer using Adobe Acrobat reader, and, on occasion may not be faithfully recreating the artwork originally saved.

A quick check in (address bar) about:config will reveal a (boolean) pdfjs.disabled value. By default this is false.

If you want to revert to the more traditional Adobe Acrobat viewer then you can set this flag to true.

You can set the pdfjs.disabled pref to true on the about:config page to disable the build-in PDF viewer and use the Adobe Reader instead.


It also turns out there is support for this in other major browsers such as IE9+, Chrome/Chromium, and (albeit rather buggy) in Safari.

If you're having issues with PDF's not rendering correctly in the browser just have a quick look for pdf.js and maybe revert back to the native Adobe Acrobat PDF viewer.

Since June 2004 and it's subsequent first working draft in Jan 2008 HTML5 has, and still is, in flux with a stable recommendation finally slated for the end of 2014, but even as I write HTML5.1 is now being drafted.

One of the many great components of HTML5 was the promise of ubiquitous video and audio content. However due to patent issues, mainly H.264 decoding (licensed through MPEG LA acting as a consortium to these majority stake MPEG Patent holders: Apple, Microsoft, Panasonic, Sony, Dolby, Thomson, and Toshiba (*B)), we've been left with somewhat of a pseudo mash-up of native HTML5 video and Flash Video wrappers unless you wanted to support multiple formats in addition to H.264, namely OGG/Theora.

For a while now Flash has offered a TRULY ubiquitous platform for delivering video and audio content. Gone were the days of having to support .mov for Mac and .wmv for PC

Due to costly patents and the Open Source ethos of projects like Firefox and Opera, these projects have had to, until now, leverage open-source video codecs. Which has led to a slower adoption of video / audio tags in HTML5 across the web.

Spurred on largely by it's Mobile efforts (FirefoxOS) Brendan Eich at Mozilla wrote (Mar 2012) a rather lengthy blog post about their decision to finally, now, adopt H.264.

Instead of building software H.264 decoding directly into the browser they've avoided costly patent fees by relying on H.264 decoding at a hardware level.

What I do know for certain is this: H.264 is absolutely required right now to compete on mobile. I do not believe that we can reject H.264 content in Firefox on Android or in B2G (*A) and survive the shift to mobile.

Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives. Failure on mobile is too likely to consign Mozilla to decline and irrelevance. So I am fully in favor of Andreas’s proposal.

What this means, in short, is that H.264 decoding is now supported in Firefox on a variety of hardware except for Mac OS X due to this bug