Yahoo! UI JavaScript treats
The Yahoo! Developer Network was updated yesterday with a veritable gold-mine of Exciting New Stuff, coinciding with the launch of the brand new Yahoo! User Interface Blog.
Here are some of the highlights:
Mature, extensively tested cross-browser JavaScript libraries for animation, event handling, DOM wrangling, XMLHttpRequest and Drag and Drop.
CSS-skinnable UI controls built on those libraries: Calendar, Slider and TreeView.
A library of documented design patterns for modern web applications.
A description of Yahoo!’s Graded Browser Support policy, which should be of great interest to anyone who cares about Web Standards, semantic HTML, accessibility, progressive enhancement and unobtrusive JavaScript.
The code is all under a BSD Open Source license, which means you can use it freely in your own projects, including for commercial development.
This release represents the culmination of more than 9 months of work by an incredibly talented team. Eric Miraglia provides some behind-the-scenes insight in to the work that has gone in to the code.
I’ve been playing with this internally quite a bit over the past few months and I keep finding new useful bits and pieces. Here are some of my favourite details:
The Event library normalises the event model across multiple browsers, including workarounds for many of the weird frustrations faced when dealing with Safari. It cleans up events when the page is unloaded, which guards against a whole swathe of memory leak problems in IE. Best of all, if you assign an event to the DOM ID of an element that has not yet been loaded, the library keeps trying to attach the event (polling) until it succeeds or the page finishes loading.
The CustomEvent library implements the publish-subscribe/listener pattern for you to use within your own scripts.
The Dom library’s getStyle and setStyle methods include cross-browser support for the CSS 3 opacity property.
The Animation library uses a global Animation Manager object to oversee all animations on the page. This means it can adjust the frame-rate depending on how much stuff is happening—so if you tell a block to move across the screen in 1 second it will happen in one second no matter how much other stuff is going on at the same time.
Here’s a surprisingly tricky question: when does a drag start? When the user presses down on the mouse they might be starting a click rather than a drag. The Drag and Drop library defaults to starting a drag after a user either clicks and moves 3 pixels or more, or holds the mouse down for over a second.
The Drag library also makes it easy to have elements “grouped” so that they can only interact with other elements in the same group—see this demo for an example.
And finally, I couldn’t resist quoting this bit of code from one of the Animation examples:
var attributes = { width: { to: 100 }, height: { to: 100 }, fontSize: { from: 100, to: 50, unit: '%' }, opacity: { to: 0.5 } } var anim = new YAHOO.util.Anim('size', attributes, 1, YAHOO.util.Easing.easeOut);
A big thanks to the team that put this all together.
Ed - 14th February 2006 14:34 - #
Yvonne Adams - 14th February 2006 15:41 - #
JD - 14th February 2006 15:44 - #
I know it's not the exciting part, but I can't help but be most fascinated by the UI patterns library. Designers can have APIs too!
Wilson - 14th February 2006 17:17 - #
It's surprisingly well-written, and it looked great at first. But it seems really imbalanced - there's great code for particular functionality, but when it comes to manipulating the DOM and picking out elements, it is awful. Why do you need to give everything IDs to work with them? Why isn't there an easy way to select a bunch of elements? Why can't you pass something like "ol.draggable li" to set up your event handlers?
Maybe I'm spoiled from working with jQuery recently, but writing code to manipulate a page just seems way too much needless work unless you have something like $(). It's a glaring omission considering most of the other major Javascript libraries have something along those lines.
Jim Dabell - 14th February 2006 19:57 - #
Wilson, design patterns are a heavily-borrowed concept (as Simon pointed out). He made an abortive attempt at CSS design patterns on the css-discuss wiki some time ago.
There's a crying need for design patterns in UI discussions. Even if something is a well-understood problem, just giving the situation a name aids communication and learning.
Instead of describing some complex problem for 15 minutes before getting to the point, I can say "maybe a visitor to each of the composite nodes would work."
Huzzah for a high-profile effort at that need, says I.
Jeremy Dunck - 14th February 2006 23:49 - #
Jim, yeah, one of the first things I looked for was whether getElementsBySelector was included. Too bad.
There is a benefit to giving everything an ID: using id + $() is a very cheap implementation of weakref so you can avoid closure-leak problems.
(But I agree that the other common usage, in which all funcs take either an dom elm obj or an id, is useful, too.)
Jeremy Dunck - 14th February 2006 23:58 - #
Dustin Diaz - 15th February 2006 07:56 - #
Tom Coates - 15th February 2006 14:46 - #
www.wreckedband.com - 28th February 2006 05:48 - #
penis enlargement - 6th March 2006 20:50 - #
Matthew Corich - 18th March 2006 05:22 - #
Naweb - 25th March 2006 12:14 - #
Tim - 11th April 2006 17:05 - #
tom - 29th April 2006 21:19 - #
Tam - 25th May 2006 21:35 - #
Thommes - 9th August 2006 00:20 - #