I needed a way to provide my users with a date picker that was automatically provided when a text area received focus.  I was eager to use the excellent YUI calendar as a starting point, but the provided documentation didn’t provide a solid example for this type of implementation.

Dav Glass has provided a solid example of the Calendar tied to a text input. But, his example is highly dependent on the text input having specific ids.  This doesn’t take advantage of YUI’s excellent Selector library really didn’t meet my need for a simple universal solution.

Key Requirements:

1. Progressive Enhancement (No inline javascript)
2. Yui based
3. Universal implementation across all pages in a site.
4. Support for multiple date inputs on a page.

Getting Started:

Source:

Adding it to your page

Integrating the code into the page is VERY easy.

In the header of the page add the following css includes.

<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/combo?2.6.0/build/calendar/assets/skins/sam/calendar.css">

YUI has announced a major new release with the  immediate availability of YUI 2.4.

Key Features:

• Selector Utility: Following in the footsteps of most other toolkits, YUI now includes a CSS Selector.  This beta component includes much of the standard CSS3 selector syntax including the proposed Selector extensions.
• Charting: Using a hybrid Flash / Javascript model, a new charting component has been released with support for bar, line and pie charts.  Of special note is the fact that the charting utility utilizes the same data model as the data table implementation allowing hybrid chart / table interfaces.
• Get: dynamically load scripts and nodes via the new Get tools.
• Profiler: This combined with YUI Test will allow you to quickly and efficiently determine profiles and unit tests.  Most notably, profiler allows unit tests based on performance to be performed.
• JSON Utility: dramatically improved JSON support.

Behind the scenes:

Incremental improvments to: Calendar, Drag & Drop & Button controls.

Dramatic enhancements & customization support added to the Rich Text Editor:

Read about the release here:

http://yuiblog.com/blog/2007/12/04/yuii-240/

Today we conclude our series of posts on space & dimension with an exploration of YUI’s Spacial capabilities. Many of YUI’s capabilities aren’t readily apparent from the component level documentation. One exception are the setXY & getXY functions.

• setXY & getXY operate on the top left corner of an Element relative to the top left corner of the document.
• A companion getXY is provided with the YUI event object to determine the location of clicks.

A look at YUI’s API’s reveals a second, powerful class for dealing with 2d space. The YUI region class is a representation of an object on a grid. Region provides the top, left, right & bottom locations in a rectangular shape. Region is not a tool for manipulating the dom, rather it is a utility class for determining the union, intersection, area and other properties of a defined rectangular area.

YUI lacks many of the capabilities for handling scrolls, widths & heights we’ve encountered in other toolkits but still provides a reasonably capable set of tools with which to handle locations within a document.

Let me start by saying that I love CSS frameworks.  From Tripoli to Blueprint, YUI to YAML, I’ve embraced them fully into my design and development process over the past 9 months.  Unfortunately, throughout that time I’ve had to deal with a nagging issue: The Semantic Web.

CSS exists to shed the shackles of inline formatting and truly separate content from display.  While It’s rarely possible to achieve all of a project goals in a semantic way, CSS frameworks really fly in the face of a semantic approach. Don’t get me wrong, I still think CSS is the way to go and that frameworks provide powerful scaffolding, but I think we all need to be aware that using CSS grid & layout frameworks isn’t exactly a true separation of content & styling.

Take for example, blueprint.  Blueprint contains a powerful set of tools for building a layout.  Unfortunately, these tools require that columns be explicitly defined in the page source <div class=”column span-2″>.  This makes it impossible for a change in stylesheet to completely alter a page layout for mobile devices without discarding the column & span classes and relying on an independent set of markup e.g. <div class=”column span-2 mobile-column mobile-span-5″>.  This is a rather cumbersome noose to have to carry for some projects.  Especially when the infrastructure isn’t in place to deliver two distinct versions of the site from the server.

I’m wondering how you have addressed these problems in past projects?

The YUI toolkit includes an entire family of Menu widgets with support for:

• Screen Reader Accessibility
• Keyboard and Mouse Navigation
• A Rich Event Model that Provides Access to all features
• Support for Progressive Enhancement; Menus can be created from simple html  structures or 100% in javascript.

More Information:

http://developer.yahoo.com/yui/menu/ 

Give Choice to your users with a truly flexible Color Picker Widget:

The YUI Color picker has been around since 2.3 and I’m trying to find an excuse to use it in a project.  It’s easy to implement & play with and quite powerful.  Unfortunately, I keep finding it a bit too powerful to give to my users.  The one time I tried using it in a light weight CMS the site turned into a Lime Green monstrosity.

Does anyone have any experience implementing color pickers?  What do you do to enforce visual styling? 

I encourage you to take the widget for a spin at:

http://developer.yahoo.com/yui/colorpicker/#start

Then come back and brainstorm ideas with me in the comments.

YUI provides for the creation of forms dynamically without the need for pre-existing markup through the Button object.

Despite its name, the button is a rich widget that supports the creation of:

• Push Buttons
• Link Buttons
• Submit Buttons
• Reset Button
• Checkboxes
• Radios
• Menus
• Split button (hybrid button menus)

Today we are exploring the creation of buttons dynamically from javascript.   Creation itself is simple. 

The syntax is:

 var oButton = new YAHOO.widget.Button({ id: "mybuttonid", type: "button", label: "My Button", container: "someelement" });

Where:

• id = the id of the element to be created
• type = the type of button (push, link, submit, reset, checkbox, radio, menu or split)
• label = the visual label to display
• container = the element in which to append the button.

Id and type are optional, Defaulting to a randomly created ID & "button" respectively.

After yesterday’s comment regarding my display:none / innerHTML hack on building a YUI panel.  I thought I’d quickly show you how to build a panel from markup without the display:none;

For a quick refresher, I recommend you read: http://www.ajaxbestiary.com/2007/09/19/building-a-form-in-a-modal-panel-with-yui/

Now, to achieve the same results we can do the following.

1. Remove the display:none from the panel div
2. Place the form into a <div class="bd"> tag
3. Place the form header in a <div class="hd"> tag before the bd tag but inside of the panel div.
4. If you’re going to add a footer, place it after the <div class="bd"> tag inside of a <div class="ft"> tag
5. Replace the instantiation command with myPanel = new YAHOO.widget.Panel( "panelid"); where "panelid" is the id of the div wrapping the various panel containers. 
6. You now have a panel to render, show, hide & modify based on your page content.

I apologize for the shotgun approach to this post, but I thought it was a handy correction to get out there.

Building a Modal Filtering List with YUI

In this tutorial we will build a simple form and embed it in a modal panel.

Building the form
There are two approaches we could take towards building the form : dynamic or static. A dynamically loaded interface is built by the javascript executed on page load, a static interface lurks hidden inside the html source and is displayed when needed. For the sake of simplicity, we will be using a static interface in this tutorial.

Our form is quite simple. It consists of 3 tiers of options and a submit button:

<div id="filterpanelform" style="display:none">
<fieldset><legend>Type</legend>
<input name="type" value="berry" type="checkbox">Berry
<input name="type" value="citrus" type="checkbox">Citrus
<input name="type"value="drupe" type="checkbox">Drupe
<input name="type" value="Melon" type="checkbox">Melon
</fieldset>

<fieldset><legend> Size </legend>
<input name="size" value="small" type="checkbox">Small
<input name="size" value="medium" type="checkbox">Medium
<input name="size" value="large" type="checkbox">Large
</fieldset>

<fieldset><legend> Color </legend>
<input name="color" value="red" type="checkbox">Red
<input name="color" value="orange" type="checkbox">Orange
<input name="color" value="yellow" type="checkbox">Yellow
<input name="color" value="green" type="checkbox">Green
<input name="color" value="purple" type="checkbox">Purple
<input name="color" value="pink" type="checkbox">Pink
</fieldset>

<button value="Filter" name="doFilter" type="button"id="doFilter">Filter</button>
</div>

Notice the style=”display:none;” on the containing div? This is to hide the contents from view until our user calls the modal dialog.

Building the Modal Interface

Now we need to build a YUI panel to contain the filtering interface. Unlike the form elements, the panel we will build dynamically. The panel will be created on page load, but will remain hidden until called for.

// Instantiate a Panel from script
YAHOO.example.container.FormPanel = new YAHOO.widget.Panel("formPanel", { width:"320px", visible:false, draggable:true, close:true} );
YAHOO.example.container.FormPanel.setHeader("Form Panel");

//populate the panel with the form we've hidden in the HTML
YAHOO.example.container.FormPanel.setBody( document.getElementById("filterpanelform").innerHTML );

YAHOO.example.container.FormPanel.render("container");

Think of it as Visual Risk Management. 
As AJAX developers, we regularly place control over swaths of the DOM in the hands of our users and outside of our web designers control.  Sure, we can restrict the users capabilities, clean up word html, run things through validators, & provide all the styles needed, but these fixes require us to anticipate problems before they happen.

Using CSS frameworks, takes a lot of the risk out of the situation.  A CSS framework removes the risk of a user accidentally calling on a structure that hasn’t been anticipated or that isn’t properly styled by our existing stylesheets.   CSS frameworks take the guessing work out of the situation.  By reseting and frequently standardizing all possible html elements.  A CSS framework ensures that your markup behaves appropriately across browsers and user inputs.  It doesn’t matter what framework you use either.  In fact, a corporation’s professionally built CSS templates likely include all of the resets & standardizations needed.

If you don’t trust your stylesheets or are building one from scratch. I recommend you investigate the following frameworks.

• YAML
• Blueprint
• YUI CSS
• Tripoli
• Eric Meyer’s Reset CSS