The demos progressively add features, from left to right lighting, to glow effects, to a multiple colored lighting extravaganza! Very nice work Francois!

I can't believe none of us knew DOM2

This is how a tweet from @SubtleGradient, re-tweeted by @jdalton, has been able to steal my rest tonight ... and this post is the consequence ...

What's new in a nutshell

There is a W3C Recommendation about addEventListener behavior, which clearly specify the second argument as an EventListener.
The new part is that no library I know has ever used a proper EventListener interface, preferring the classic attached callback instead.

Benefits

The most common case that may disappear is well explained in this MDC addEventListener page.
Rather than bind inline or add anonymous functions to make our object call context preserved, we can simply add an handleEvent method to whatever object and pass it as EventListener.
Moreover, being close to full ES5 support and "use strict" directive where arguments.callee disappears, it may be more than handy to be able to perform such operation:

An opened door for custom listeners

As I have recently posted, custom listeners implementation can be truly handy when we are dealing with events driven applications, but as soon as I have read the tweet, I had to rewrite a fresh new way to create a listener. Please note that following code is assuming that the browser supports both DOM Level 2 and Array extras, which is true for all modern browsers, mobile oriented included.

Here a usage example:

Advantages

• both evt.stopPropagation() and evt.preventDefault() are not able to break the current notification of all attached listeners, if added to the same node, and while the FIFO order gives to the node "owner" or creator the ability to pollute the event object with some flag such evt.pleaseDontDoAnyOtherActionHere = true, not every library, script, or framework, may respect or understand this flag. With custom events we can adopt better strategies to actually avoid any other operation if this is what we meant, because we arrived before over the node and we may like to be that privileged
• being custom, we can also decide which argument should be passed for each callback, simplifying most common problems we may have when dealing with listeners
• we can better decouple DOM and listeners, being able to remove whatever amount of callbacks simply calling once node.removeEventListener(evt.type, this, false); inside any kind of notification
• being based on standard and modern browsers, we can use native power, in this case provided by forEach and indexOf operations, so that performances will be best possible
• thanks to automatic context injection, we can still reuse callbacks for different listeners, through bind, or simply considering the current context once called (or in this case the third argument by reference, if the context is different)

Last but not least, if we would like to fire an event we can bypass DOM initialization using handleEvent directly, e.g.

Compatibility ?

Apparently both W3C behavior and provided examples are compatible with every modern browser with DOM Level 2 support, and I believe this is great.
The only one behind here is IE9 pre 3, but again @jdalton has acted at speed light, thanks!

The main concept works on using CSS3 for the radius, making a round circle view point. This contains an iframe which is the exact same content. Using CSS3 again I scale the content in the iframe so that it is x2 larger, allowing smaller content to be read. The magnifying glass is also controlled by simple keyboard combinations which allow for show / hide and zooming in and out. Future plans will include Chrome and Firefox add-ons meaning that an iframe will no longer be used and can then use canvas to get the page content, which can then be updated as the page content updates.

Check it out in action:

The environment is mapped using cube mapping. I store all the values of the cubemap as floats. I increase the definition range by multiplying all values bigger than 0.95 with 2. This makes sure that the bright parts of the image are also very bright in the reflections. You can think of this as faking hdr. I do not calculate any lighting, it is all coming from the environment map. To make the animation look a bit more fluid and hide the aliasing I apply some fake motion blur by blending the current frame with the previous one.

You can check out the code to see how it all works. What frame rates are you getting?

Greg Murray has an early beta of a fun sample app: HTML5 Fish Tank. The app lets you build out your fishes, and then place them in the tank.

It puts the low level Canvas and CSS3 transitions/transforms to work.

E.g.

The fish animation is driven by code like this:

A fun little way to start your day.

Jacob Waller created an addictive word came in Golingo. What sets it apart?

• Not a single line of Objective-C written, courtesy of Titanium Mobile
• Only one (!) image ingame - the rest is CSS3 magic
• Fluid gameplay thanks to CSS Transitions and Animations
• All logic using pure, beautiful JavaScript
• Multitouch draggables using iPhone Touch API
• Logic encapsulated using Low Pro - meaning split screen mode was easy pie
• jQuery 1.4.2 for development speed (and sanity of developer)
• CouchDB as highscore storage, with storage logic in JavaScript
• Predictable randomness means replayable games, all courtesy of excellent seedrandom

Jacob dives into deeper into the full tool chain that he used in his post about open sourcing the code behind the game. That's right, he wants you to fork it and do something amazing with the game. Pretty awesome if you ask me.

His tool chain:

• Titanium Mobile
• CSS3 with Webkit extras
• jQuery 1.4.2
• Low Pro for jQuery
• Glyphish icons
• Uri-parser
• Swedish word list
• CouchDB
• Flag icons

He then goes on to talk about the initial construction of the game:

Most of the actual game was made in a few weeks time, but from scratch to published app it took almost six weeks of part time work. A lot of this time was spent banging my head into various walls. Again, Titanium is great, but it's a young framework with all the kinks that follows. There has been quite a few bugs, and the documentation hasn't always been up to date - but this is much better nowadays. What more - since most other developers are as clueless as yourself, It's been hard finding good resources and getting help. I did however get a trial for Appcelerator's Premium Subscription, with 48-hours guaranteed response, and I must say it's really good stuff. The developers themselves answers all your stupid questions and relieves most of the wall banging. If you can afford it, go for it!

By releasing the code for Golingo, we hope to relieve some of the headaches surrounding developing packaged HTML5 apps. I do not say that it's not full of faults, because it is, but at least it is a working example full of faults. Please don't hesitate to dig through the code to see what is going on. We believe we've solved some common problems that you too will run in to when using Titanium, for example transparently calling native functions from a webview (and vice versa) using callbacks and trickery. Here's a quick recap of that:

• Connecting Titanium Contexts
• Low Pro like a low pro: $('<div/>').attachAndReturn(Letter, this, letter, specialLetter);
• Sexifying: including templating with mustasche

Thanks for the great info and resource Jacob!

It's Friday. How about some Spiderman. In CSS using animation.

"Guess who's back? Back again....."

The JavaScript slim shady himself.... Dustin Diaz (formerly of YUI - Google, now of Twitter) has taken some time out for his busy coding at Twitter, and photography awesomeness to get back to some JS blogging.

Dustin has written up a pattern that he used in Twitter @anywhere, the asynchronous method queue chaining pattern:

One technique you don’t often see is queueing up a chain of methods, asynchronously, by which functions can be linked together independent of a callback.

Let's start with the end result. What if you could do this?

You grab content, tweak style, and change the DOM, all in a single chain. Or, fetch a tweet, add href, filter it, and then change the DOM.

Here is an example that does this.

The internals of the Twitter example become:

Nicely done my friend. Looking forward to more JS goodness inspired from your Twitter work.

There have been a few interesting posts recently. Trotter Cashion kicks things into gear as he declares his love and then goes on to show how you can unit test Raphael with some mocks.

Then we learn how easy it is to write a "plugin" a la jQuery, such as adding an arrow abstraction:

And finally, play with a great example usage thanks to Thomas Fuchs.

If your application involves reading large documents, books, or articles there's a good chance you've had to put some serious effort into building a nice reader. At Nextpoint, we build web-based litigation applications for discovery and evidence management and our users often find themselves reading very long documents. We decided to build a nice scrollable reader because we believe it's the most natural way to navigate through large documents in a browser and because we needed to have other meta-data and functionality remain in static locations surrounding the document. You may have seen something similar at Google Books or Bing image search. With potentially thousands of pages and images in each document there are some very interesting technical challenges that arise so we'll walk through how we tackled them.

Challenges

Documents can be thousands of pages long and consist of imaged pages making document sizes quite large. They vary in resolution and range in quality from poorly scanned images to rich graphical diagrams. Because many of the documents contain poor quality images we also implemented a zoom feature which leverages our Theater document presentation tool, previously covered here, to expand images on the fly. And finally, as always, it needs to be fast when scanning or following search hits throughout the documents.

Our approach

Our basic reader structure is a container DIV styled with "overflow:auto". The initial markup is very lightweight with JavaScript doing all of the heavy lifting. The basic metadata for each page (page number, image size, and URL) is loaded in sets of 20 on the initial request and then using ajax while navigating the document. The IMAGE elements are created on the fly as pages get near the visible area. Those are the basics. Here's a brief demo and then we'll hash out some of the details.

Preparing the scroll area

There are two main methods for incrementally loading -- expand the scrollable container as you load more data (such as Bing image search), or pre-set the height of the container for the entire content (such as Google Books uses). We chose to pre-set the height by drawing very simple placeholders for each page initially. These consist of a "Page 123" label and a div with the actual or estimated page height (depending if we've loaded that page's metadata yet), which will eventually act as a container for the page.

This allows the user to scroll through the document immediately, without causing confusion as the content jumps around due to the scrollable content getting "taller." We keep the placeholders as simple as possible so the initial setup and rendering of the page is quick. After drawing the placeholders, we cache the offsetTop of each placeholder in an array so we can quickly determine the "current visible page" by comparing the scrollTop of the container DIV to this array. Finally, we set up event handlers to watch the scroll position. We trap the onScroll event and use it to update the current page number in our navigation bar, and then separately a setInterval callback that checks if the user has "landed" on a particular page for long enough (~200ms) that we should load its images. (This allows for quick scrolling through the document without unnecessarily loading in-between images.)

Loading content as you go

When the user lands on a particular page, we first try to load all the currently-visible pages, then we pre-load a few of the surrounding pages, so those will be ready when they scroll down further. Loading the pages consists of checking whether we've already loaded the page metadata for it -- and if not, making an ajax call to load that plus 20 or so nearby pages' metadata. Once we have metadata for the page, we update its dimensions and create DOM content for the labels, a checkered "loading..." type background, and the page image itself. We use a bit of a trick, to help make sure the images for pages in the visible area load first, by setting all those up, and preloading the surrounding pages in a separate method on a 1ms setTimeout callback.

This lets the browser start loading the visible pages before adding the surrounding ones to the DOM. Also, if we update the dimensions of the page (because an initial estimate of height was a bit off), we re-cache the list of placeholder offsetTop values. Beyond that, the main UI piece is navigation. Next- and previous-page buttons are easy, along with a box where the user can type a page to jump to. Since the offsetTop of each page is already in an array, you can just scroll there and let the onScroll handler update as usual.

Gotchas

As usual, the Web has some quirks that corrupt this simple concept. One is that the browser doesn't render the DOM changes until Javascript events finish. So we end up using that setTimeout trick more often -- in particular, right before updating the cache of offsetTop values. It's always like this: setTimeout(updatePlaceholderCache, 1). Another is that, because we load the images from Amazon S3, there's a possibility of the URLs expiring if the user is reading a particularly long document, so we have to add an expire time to the page metadata, and check that before loading the page image. If it's expired, we have to re-request the page metadata before displaying the image. Also, we want a page to be considered "current" when it's scrolled most of the way into the visible area (when just the tail of the previous page is visible at the top), so whenever we check what the current page is, we add a slop amount to the container DIV's scrollTop value. Finally, since the container DIV may sometimes be larger than a single page of a document, it could be impossible to scroll down far enough that the last page is considered "current." So we add a spacer at the bottom of the container, just tall enough to let the last page scroll into the current position. (While not strictly necessary, extra features such as a "link to this page" option wouldn't work for the last page if it never was seen as the current page.)

A Line of Code is worth a Thousand Words?

For those interested in more of the details, we've put together a more generic version of the code, available here. No setup necessary and you'll be able to explore the basic concept without the Nextpoint dependencies.

Thanks for reading and happy scrolling!

Sergey Chikuyonok gets his Philips Ambilight foo on as he created a HTML5 video + canvas sample that mimics the TV effect.

As the video runs, a snapshot is sent over to JavaScript land where colors are worked out:

Then, two canvas objects are placed, one on each side, of the video itself.

Paul Irish and Jonathan Neal have created a fun example of various CSS tweaks that you can make, and see the results instantly.

CSS3, Please! lets you play with fancy new rules such as:

• border-radius
• box shadow
• gradients
• rgba support in backgrounds
• transforms
• font-face

Really nice way to make tweaks inline in the page..... nicely done. Hope to see some other examples out there :)

Anthony Calzadilla has a fun Friday example for us. He has a tutorial on how he animated an AT AT using CSS.

He goes over the different areas and how he uses animation and transforms.

For example, the head of the beast:

See addmap.js in action below - all the content in the green box is generated from the paragraph of text above it. You can try it out for yourself by clicking the screenshot.

Using addmap.js is easy - sign up for a Google Maps Key and provide it as a configuration parameter. Then call the analyse function with the ID of the element to analyse as the parameter:

The script uses YQL and Yahoo PlaceMaker under the hood, for more info and updates on this, check the blog.

And what about @zacharyjohnson? He put snow all over the network via its Winternetizer, the first snow proxy I have ever seen.

Am I missing anybody? ... sure, me!

Above FX is dedicated to all Ajaxian readers and created via some CSS3 rule handled via JavaScript for a partial cross browser implementation. WebKit based browsers, included Android and iPhone, plus Firefox 3.6, should render properly, while the most interesting thing, snow a part, is that for the first time rather than browser sniffing, I have implemented a sort of "screen resolution to power computation" sniff:

Probably not perfect, the aim is to avoid same number of flakes in mobile devices, netbooks, or desktop PCs.
I guess one day we'll have exposed CPU model and RAM amount as read only userAgent properties, so that all new effects could avoid stress for web surfers.
Something like System namespace in ActionScript, with capabilities for audio and video and extra info about the current navigator ... maybe just an AS to JS bridge 'till that day? We'll see, today the important thing is simply one: Have Fun!

Guillermo Esteves presented a piece of history translated for tomorrows browsers:  the Star Wars Episode IV opening crawl in HTML and CSS:

Unfortunately, the live experiment is not suitable for all browsers and the ideal target seems to be only OSX 10.6 and its latest Safari browser but it partially worked via Google Chrome as well.

Something To Learn About

We are moving complex computations into our favorite "decoration layer": CSS
We also want as much control as possible, and the above concept is brilliant to understand how to tame CSS transitions.
This example includes new and different techniques. Here is what I found interesting:

@font-face

OK, this is not new at all, but in this case I could not find a single valid reason to avoid the original font: a must! The only point here is that the author could have saved a bit of bandwidth via pre-deflated or gzipped fonts rather than serving them without any apparent optimization.

It's a shame there is not the real STAR WARS font as well but just an image ... anyway, let's move into more concrete stuff ...

Perspective

The stage is the block element where the magic happens. The perspective property is able to give us a "deep space" 3D feeling making closer objects look larger than further ones. Via origin modification we can decide where things should disappear, in this case a bit higher point than a central 400px, to create a similar atmosphere respecting the movie choice (and I guess to make content readable as well).

Iteration-count and Custom transitions

Far far away is the initial text. As we can see with other browsers as well this appears and disappear in 6 seconds.
This fade-in-out happens just once, so at the end of the effect, unless we won't modify the node class, the element won't be displayed anymore. This is what the animation-iteration-count property does while next snippet is the fade-in-out customization:

Via keyframes <transition_name> we can blend FX linearity deciding the amount of opacity, or other properties, at certain moments.
A generic normal linear fade-in-out would be visible 100% only in the middle of the transition while in this case it is forced to be visible for 68% of the time, making fade in and out still homogeneous but controlling the full opacity for longer.
We could have used an ease-in-out effect over opacity property to obtain a similar result but I find definitively more interesting this kind of approach.

Warp Speed: Action!

Thanks to Z axis transitions the initial STAR WARS image can appear and disappear using again a customized FX:

Above mix of webkit properties suggests me that new JavaScript libraries will use run-time actions to CSS transformations soon, rather than hard and manual JS computations over computed styles or similar expensive operations.
We can control delays, we can stop FXs removing classes or simply overwriting existent directives and, moreover, we can split the CSS itself into logical parts as the same @gesteves did, putting custom animations all together: good hint!

The Crawl

Last piece to check out is the text plus its title.

The Mythical Song

Well, this demo could not miss a proper audio element:

Apparently the used compression is truly good and the sound loud and clear. But who is in charge to start above song?

JavaScript

Quite hilarious all this demo does not basically need JavaScript at all except for an audio delay forced via interval:

If we have a good broadband connection and we are sure in 12 seconds we have buffered enough audio, the synchronization between JavaScript and the transition delay is almost perfect and the demo experience unique.

It is great to see this work, and I look forward to seeing what he comes up with next. It feels that with HTML5, CSS3, and the Web.Next we will be able to be much more creative. Finally, it's December, I can already imagine a CSS3 based snow effect for our pages ... no?

The post is complete with examples and explanation over PHP, CSS, jQuery, and finally jQuery UI.
So what is the problem? The title: An Awesome CSS3 Lightbox Gallery With jQuery

At the end of the day, the total size of the demo is massive, compared with what it offers, plus the only piece of CSS3 in the stylesheet is a box-shadow and a rotation via -webkit-transform.

Is That It?

If we can define awesome a basic usage of CSS3 requiring both jQuery and jQuery UI to create a Gallery, included a server side language, how can we define my latest experiment realized in half an hour and without using JavaScript, PHP, or whatever programming language at all?

The answer is simple: CSS3 and we can read how I did it via the not-minified and hopefully well commented css file.
OK, agreed my page is dynamically fake and a proof of concept, but honestly, which title would consider appropriate for above example?
Thanks in any case to Tutorialzine for the interesting step by step explanation and to let me try above experiment which works with latest WebKit, Chrome, Safari, and somehow with Firefox, I've not tried the nightly, and Opera as well but in latter cases without transitions.

P.S. for those with poor computation performances like me, here there is a fluid concept variation ;-)

Elias Klughammer has implemented the Juggernaut push server in a Cappuccino app.

Always nice to have an open source bare bones sample app for a marriage like this. Nothing beats looking at the source.

This becomes disastrous when a company tries to reach developers with their product. Normal marketing and PR stunts normally fail to get us excited. To work around this issue, clever companies allow developers to move into a role of developer evangelists.

A developer evangelist is a spokesperson, mediator and translator between a company and both its technical staff and outside developers.

This is my job at the moment, and I was asked by people I trained if there is a handbook about the skills needed to do this job, so I wrote one.

Check out the The Developer Evangelist handbook

The handbook explains several things:

The handbook is Creative Commons and free to use. I am working on getting a printed version out, too.

Brian Arnold created a fun sample drum machine simulator using HTML5 <audio>.

That's not all Brian is working on:

I'm also working on something like the ToneMatrix or Tenori-on (Flash and actual devices, respectively) in pure HTML/JS. It works too, but the sounds aren't exactly designed to be great together (it's currently working on a C scale) and so if you're careful, you can get some decent sound but otherwise, it'll hurt your ears.