Schöner Debuggen: »prettyPrint« für JavaScript

James Padolsey bietet mit »prettyPrint« eine art Variablen-Dumper für javaScript an (so in der Art wie JavaScript Dump:

»prettyPrint« is an in-browser JavaScript “variable dumper” similar to ColdFusions’s cfdump. It enables you to print out an object of any type in table format for viewing during debugging sessions. In combination with Firebug, »prettyPrint« will make you the best-equipped JavaScript debugger on earth! (not guaranteed)

Some of its key features:

  • Entirely independent. It requires NO StyleSheets or images.
  • Handles infinitely nested objects.
  • All native JavaScript types are supported plus DOM nodes/elements!
  • Protects against circular/repeated references.
  • Allows you to specify the depth to which the object will be printed.
  • Better browser users benefit from gradient column-headers! Thanks to HTML5 and CANVAS!
  • Allows low-level CSS customisation (if such a thing exists).
  • Fully validated with JSLint!

A Free JavaScript Speed Boost for Everyone!

A Free JavaScript Speed Boost for Everyone!: „An exciting development in the world of DOM scripting is the W3C Selector API. Up until now, using the DOM Level 2 API, the only way to obtain references to HTML elements in the DOM was to use either document.getElementById or document.getElementsByTagName and filter the results manually. With the rise of CSS, JavaScript programmers asked the obvious question, ‘If the browser has a really fast way of selecting HTML elements that match CSS selectors why can’t we?’.

The Selector API defines the querySelector, and querySelectorAll methods that take a CSS selector string and return the first matching element or a StaticNodeList of matching elements, respectively. The methods can be called from the document object in order to select elements from the whole document or a specific HTML element to select only from descendants of that element.

To illustrate how much easier your life will be using the Selector API, have a look at this example HTML:

<ul id='menu'>
    <input type='checkbox' name='item1_done' id='item1_done'> 
    <label for='item1_done'>bread</label>
  <li class='important'>
    <input type='checkbox' name='item2_done' id='item2_done'> 
    <label for='item2_done'>milk</label>
  <!-- imagine more items -->

Our task is to check all the checkboxes for the list items that have the class ‘important’. Using only DOM Level 2 methods we could do it this way:

var items = document.getElementById('menu').getElementsByTagName('li');
for(var i=0; i < items.length; i++) {
  if(items[i].className.match(/important/)) {
    if(items[i].firstChild.type == 'checkbox') {
      items[i].firstChild.checked = true;

Using the new selector API we can simplify it to this:

var items = document.querySelectorAll('#menu li.important input[type='checkbox']');
for(var i=0; i < items.length; i++) {
  items[i].checked = true;

That’s much nicer! The methods also support selector grouping — multiple selectors separated by commas. The Selector API is working right now in Safari 3.1, the Internet Explorer 8 beta, and Firefox 3.1 alpha1. Opera is also working on adding support for the API.

If you’re a fan of one of the many JavaScript libraries available you’re probably thinking ‘But, I can already do that.’ One of the great examples of the benefits of using JavaScript libraries are the implementations of CSS selectors found in nearly all of them. Recently we’ve seen huge speed improvements in the CSS selector implementations because library authors have been sharing their techniques. So what’s the benefit of using the Selector API? In a word: speed — native implementations are fast! And better yet all of the javascript libraries are poised to benefit. jQuery and Prototype are already developing implementations that make use of the Selector API, while The Dojo Toolkit, DOMAssistant and base2 have already made use of it.

There’s a reason why those 3 libraries were the first ones to benefit. Kevin talked about the potential problem back in Tech Times #190 in the article titled ‘Is Your JavaScript Library Standards Compliant?’ The Selector API makes use of standard CSS selectors so if the browser doesn’t support a certain selector then you won’t be able to use it. The libraries that have already taken advantage of the Selector API are those that only supported standard CSS selectors. For those libraries, supporting the API was (almost) as easy as doing this:

if(document.querySelector) {
  return document.querySelector(selector);
} else {
  return oldSelectorFunction(selector);

Libraries that support custom selectors will have more work to do. The risk is that if you have used custom CSS selectors extensively in your project, it may be difficult for your chosen library to pass on the speed benefit to you because the library will have to use its default selector instead of the Selector API. If the library somehow rewires its custom selectors so that they can utilize the Selector API, the secondary risk is increased code bloat.

Hopefully the Selector API will encourage the use of standard CSS selectors over custom ones. In fact if uptake of the new browser versions is good and the performance benefits of the new Selector API are compelling enough we could see custom selector functionality moved to supplementary libraries you only need to use in case of legacy compatibility requirements.

Dean Edwards’ base2 Library has the nicest implementation in my opinion. Base2 implements the API exactly, which means you can write your JavaScript using standard the standard API methods — Base2 only creates custom querySelector and querySelectorAll methods if the browser doesn’t support them. You can’t get any cleaner than that. Base2 does, however, implement the non-standard ‘!=’ attribute selector in it’s custom selector function, apparently because of peer pressure, so it’ll have to have points deducted for that.

Regardless of whether you use a JavaScript library or roll your own, the new browser implementations of the Selector API give everyone an instant speed boost. We all win, hooray!“

(Via SitePoint Blogs.)

A Closer Look at YUI 3.0 PR 1: Dav Glass’s Draggable Portal Example

A Closer Look at YUI 3.0 PR 1: Dav Glass’s Draggable Portal Example: „

YUI 3.0 Preview Release 1 was made available on Wednesday, and with it we provided a look at how the next major iteration of YUI is taking shape. Among the elements we shipped with the preview is a new example from Dav Glass, the Draggable Portal, which exercises a broad cross section of the preview’s contents.

The Portal Example in the YUI 3.0 preview release.

The Draggable Portal is a common design pattern in which content modules on the page can be repositioned, minimized, removed, and re-added to the page. The state of the modules persists in the background, so a reload of the page or a return to the page calls up the modules in their most recently positioned state. You see variations of this design pattern on many personlizable portals like My Yahoo, NetVibes, and iGoogle.

In this article, we’ll take a look under the hood of this example to get a richer sense of YUI’s 3.x codeline and the idioms and patterns it establishes. We’re just pulling out some specific code snippets to examine here, but you can review the full code source for this exampleand for 66 others — on the YUI 3 website.


(Via Yahoo! User Interface Blog.)

YUI 3.0 Preview Release 1

YUI 3.0 Preview Release 1: „

YUI 3.0 Preview 1 website.The YUI team is pleased to announce the public availability of YUI 3.0 Preview Release 1, an early look at what we’re working on for the next generation of the YUI Library. Documentation for YUI 3.0 is on the YUI website; the download is available on the YUI project area on SourceForge; you can find us with questions or comments on the YUI 3.x discussion forum. Keep in mind that this is an early preview, not a production-quality (or even a beta) release. This release is not suitable for production use, but it will give you an idea of what we’re working on, and it should provide a good framework for conversation about the future of the library.

Five Goals for YUI 3:

We’ve talked to thousands of YUI users over the past 30 months, and based on that feedback we’ve set five design goals for the next generation of the library. What you’ve told us is that YUI 3.0 should be:

  • lighter (less K-weight on the wire and on the page for most uses)
  • faster (fewer http requests, less code to write and compile, more efficient code)
  • more consistent (common naming, event signatures, and widget APIs throughout the library)
  • more powerful (do more with less implementation code)
  • more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)

With this early release, we’ve made progress toward most of these objectives — and we believe we have the right architecture in place to meet all five as we move to GA over the next few quarters.

What’s New in YUI 3.0?

When you start to write code using YUI 3.0, you’ll notice some changes in structure and style. Here’s a taste:

Snippet: What it does:
YUI().use('node', function(Y) {
Creates a YUI instance with the node module (and any dependencies) and adds the class ‚enabled‘ to the element with the id of ‚demo‘.
YUI().use('dd-drag', function(Y) {
        var dd = new Y.DD.Drag({
        node: '#demo'
Creates an instance of YUI with basic drag functionality (a subset of the dd module), and makes the element with the id of ‚demo‘ draggable.
Adds the class ‚enabled‘ to the all elements with the className ‚demo‘.
Y.all('.demo').set('title', 'Ready!').removeClass('disabled');
Sets the title attribute of all elements with the className ‚demo‘ and removes the class ‚disabled‘ from each.
Y.get('#demo').plug(Y.Plugin.Drag, {
    handles: 'h2'
Adds the Drag plugin to the element with the id ‚demo‘, and enables all of its h2 children drag as handles.
Y.on('click', function(e) {
    e.preventDefault();'em').set('innerHTML', 'clicked');
}, '#demo a');
Attaches a DOM event listener to all anchor elements that are children of the element with the id ‚demo‘. The event handler prevents the anchor from navigating and then sets a value for the innerHTML of the first em element of the clicked anchor.

What’s different here?

  • Sandboxing: Each YUI instance on the page can be self-contained, protected and limited (YUI().use()). This segregates it from other YUI instances, tailors the functionality to your specific needs, and lets different versions of YUI play nicely together.
  • Modularity: YUI 3 is architected to use smaller modular pieces, giving you fine-grained control over what functionality you put on the page. If you simply want to make something draggable, you can include the dd-drag submodule, which is a small subset of the Drag & Drop Utility.
  • Self-completing: As long as the basic YUI seed file is in place, you can make use of any functionality in the library. Tell YUI what modules you want to use, tie that to your implementation code, and YUI will bring in all necessary dependencies in a single HTTP request before executing your code.
  • Selectors: Elements are targeted using intuitive CSS selector idioms, making it easy to grab an element or a group of elements whenever you’re performing an operation.
  • Custom Events++: Custom Events are even more powerful in YUI 3.0, with support for bubbling, stopping propagation, assigning/preventing default behaviors, and more. In fact, the Custom Event engine provides a common interface for DOM and API events in YUI 3.0, creating a consistent idiom for all kinds of event-driven work.
  • Nodes and NodeLists: Element references in YUI 3.0 are mediated by Node and NodeList facades. Not only does this make implementation code more expressive (Y.Node.get('#main ul li').addClass('foo');), it makes it easier to normalize differences in browser behavior (Y.Node.get('#promo').setStyle('opacity', .5);).
  • Chaining: We’ve paid attention throughout the new architecture to the return values of methods and constructors, allowing for a more compressed chaining syntax in implementation code.

And that’s just the beginning. Dive into the examples to learn more and to see the preview release in action, including some hidden gems like full A-Grade cross-domain requests. Our resident metahacker Dav Glass created a nice multi-component example, the draggable portal, that will give you some sense of what’s included in today’s preview.

Is YUI 3.0 Backward Compatible with YUI 2.x?

No. YUI 3.0 builds off of the YUI 2.x codeline, but we’ve evolved most of the core APIs in working toward the five key goals described above. As a result, migrating from YUI 2.x to 3.x will require effort at the implementation level.

We know that ease-of-migration will be a critical factor for all YUI users. We’re taking two important steps to facilitate the transition as it arrives:

  • Limited compatibility layer: YUI 3.0 will ship with a limited compatibility layer for the current YUI Core (Yahoo Global Object, Dom Collection, and Event Utility). This will allow you to run many of your YUI 2.x-based implementations on top of YUI 3.0. We’re not shipping the compatibility layer with today’s preview, but you’ll see it appear in a future preview or beta release prior to GA.
  • Full parallel compatibility: YUI 3.0 can be run in parallel to YUI 2.x with no side effects for either version. If you choose to make the transition in stages, you can run the full 2.x stack and 3.x stack together as needed.

Even with these provisions in place, we know that an API change (along with new concepts and idioms) has a real cost for everyone involved. We’re convinced that this change is both necessary and worth the effort, and obviously we’re going to work hard to make the value proposition compelling.

What’s Next?

YUI 3.0 is a work in progress. The common widget framework for 3.0 is not included in this preview and we’re continuing to work on refinements to the core — including optimizations to the package structure to minimize base K-weight. We anticipate the next two releases coming up as follows:

  • October 2008 — PR2: Widget Framework, sample widgets, additional utilities.
  • December 2008 — Beta 1: Final mix of module structures, API completion, full complement of utilities.

We have some great stuff to share as we move further along in this process. We’ve never been more excited about YUI and its future — and we think YUI 3.0 will have a big role to play in that future.

(Via Yahoo! User Interface Blog.)

Non-blocking JavaScript Downloads

Non-blocking JavaScript Downloads:

External JavaScript files block downloads and hurt your page performance, but there is an easy way to work around this problem: use dynamic scripts tags and load scripts in parallel, improving the page loading speed and the user experience.

The problem: scripts block downloads

Let’s first take a look at what the problem is with the script downloads. The thing is that before fully downloading and parsing a script, the browser can’t tell what’s in it. It may contain document.write() calls which modify the DOM tree or it may even contain location.href and send the user to a whole new page. If that happens, any components downloaded from the previous page may never be needed. In order to avoid potentially useless downloads, browsers first download, parse and execute each script before moving on with the queue of other components waiting to be downloaded. As a result, any script on your page blocks the download process and that has a negative impact on your page loading speed.

Here’s how the timeline looks like when downloading a slow JavaScript file (exaggerated to take 1 second). The script download (the third row in the image) blocks the two-by-two parallel downloads of the images that follow after the script:

Timeline - Blocking behavior of JavaScript files

Here’s the example to test yourself.

Problem 2: number of downloads per hostname

Another thing to note in the timeline above is how the images following the script are downloaded two-by-two. This is because of the restriction of how many components can be downloaded in parallel. In IE <= 7 and Firefox 2, it’s two components at a time (following the HTTP 1.1 specs), but both IE8 and FF3 increase the default to 6.

You can work around this limitation by using multiple domains to host your components, because the restriction is two components per hostname. For more information of this topic check the article ‘Maximizing Parallel Downloads in the Carpool Lane’ by Tenni Theurer.

The important thing to note is that JavaScripts block downloads across all hostnames. In fact, in the example timeline above, the script is hosted on a different domain than the images, but it still blocks them.

Scripts at the bottom to improve user experience

As Yahoo!’s Performance rules advise, you should put the scripts at the bottom of the page, towards the closing </body> tag. This doesn’t really make the page load faster (the script still has to load), but helps with the progressive rendering of the page. The user perception is that the page is faster when they can see a visual feedback that there is progress.

Non-blocking scripts

It turns out that there is an easy solution to the download blocking problem: include scripts dynamically via DOM methods. How do you do that? Simply create a new <script> element and append it to the <head>:

var js = document.createElement('script');
js.src = 'myscript.js';
var head = document.getElementsByTagName('head')[0];

Here’s the same test from above, modified to use the script node technique. Note that the third row in the image takes just as long to download, but the other resources on the page are loading simultaneously:

Non-blocking JavaScript timeline

Test example

As you can see the script file no longer blocks the downloads and the browser starts fetching the other components in parallel. And the overall response time is cut in half.


A problem with including scripts dynamically would be satisfying the dependencies. Imagine you’re downloading 3 scripts and three.js requires a function from one.js. How do you make sure this works?

Well, the simplest thing is to have only one file, this way not only avoiding the problem, but also improving performance by minimizing the number of HTTP requests (performance rule #1).

If you do need several files though, you can attach a listener to the script’s onload event (this will work in Firefox) and the onreadystatechange event (this will work in IE). Here’s a blog post that shows you how to do this. To be fully cross-browser compliant, you can do something else instead: just include a variable at the bottom of every script, as to signal ‘I’m ready’. This variable may very well be an array with elements for every script already included.

Using YUI Get utility

The YUI Get Utility makes it easy for you to use script includes. For example if you want to load 3 files, one.js, two.js and three.js, you can simply do:

var urls = ['one.js', 'two.js', 'three.js'];

YUI Get also helps you with satisfying dependencies, by loading the scripts in order and also by letting you pass an onSuccess callback function which is executed when the last script is done loading. Similarly, you can pass an onFailure function to handle cases where scripts fail to load.

var myHandler = {
    onSuccess: function(){
    onFailure: function(){

var urls = ['1.js', '2.js', '3.js'];
YAHOO.util.Get.script(urls, myHandler);

Again, note that YUI Get will request the scripts in sequence, one after the other. This way you don’t download all the scripts in parallel, but still, the good part is that the scripts are not blocking the rest of the images and the other components on the page. Here’s a good example and tutorial on using YUI Get to load scripts.

YUI Get can also include stylesheets dynamically through the method
YAHOO.util.Get.css() [example].

Which brings us to the next question:

And what about stylesheets?

Stylesheets don’t block downloads in IE, but they do in Firefox. Applying the same technique of dynamic inserts solves the problem. You can create dynamic link tags like this:

var h = document.getElementsByTagName('head')[0];
var link = document.createElement('link');
link.href = 'mycss.css';
link.type = 'text/css';
link.rel = 'stylesheet';

This will improve the loading time in Firefox significantly, while not affecting the loading time in IE.

Another positive side effect of the dynamic stylesheets (in FF) is that it helps with the progressive rendering. Usually both browsers will wait and show blank screen until the very last piece of stylesheet information is downloaded, and only then they’ll start rendering. This behavior saves them the potential work of re-rendering when new stylesheet rules come down the wire. With dynamic <link>s this is not happening in Firefox, it will render without waiting for all the styles and then re-render once they arrive. IE will behave as usual and wait.

But before you go ahead and implement dynamic <link> tags, consider the violation of the rule of separation of concerns: your page formatting (CSS) will be dependent on behavior (JS). In addition, this problem is going to be addressed in future Firefox versions.

Other ways?

There are other ways to achieve the non-blocking scripts behavior, but they all have their drawbacks.

Method Drawback
Using defer attribute of the script tag IE-only, unreliable even there
Using document.write() to write a script tag
  1. Non-blocking behavior is in IE-only
  2. document.write is not a recommended coding practice
XMLHttpRequest to get the source then execute with eval().
  1. eval() is evil’
  2. same-domain policy restriction
XHR request to get the source, create a new script tag and set its content
  1. more complex
  2. same-domain policy
Load script in an iframe
  1. complex
  2. iframe overhead
  3. same-domain policy


Safari and IE8 are already changing the way scripts are getting loaded. Their idea is to download the scripts in parallel, but execute them in the sequence they’re found on the page. It’s likely that one day this blocking problem will become negligible, because only a few users will be using IE7 or lower and FF3 or lower. Until then, a dynamic script tag is an easy way around the problem.


  • Scripts block downloads in FF and IE browsers and this makes your pages load slower.
  • An easy solution is to use dynamic <script> tags and prevent blocking.
  • YUI Get Utility makes it easier to do script and style includes and manage dependencies.
  • You can use dynamic <link> tags too, but consider the separation of concerns first.

(Via Yahoo! User Interface Blog.)

Optimizing Page Loading in the Web Browser

Interessanter Artikel, der unter anderem kurz auf die SCRIPT-Tag-Problematik eingeht.

Optimizing Page Loading in the Web Browser: It is well understood that page loading speed in a web browser is limited by the available connection bandwidth. However, it turns out bandwidth is not the only limiting factor and in many cases it is not even the most important one.


It turns out that figuring out ‘all the associated resources’ is the hard part of the problem. The browser does not know what resources it should load until it has completely parsed the document. When the browser first receives the HTML text of the document it feeds it to the parser. The parser builds a DOM tree out of the document. When the browser sees an element like <img src> that references an external resource it requests that resources from the network.

Problems start when a document contains references to external scripts, <script src>. Any script can call document.write(). Parsing can’t proceed further before the script is fully loaded and executed and any document.write() output has been inserted into the document text. Since parsing is not proceeding while the script is being loaded no further requests for other resources are made either. This quickly leads to a situation where the script is the only resource loading and connection parallelism does not get exploited at all. A series of script tags essentially loads serially, hugely amplifying effect of the latency.

The situation is made worse by scripts that load additional resources. Since those resources are not known before the script is executed it is critical to load scripts as quickly as possible. The worst case is a script that load more scripts (by using document.write() to write <script> tags), a common pattern in Javascript frameworks and ad scripts.


(Via Surfin‘ Safari.)

Safari 3.1

Safari 3.1 ist soweit und lässt sich ab sofort auf der Apple-Seite herunterladen – sowohl für den Mac als auch für Windows-PCs. Im Vorfeld hatte sich bereits anhand von Vorversionen gezeigt, dass die neue Version ein großer Wurf werden könnte.

Nun bestätigt Apple per Pressemitteilung: „Safari baut Webseiten bis zu 1,9 mal so schnell wie der Internet Explorer 7 und bis zu 1,7 mal so schnell wie Firefox 2 auf“. JavaScript sei bis zu sechs Mal schneller als bei anderen Browsern. Apple unterschlägt bei diesen Geschwindigkeitsangaben zwar, dass die Konkurrenz ebenfalls nicht schläft und Betaversionen von Firefox 3 bereits fast an die Geschwindigkeit von Safari herankommen – dennoch hat Apple unseren Tests zufolge derzeit die Nase vorn, sowohl in punkto Gewschwindigkeit als auch bei der Komaptibilität mit aktuellen und kommenden Web-Standards, wie der Acid3-Test beweist. Safari 3.1 unterstützt zudem als erster Browser sowohl Video- und Audio-Tags in HTML 5 als auch CSS Animationen und kommt darüber hinaus mit CSS Web Fonts zurecht. Voraussetzung ist mindestens Mac OS X 10.4.11, das Update ist über die Software-Aktualisierung erhältlich und für Leopard 39 Megabyte groß, der Tiger-Download zählt 49 Megabyte.

Apple Informationen zum Update:


YUI 2.5.0 Released — Big upgrades to DataTable, new Layout Manager, Flickr-style multi-file Uploader, and more

YUI 2.5.0 Released — Big upgrades to DataTable, new Layout Manager, Flickr-style multi-file Uploader, and more: „

The YUI Team just released version 2.5.0 of the library. We’ve added six new components — Layout Manager, Uploader (multi-file upload engine combining Flash and JavaScript), Resize Utility, ImageCropper, Cookie Utility and a ProfilerViewer Control that works in tandem with the YUI Profiler. This release also contains major improvements to the DataTable Control and new Dual-Thumb Slider functionality in the Slider Control. Here are the highlights:

  • DataTable Control: Jenny Han Donnelly has been joined by Luke Smith for this development cycle, and we’re all thrilled with what they’ve produced. DataTable in 2.5.0 gets a more robust markup structure that allows greater control over all aspects of the table. This release also includes major performance enhancements, improvements to the fixed-header implementation for vertical scrolling, built-in support for horizontal scrollling, an all-new Paginator class, support for drag-and-drop column reordering, and a new set of column APIs with hooks for showing, hiding, adding and removing columns.
    The DataTable and its new show/hide column interface.
    DataTable has been one of YUI’s most popular and important components since its debut, and this is its strongest release yet. If you have existing DataTable implementations that you want to upgrade, take a look at the new User’s Guide, as it has some detailed notes about API changes. The DataTable examples roster is another nice place to check out the new code in action.
  • The YUI Layout ManagerLayout Manager: Dav Glass has a lot for you to enjoy in 2.5.0, but top billing goes to his new Layout Manager. Layout Manager eases development of multipane UIs that take up either the full viewport or the full canvas of any block-level element. Layout Units within a layout are resizeable, collapsible, removable and swappable; transitions between expanded and collapsed states have built-in animation support. Whether you’re creating a full-screen application like Yahoo! Mail or a rich multi-pane pop-up, Layout Manager is a great place to start.
  • Uploader: If you’ve ever built a UI for uploading files via a browser, you know what the big pain points are: One file at a time, no easy way to track upload progress, no programmatic access to file metadata, etc. The new YUI Uploader addresses these issues and others, allowing for the creation of more powerful, intuitive, and responsive file upload experiences. Allen Rabinovich of the ASTRA Library team did the legwork on this one, and it’s the same code that underlies the Flickr Uploader. Uploader is our second JavaScript/Flash hybrid control (following on the heels of the Charts Control in 2.4.0).
    The YUI Uploader is the same code that drives Flickr's multi-file photo uploading interface.
  • Resize Utility: Layout Manager is built upon a new YUI utility, Resize. Dav’s Resize Utility formalizes the support that YUI Drag & Drop has long provided in example form and makes it easier for you to make any block-level element resizeable. Resizing can be implemented directly (the resized element resizes in real time during the interaction) or by proxy (a proxy element visualizes the interaction until its conclusion, at which time the resized element snaps to its new size).
  • The YUI ImageCropper ControlImageCropper Control: The Resize Utility makes a lot of things easier — and one of those is the implementation of an ImageCropper interface, which Dav built out on top of Resize for 2.5.0. Take a look at the examples and be sure to check out the support Dav provided for modifier keys in this very desktop-like UI control.
  • Cookie Utility: When he’s not busy writing books or working on My Yahoo!, Nicholas C. Zakas is cranking out new code for YUI. In 2.5.0, he contributes the Cookie Utility, a simple but powerful component that helps you get maximum mileage out of your limited cookie space. Because browsers limit the number of cookies you can set per domain (and because that limitation can sneak up on you if you manage a large site with many subdomains), the Cookie Utility supports ’sub-cookies.‘ Sub-cookies pack multiple name-value pairs under the umbrella of a single cookie, expanding the number of data points that you can store in cookie space.
  • ProfilerViewer Control: 2.4.0 saw the release of Nicholas’s Profiler, a headless, cross-browser kit for profiling JavaScript functions. To make it easier to access and interpret the data that Profiler collects, we’ve added a ProfilerViewer Control in 2.5.0 that sits on top of Profiler and visulizes its accrued data. ProfilerViewer leverages the Charts Control and the DataTable Control. Taken together, Profiler and ProfilerViewer provide another arrow in the development quiver that includes tools like Firebug’s integrated profiling interface.

    The ProfilerViewer interface.

  • The YUI Slider Control now has dual-thumb support.Slider Control with Dual Thumb Support: Supporting dual-thumb interactions in our Slider Control has been on our list for awhile, and Luke took the opportunity to get this out to you in 2.5.0. Sliders are ‘finite range controls’; dual-thumb sliders allow you specify a sub-range within the control’s larger range. The classic use case for dual-thumb sliders is on shopping sites, where such controls can allow users to filter results based on price range. Check out the User’s Guide, example, and the new Slider Cheatsheet (which has a second page dedicated to dual-thumb implementations).
  • We’re using this release to promote the following components from beta to GA status: ColorPicker Control, Get Utility (for cross-domain, dynamic loading of script and CSS files), JSON Utility, ImageLoader Utility, and YUI Test Utility. These promotions reflect the maturity of those components and their very low bug traffic. As always, we’re releasing all new-for-2.5.0 components under the beta moniker, and we’re looking forward to your feedback on those once you get a chance to try them out.
  • Full details on the release, including a rollup of the changelog for all components and a bug/feature manifest, are available in Georgiann Puckett’s update to the YUI developer forum this morning.

One More Thing…

YUI now ships with more than 270 examples, many of which are accompanied by full tutorials to help you get started using YUI. And while individual examples are good, we’ve gotten a number of requests to create an über example, one that pulls in and makes use of a wide range of YUI components in a single sample application — while still being YUI-centric and not littered with noisy implementation logic.

The incomparably prolific Dav Glass rose to the challenge for 2.5.0 with a complex, multi-component example that uses Layout Manager as its basis and Yahoo Mail as its inspiration.

Dav Glass's multi-module YUI application example.

Let’s Celebrate!

We’re excited to get 2.5.0 out the door and, as luck would have it, we’ve got a fantastic excuse to celebrate. YUI’s (and the Yahoo Pattern Library’s) second anniversary party is coming up next week (February 26, 5 p.m., Sunnyvale), and we’d love to have you join us. Sign up on Upcoming to let us know you’ll be stopping by at Yahoo! HQ for some beer and general revelry. We look forward to showing off some of the stuff you all have been doing with YUI in the past two years and we’ll talk a bit about where Patterns and YUI are headed from here.

(Via Yahoo! User Interface Blog.)

Google Gadgets for the Mac

Google Gadgets for the Mac: „Posted By Mike Pinkerton, Software Engineer

Earlier this year, I posted here to introduce Google Desktop for Mac OS X. Today, on behalf of my team, I’m happy to unveil the latest feature of Desktop: Google Gadgets for Mac OS X Beta.

This feature brings hundreds of existing Google Gadgets to Dashboard. You can add fun gadgets (such as bowling, virtual flower pot, or YouTube), useful gadgets (weather maps, driving directions, and news), and others that offer daily wisdom for the ages (Confucius, horoscopes, and even a joke of the day!). These gadgets look and behave just like any other Dashboard widget, so you don’t have to learn anything new.

With hundreds of gadgets available and more being added every week, you might wonder how to get started. No problem! The Google Gadgets application is your one-stop shop for all available gadgets, complete with search to quickly find what you’re looking for. If you’re concerned you might miss out on new gadgets as they come along, don’t be. The Google Gadgets application regularly updates itself so the list of available gadgets is never out of date.

You can download the new software at

The best part is that anyone can create a gadget. If you are interested in developing your own Google Gadget, check out the Desktop Gadget API homepage. There you’ll see how to create a cross-platform gadget that runs on both Mac OS X and Windows. If you’re already a gadget developer, download the Beta today to test your gadget on a Mac and ensure that it works correctly.

We need your help and your feedback to make this Beta an even better product. Please come visit our forum and let us know how we can do that.“

(Via Official Google Mac Blog.)