The HTML5 specification introduces the and media elements, and with them the opportunity to dramatically change the way we integrate media on the web. The current HTML5 media API provides ways to play and get limited information about audio and video, but gives no way to programatically access or create such media. We present a new extension to this API, which allows web developers to read and write raw audio data.

The above quote is from the Audio Data API extension that joins a bunch of juicy developer work in Firefox 3.7.

Thomas Sturm has taken that API and created a spectrum visualization a kin to some of the great work by Scott Schiller (using Flash).

There is a new onaudiowritten attribute:

1.  
2. <audio src="song.ogg" controls="true"
3.            onaudiowritten="audioWritten(event);">
4. </audio>
5.  

that lets you get access to info such as the spectrum:

1.  
2.       function audioWritten(event) {
3.         spectrum = event.mozSpectrum;
4.        
5.         var specSize = spectrum.length, magnitude;
6.        
7.         // Clear the canvas before drawing spectrum
8.         ctx.clearRect(0,0, canvas.width, canvas.height);
9.        
10.         for ( var i = 0; i <specSize; i++ ) {
11.           magnitude = spectrum.item(i) * 4000; // multiply spectrum by a zoom value
12.          
13.           // Draw rectangle bars for each frequency bin
14.           ctx.fillRect(i * 4, canvas.height, 3, -magnitude);
15.         }
16.       }
17.  

Add to that the ability to write audio....

1.  
2. var audioOutput = new Audio();
3. audioOutput.mozSetup(2, 44100, 1);
4.  
5. var samples = [0.242, 0.127, 0.0, -0.058, -0.242, ...];
6. audioOutput.mozAudioWrite(samples.length, samples);
7.  

Nice work all around.

modulr is a CommonJS module implementation in Ruby for client-side JavaScript

Ruby? what does that have anything to do with it? Ah, its from one of those Prototype guys isn't it.... Yup, Tobie is at it again, this time with modulr:

modulr accepts a singular file as input (the program) on which is does static analysis to recursively resolve its dependencies.

The program, its dependencies and a small, namespaced JavaScript library are concatenated into a single js file.

The bundled JavaScript library provides each module with the necessary require function and exports and module free variables.

This can also help sharing that CommonJS code. I recently did just that and had some:

1.  
2. // check to see if you are running inside of node.js and export if you are
3. if (typeof GLOBAL == "object" && typeof GLOBAL['node'] == "object") {
4.     exports.Appetite = Appetite;
5. }
6.  

I just came across this wonderful Gist on gitHub:

1.  
2. var $;
3. YUI().use('*', function(Y){
4.   $ = Y.get;
5.   for(var p in Y) {
6.       $[p] = Y[p];
7.   }
8. });
9.  
10. // test
11. $('body').append("boo!");
12.  

In case you want to use YUI3 but really really like jQuery syntax :) OK, it breaks the whole sandboxing idea of YUI3, but that's a small price to pay, right?

Bass Schouten is a cool name, and the Mozillan has presented Direct2D hardware acceleration.

You have to grab Firefox nightly, do the about:config / gfx.font_rendering.directwrite.enabled game, but then you get to see it in action.

IE9 showed off how they will support hardware rendering, and I am sure we will see more at MIX, but it is very cool to see this across the board.

CSS Transforms/Transitions/Animations are going to feel like butter in 2010!

Works even in IE6

Love that quote from the color picker over at RaphaelJS land. This plugin by Dmitry Baranovskiy gives you an easy color picker in short order:

1.  
2. var icon = Raphael("picker", 23, 23).colorPickerIcon(11, 11, 10);
3.  
4. icon.attr({cursor: "pointer"}).node.onclick = function () {
5.     document.getElementById("benefits").style.visibility = "visible";
6.     var out = document.getElementById("output");
7.     out.style.visibility = "visible";
8.                
9.     // this is where colorpicker created
10.     var cp = Raphael.colorpicker(document.body.offsetWidth / 2 - 150, 250, 300, "#eee", document.getElementById("picker2"));
11.                
12.     out.onkeyup = function () {
13.         cp.color(this.value);
14.     };
15.     // assigning onchange event handler
16.     cp.onchange = function (clr) {
17.         out.value = clr;
18.         document.body.style.background = clr;
19.         document.body.style.color = Raphael.rgb2hsb(clr).b <.5 ? "#fff" : "#666";
20.      };
21.      // that’s it. Too easy
22.                
23.      icon.node.onclick = null;
24. };
25.  

Andrew Hoyer shows his canvas Fu with Cloth, a great experiment using nice physics.

What makes this simulation special is the speed at which everything is computed. Javascript (the language this is written in) is not exactly the most efficient language for this type of computation. This being said, much time was spent squeezing out every little detail that slows things down.

The most computationally expensive part is trying to satisfy the constraints. To do this requires the calculation of distance between two points. This is easy to do with a little math, but that often involves an expensive square root. This is something that cannot simply be thrown out either, so what do you do? You approximate it. There are lots of mathematical tools for approximating functions, in this case I chose the first couple terms of a taylor expansion.

Check out his fast vector, constraints, and finally the cloth itself.

Marcus Westin has created a new templating language called fin. It is an interesting beast, and he gave us a run down:

Since this past November I've been working on a realtime templating system I call "fin". I'd love to get some eyes on it, and hope that you'll find it exciting. There is no demo, but quite a bit of information and if you're on OS X it's trivial to get the system set up on your own machine.

The basic idea is this... Rather than describing your data, you describe how you want your data to be viewed. Fin takes it from there in terms of persisting new data as it gets created. In addition, all views of any piece of data is globally synchronized. If one computer makes changes to a user's name for example, then those edits are reflected for anyone viewing that user's name as well, keystroke by keystroke. The way you create value views and input views goes like

1.  
2. <div> User name: (( Value user.name )) </div><div> Edit user name: (( Input user.name )) </div>
3.  

More detailed examples can be found here.

You can also chain references to items, for example (( Value user.friend.name )). Now, if user.friend.name changes, then the Value view is instantly updated. Even cooler, if the user's friend reference changes to a new friend, then the value view will accurately reflect the new friend's name.

To get started on OS X 10.6 is as easy as

git clone git://github.com/marcuswestin/fin.git
cd fin
sudo make install-node
make deps
make run-couchdbx

And voila! Just navigate to localhost/path/to/fin/examples/from-html.html and you're good to go.

Would we all like Steve to sit down with us on our project and do a performance case study? Well, we may not get that, but we are getting to at least sit in on others.

Steve has kicked off his long awaited series that runs performance case studies on third party content. I have been talking to Steve about this for a couple of years, so it is great to see it. It is a sensitive topic as you never want to show up a team when you are just trying to help and educate.

First on the block? The Digg widget.

Steve goes into detail and finds a lot of short comings. You could probably guess some of the bad actors. Mr. document.write() appears for example. We get the problems, and proposed solutions to the issue. Steve also tries to note what a user of third party content can do regardless of if the third party guys fix their issues (put in iframe!).

Here are the most important performance issues along with recommended solutions.

1. 9 HTTP requests, 52 kB transferred over the wire, and 107 kB of JavaScript (uncompressed) is a lot of content for a single widget.

   Recommendations:

   • Concatenate these three scripts: JS_Libraries, widgetjsvars, and omnidiggthis. (eliminates 2 HTTP requests)
   • Run Page Speed’s “Defer loading JavaScript” feature and see how much of the JavaScript is not used. If it’s sizable, delete it. (This feature is currently broken in the latest version of Page Speed, but a fix is imminent.) (eliminates ?? kB)
   • Optimize the images – widget-logo.png and get-widget.png can both be reduced by ~3 kB. (eliminates ~6 kB)
   • Sprite widget-logo.png and shade-com.png. (eliminates 1 HTTP request)
2. The widget’s scripts block the main page’s content from downloading. Looking at the waterfall chart, the main page includes the image “digg-waterfall.png” (row 10). Notice how this image doesn’t start downloading until after all the scripts for the Digg widget are received.
   Recommendations:
   • Instead of loading the scripts using document.write, load them without blocking other downloads. The scripts are already suffering from race condition behavior, as evidenced by this comment from widgetjsvars:
     1: if (!digg || !digg.$) setTimeout(function() { diggwb(obj); }, 200); //hack for IE not loading scripts that are included via document.write until it decides too

   So it probably isn’t too much work to avoid race conditions when making all the scripts load asynchronously.

3. The widget’s stylesheet blocks the main page from rendering in IE.

   Recommendations:

   • Instead of loading the stylesheet using document.write, load it via JavaScript as described in 5d dynamic stylesheets.
4. Four of the resources aren’t cached long enough.
   Recommendations:
   • Two scripts aren’t cacheable because they have an expiration date in the past. widgetjs is part of the snippet, so it can’t have a long expiration date, but something like an hour or a day would be better than a date in the past. widgetjsvars could have a far future expiration date since its URL is specified in widgetjs.
   • The three images are only cacheable for a day. They should have a far future expires header since the image filename can be change if it’s modified.
5. There are approximately 30 inefficient CSS selectors. Because this stylesheet is part of the main page, the selectors will cause the overall page to render more slowly when these selectors are applied to the elements in the main page.
   Recommendations:
   • Reduce the performance impact by simplifying these CSS selectors.
6. Four of the resources have ETags which reduces their cacheability.

   Recommendations:

   • Configure the ETags for widget.css, widget-logo.png, get-widget.png, and shade-com.png.

This is just the first example. What else would you like to see Steve tackle?

David Anderson: "TraceMonkey has rocket boosters, so it runs really fast when the boosters are on, but the boosters can’t always be turned on."

Opera's new JIT compiler Carakan is doing well as we just posted. What is Mozilla doing with TraceMonkey? A lot.

Mozilla JägerMonkey adds method based JIT (of V8 and Nitro fame) to keep the boosters on.

We learn more from David Mandelin and David Anderson.

The Opera team has released 10.50 for Mac and along with it some impressive performance numbers:

• Stabilization Improvements: You will find that this build is much more stable than the pre-alpha build.
• More polished user interface: The whole UI is more polished now. We're still not done yet, and expect more polishes and improvements in the builds to come.
• Opera Unite: Opera Unite now works with this release. You can browse through and download unite apps through the Unite Apps Repository.
• HTML5 <video>: This beta now supports the html5 <video> tag.
• Widgets as standlone apps: We've already talked about widgets as standalone apps, but this functionality was till now, only available in windows builds. Now even in this build of 10.50 beta for mac, you can use widgets as standalone apps. Check out this ODIN post by Patrick Lauke on standalone widgets for more information.
• New Developer Tools Menu: You can go to 'View->Developer Tools' Menu to access common and usefull tools for developers, such as Opera Dragonfly, cache information, the error console, the source code of the page, and more.

Gregg Keizer talks about the performance side of things

According to tests run by Computerworld, Opera 10.5 was nearly 15% faster than Safari for Windows and almost 20% faster than Google's Chrome, the previous No. 1 and No. 2 browsers. Opera's preview was more than twice as fast as Mozilla's Firefox 3.6, over eight times faster than Opera 10.10, and 10 times faster than Microsoft's Internet Explorer 8 (IE8).

We tend to talk a lot about WebKit, Moz, and IE.... congrats to the Opera team on their impressive work.

Bastian Allgeier has developed a beautiful, native looking web application called ZooTool.

Zootool is a visual bookmark tool for images, videos, documents and links. It is completely based on Mootools, even though it looks more like a Cappuccino app!

Play with it. Enjoy it.

EnhanceJS is a new library from the Filament Group, who are serious about progressive enhancement and accessibility.

What is EnhanceJS?

EnhanceJS is a new JavaScript framework (a single 2.5kb JavaScript file once minified/gzipped) that that automates a series of browser tests to ensure that advanced CSS and JavaScript features will render properly before they’re loaded to the page, enabling you to build advanced, modern websites without introducing accessibility problems for people on browsers that aren't capable of supporting all advanced features. It's designed to be easily integrated into a standard progressive enhancement workflow: just construct the page using standard, functional HTML, and reference any advanced CSS and JavaScript files using EnhanceJS to ensure they're only delivered to browsers capable of understanding them.

So, you have simple markup, if you pass the test you will get "enhanced" with new CSS and JavaScript behaviour additions to take things to the next level. You can even do conditional CSS for IE:

1.  
2. <script type="text/javascript" src="enhance.js"></script>       
3. <script type="text/javascript">
4.         enhance({
5.                 loadStyles: [
6.                         'css/enhancements.css',
7.                         {href: 'css/print.css', media: 'print'},
8.                         {href: 'css/ie6.css', iecondition: 6}
9.                 ],     
10.                 loadScripts: [
11.                         'js/jquery.min.js',
12.                         'js/enhancements.js'
13.                 ]
14.         });   
15. </script>
16.  

There are detailed docs:

• EnhanceJS Usage Basics (integration basics covered in this article)
• Configurable Options (all options available in EnhanceJS)
• Integration tips (how to prevent a flash of unstyled content, and more)
• Additional tests (capabilities tests not included in the default suite)

Go to the bottom of their blog post and click on the low-bandwidth version to see it in action.

Reposted from my personal blog where I tinker with the Web. I tweet about this stuff here.

As you move to a new platform, it is interesting to watch your brain morph over time. I remember switching from Windows to Mac. At first the fonts looked blurry and weird. The mouse pointer didn't weight right. The constant app menu was strange. There were things I liked about it right away, but they were mostly the fact that I had a command line, and the fact that apps were minimal, pretty, and useful.

Over time though, I grew to like the Mac more and more. A few months in and it was the Windows fonts that looked too sharp and weird.

I am going through the same experience with webOS and the iPhone. It took me awhile to get used to the back gesture on webOS and not look for a back button. Now I know how to organize my multiple windows, and use universal search as my quicksilver, and so much more. When I open up my iPhone now I am at the point where I try to do a back gesture by mistake. webOS is a touchier, needier device, and as I develop apps and play with the platform, I start to grok that more and more.

Embrace the touch

I discussed touching and horizontal scrolling awhile back, but the more I play with touch devices, the more I find myself wanting to build features for the touch. I have a ton of learning, but here are some of the lessons so far:

Native UI or Immersive UI

One decision that you have to make when you start building your application is the style of UI. Do you want a native looking UI for the given platform?

Everyone jumped on native off the bat. We quickly saw libraries such as iUI come out that let you mimic the iPhone UI. Having a native UI can be important. You want to fit in. However, we have also seen the growth of immersive UIs. Convertbot is the example above on the right. It is task based and you feel like you are really interacting with the app. It is almost tactile.

It is interesting to compare the Gmail and native Mail client UI in webOS. The Gmail version is deployed via a website, whereas the native version is of course an application, but they are very similar. Both use HTML/JS/CSS. Both have their look and feels. Do you try to look like your website (e.g. Google look and feel), or do you try to go fully native. The blending of the two gets interesting. Your brand has to live in another native world.

Haptics and touch feedback

It is usability 101 to make sure that you are always giving users feedback on their actions.

First, how do we signal to users that there are particular touch areas? This one is a bit of an art. We don't really have :hover and the like. I actually like the idea of having a long press show helpful information, but users aren't used to using that ability yet (see: need more gestures!).

Where we do have touch areas, we need to make sure to have various depress states for the touch.

Users will touch all over the app, so think about what you can do where.

We are going to see haptics in the future. For now it feels like haptics are used like this:

But the science is coming along. Sony Ericcson has a device (Satio) with haptic support for example:

Using the Keyboard: Software or hardware

This brings us to keyboards. What is the optimal input for your application use cases.

Feathers by Aral Balkan is a good example of both the task based nature of mobile apps, and custom software input. I like how Aral thought to create an app that solely creates Twitter messages. He didn't create a full Twitter client that would do it all.

And if you have the pleasure of a hardware keyboard, how can you use that beyond the obvious inputting of text fields. The beauty of a keyboard that come out is that it doesn't take away space from the screen. Could you offer short cut keys in the app? Different navigation? There is a lot more to explore here.

Gestures. Time to catalog and create new standards

We are seeing more and more gestures in applications. It feels like we are building out the standards right now. What will be the Ctrl-C's of mobile? We get to build out invisible ways to navigate.

Tweetie 2 did something interesting when it threw away the refresh button and replaced it with the pull down. Isn't it more work? Some people don't like it (Jimmy Fallon for one!) but a lot of people find it more gratifying because it is more natural. We have buttons in the real world, but the apes in us are more used to touching the world around us in very different ways? This is one example of going back to our roots.

Speaking of reload, we are seeing another common gesture here too. Using "shake" to reload, or relayout.

Orientation: Try to accept them, and be more creative

Have you ever turned your device on its side and not seen anything happen? That frustrates me. At the least, we need to rotate the UI and let it continue. But, can we go beyond that? I have been playing with this. What if landscape brings a more immersive experience?

Take an app that loads a stream (e.g. Facebook, FriendFeed, Twitter, whatever). In landscape, you can view one entry at a time. If the type of entry contains a photo album say, take over the full screen to show the photos and let you flick through.

It really is fun to play with touch apps these days, and I get the feeling that we are still in the dark ages wrt our interaction models.

What patterns have you enjoyed in using and building mobile apps?

In my never ending quest to find weird and wonderful ways to abuse CSS and all its little intricacies, I have come up with a pretty good way of using CSS to create custom radio and checkbox inputs without JavaScript, that are accessible, keyboard controlled, don’t use any hacks and degrade nicely in non supporting browsers. The journey wasn’t easy and I was on the brink of filing it in the “to crazy” folder, never to be seen again. Luckily I had a brain wave that paid off and actually allowed this to be a very viable solution that degrades beautifully and works in 80% of the browsers. This is my story.

Ryan "the CSS Ninja" goes from here to explain his quest which includes fun CSS such as:

1.  
2. p:not(#foo)> input + label:before
3. {
4.     background: url(gr_custom-inputs.png) 0 -1px no-repeat;
5.     position: absolute;
6.     z-index: 2;
7.     left: 16px;
8.     content: "\00a0\00a0\00a0"; /* 3x &nbsp; */
9.     overflow: hidden;
10.     width: 16px;
11.     height: 16px;
12.     margin: 0 3px 0 -16px;
13. }
14.  
15. p:not(#foo)> input[type=radio]:checked + label:before {
16.     background-position: -32px -73px;
17. }
18.  
19. input[type=radio]:hover + label:before,
20. input[type=radio]:focus + label:before {
21.     background-position: -32px -19px;
22. }
23. input[type=radio]:hover:checked + label:before,
24. input[type=radio]:focus:checked + label:before {
25.     background-position: -32px -91px;
26. }
27. input[type=radio]:hover:disabled + label:before,
28. input[type=radio]:focus:disabled + label:before {
29.     background-position: -32px -55px;
30. }
31. input[type=radio]:hover:disabled:checked + label:before,
32. input[type=radio]:focus:disabled:checked + label:before {
33.     background-position: -32px -127px;
34. }
35. input[type=radio]:active + label:before {
36.     background-position: -32px -37px;
37. }
38. input[type=radio]:active:checked + label:before {
39.     background-position: -32px -109px;
40. }
41.  

He also reminded me of pointer events:

The CSS property pointer-events allows authors to control whether or when an element may be the target of a mouse event. This property is used to specify under which circumstance (if any) a mouse event should go "through" an element and target whatever is "underneath" that element instead.

There is a lot of Ninja in this one. Nice job.

Piotr Zalewa has created a really great playground, jsFiddle, for testing sample code and playing with the Web. With an area for the holy trinity of the Web (HTML, CSS, JS) and an output region, you can get right to hacking.

It goes beyond this though. You can also add resources, an Ajax echo backend, and auto load from a slew of JavaScript frameworks.

You can also check out the examples and see great stuff such as Processing in action.

And the finishing touch, share and embed.

Piotr wrote all of this using CodeMirror and MooTools. Nice! Having worked on Bespin, and developed a playground like this (looking forward to show a new mobile one soon!) I appreciate the work!

Most of the thinking on iPad's exclusion of Flash has been focused on battery life, performance, stability, or control of the application market, but here's a Flash developer who's thinking differently. Morgan Adams argues it's all about the mouseover, and he raises a point that is just as relevant to rich Javascript apps.

Many (if not most) current Flash games, menus, and even video players require a visible mouse pointer. They are coded to rely on the difference between hovering over something (mouseover) vs. actually clicking. This distinction is not rare. It’s pervasive, fundamental to interactive design, and vital to the basic use of Flash content. New Flash content designed just for touchscreens can be done, but people want existing Flash sites to work. All of them—not just some here and there—and in a usable manner. That’s impossible no matter what.
....
Mouseover examples:

* Video players where the controls appear on mouseover and hide otherwise. (This seems to be the norm, in fact. Whereas a click on the same video does something different: usually Pause. Try Hulu for instance.)

* Games where you steer with the mouse without clicking (extremely common).

* Menus that popup up subpage links when you mouse over a main button, vs. going directly to a main category page when you click.
....

He claims all the alternatives are unsatisfactory, e.g. re-coding every application manually, introducing gestures, substituting double-clicking for clicking and clicking for mouseovers.

The issues are relevant to Javascript developers; for example, PPK has previously speculated on the demise of mouse* events, as well as hover in touch environments. How will that play out with a web app that relies on them?

It's a bit like Dion's recent tweet: "I find myself typing click^H^H^H^H^Htap 20 times a day at the moment. Is there a term that abstractly could mean both? :)". We can get away with simple substitutions with straightforward web apps maybe, but it gets a lot more complicated with seriously rich interaction styles, the kind traditionally seen in some Flash games and now possible with Javascript. We tend to think of mobile device design as a matter of massaging the look with some CSS...the harder part to get right is often the "feel" in the look-and-feel equation. Platforms, like the web, which want to support multiple interaction styles, need to provide ways to ease the transition for developers, automating degradation and enhancement in the first instance, but allowing application designers to customise further for each device. Dan Saffer's sideshow below makes the point well, regarding gesture design in touch devices:

Steve Souders has put together a browser performance wishlist that answers the question "What are the most important changes browsers could make to improve performance?"

• download scripts without blocking
• SCRIPT attributes
• resource packages
• border-radius
• cache redirects
• link prefetch
• Web Timing spec
• remote JS debugging
• Web Sockets
• History
• anchor ping
• progressive XHR
• stylesheet & inline JS
• SCRIPT DEFER for inline scripts
• @import improvements
• @font-face improvements
• stylesheets & iframes
• paint events
• missing schema, double downloads

He also notes a couple of new ideas that he is very much behind:

SPDY

SPDY is a proposal from Google for making three major improvements to HTTP: compressed headers, multiplexed requests, and prioritized responses. Initial studies showed 25 top sites were loaded 55% faster. Server and client implementations are available, and some other organizations and individuals have completed server and client implementations. The protocol draft has been published for review.

FRAG

The idea behind this “document fragment” tag is that it be used to wrap 3rd party content – ads, widgets, and analytics. 3rd party content can have a severe impact on the containing page’s performance due to additional HTTP requests, scripts that block rendering and downloads, and added DOM nodes. Many of these factors can be mitigated by putting the 3rd party content inside an iframe embedded in the top level HTML document. But iframes have constraints and drawbacks – they typically introduce another HTTP request for the iframe’s HTML document, not all 3rd party code snippets will work inside an iframe without changes (e.g., references to “document” in JavaScript might need to reference the parent document), and some snippets (expando ads, suggest) can’t float over the main page’s elements. Another path to mitigate these issues is to load the JavaScript asynchronously, but many of these widgets use document.write and so must be evaluated synchronously.

A compromise is to place 3rd party content in the top level HTML document wrapped in a FRAG block. This approach degrades nicely – older browsers would ignore the FRAG tag and handle these snippets the same way they do today. Newer browsers would parse the HTML in a separate document fragment. The FRAG content would not block the rendering of the top level document. Snippets containing document.write would work without blocking the top level document. This idea just started getting discussed in January 2010. Much more use case analysis and discussion is needed, culminating in a proposed specification. (Credit to Alex Russell for the idea and name.)

jQuery 1.4.2 has been released today and it comes with some performance bumps (aggressive ones according to Taskspeed). Benchmarks are challenging, and John even calls that out:

For example, we saw significant overall performance speed-ups in Taskspeed simply by optimizing the $("body") selector because it’s called hundreds of times within the tests. Additionally we saw large gains by optimizing .bind() and .unbind() by a fraction of a millisecond – an inconsequential amount – especially considering that any cases where you would bind hundreds of events you would likely want to use .live() or .delegate() instead.

There are some new APIs a bunch of them around ergonomics:

In this release we’ve added two new methods: .delegate() and .undelegate(). These methods serve as complements to the existing .live() and .die() methods in jQuery. They simplify the process of watching for specific events from a certain root within the document.

For example:

1.  
2. $("table").delegate("td", "hover", function(){
3.         $(this).toggleClass("hover");
4. });
5.  

This is equivalent to the following code written using .live():

1.  
2. $("table").each(function(){
3.         $("td", this).live("hover", function(){
4.                 $(this).toggleClass("hover");
5.         });
6. });
7.  

Additionally, .live() is roughly equivalent to the following .delegate() code.

1.  
2. $(document).delegate("td", "hover", function(){
3.         $(this).toggleClass("hover");
4. });
5.  

The jQuery team continues to really put the pedal to the metal.

Bram Stein has done some really fun work. He has taken the Knuth and Plass line breaking algorithm and implemented it using Canvas:

The goal of this implementation is to optimally set justified text in the new HTML5 canvas element, and ultimately provide a library for various line breaking algorithms in JavaScript.

You can see the subtleties at work:

Check out the linebreak code which does more than solely justification. It can also perform all sorts of alignment with an appropriate selection of boxes, glue and penalties. It is also possible to give it varying line widths to flow text around illustrations, asides or quotes. Alternatively, varying line widths can be used to create interesting text shapes.

Thomas Fuchs gave a presentation titled "I Can't Believe It's Not Flash" at WebStock. It is often hard to grasp a presentation from slides, but this one is great fun to flip through.

This one really hits home:

We were surprised to see how JavaScript was NOT the bottleneck in Bespin when we first prototyped it.

And, this is Thomas, so you know he is going to be cheeky.... and he doesn't dissapoint ;)