Blog: Archive for June, 2008

I love YUI Grids. I know my CSS and I know how to work around different problems of browsers, but I am also very much bored about having to fix and test and create these workarounds over and over again. While YUI Grids might not be perfect for all cases of web development out there, I am happy to take a pragmatic approach and just create sites that can be done with them (now you also know why I am not a designer).

One problem I keep having when I put some YUI Grids-based sites live is that people complain about me expecting a certain screen resolution or viewport size. YUI grids can either be 100% wide, which can be pretty silly on high resolutions, or optimized for resolutions of either 800×600 or 1024×768. When you optimize for 800 pixels people on higher resolutions will complain about the length of the page and when you go for 1024 people will say they have to scroll to see your side-bar on 800×600. You can’t win.

Or can you? CSS is not dynamic — it has a fixed state and you can only hope that the browser does the right thing with what you give it (well, there are conditional comments for IE, but technically they are HTML, and of course there are media queries in CSS3 and other goodies, but for the sake of the argument let’s say supporting IE6 is a base). JavaScript, on the other hand, is very dynamic and you can read out and check what is happening to the browser currently in use and react to it.

Putting this feature of JavaScript to good use you can create a YUI-Grids-based layout that remains flexible and changes according to needs. All you need to do is use some YUI Dom magic and change IDs and classes accordingly.

YUI Grids come in several flavours of overall width, defined by the ID on the container DIV:

• #doc – 750px centered (good for 800×600)
• #doc2 – 950px centered (good for 1024×768)
• #doc3 – 100% fluid (good for everybody)
• #doc4 – 974px fluid (good for 1024×768)
• #doc-custom – custom width

One thing to remember here is that even doc3 has a minimum width of 750 pixels, which is why for a fully flexible grid you need to override that:

#doc3{
  min-width:0;
}

Inside the container DIV you can have two blocks, and their width and the position of the side bar is defined by the class on the container DIV:

• .yui-t1 – Two columns, narrow on left, 160px
• .yui-t2 – Two columns, narrow on left, 180px
• .yui-t3 – Two columns, narrow on left, 300px
• .yui-t4 – Two columns, narrow on right, 180px
• .yui-t5 – Two columns, narrow on right, 240px
• .yui-t6 – Two columns, narrow on right, 300px

Putting these together you can create a plan for your flexible grid:

• When the available screen space is larger than 950 pixels, use doc2 and the widest sidebar — either left or right
• If you have less than 950 pixels, use doc and the medium size sidebars
• If you have less than 760 pixels, use doc3 and the smallest sidebars
• If you have even less — say 600 pixels — at your disposal, show the side bar below the main content

The script to allow for this is not really rocket science. All it needs to do is read out the grids settings, the width of the available browser window and then change the IDs and classes accordingly.

YAHOO.example.autoGrid = function(){
  var container = YAHOO.util.Dom.get('doc') || 
                  YAHOO.util.Dom.get('doc2') || 
                  YAHOO.util.Dom.get('doc4') || 
                  YAHOO.util.Dom.get('doc3') ||
                  YAHOO.util.Dom.get('doc-custom');
  if(container){
    var sidebar = null;
    var classes = container.className;
    if(classes.match(/yui-t[1-3]|yui-left/)){
       var sidebar = 'left';
    }
    if(classes.match(/yui-t[4-6]|yui-right/)){
       var sidebar = 'right';
    }
    function switchGrid(){
      var currentWidth = YAHOO.util.Dom.getViewportWidth();
      if(currentWidth > 950){
        container.id = 'doc2';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t3' : 'yui-t6';
        }
      }
      if(currentWidth < 950){
        container.id = 'doc';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t2' : 'yui-t5';
        }
      }
      if(currentWidth < 760){
        container.id = 'doc3';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t1' : 'yui-t4';
        }
      }
      if(currentWidth < 600){
        container.id = 'doc3';
        container.className = '';
      }
    };
    switchGrid();
    /* 
      Throttle by Nicholas Zakas to work around MSIE's resize nasties.

http://www.nczonline.net/blog/2007/11/30/the_throttle_function

    */
    function throttle(method, scope) {
      clearTimeout(method._tId);
        method._tId= setTimeout(function(){
        method.call(scope);
      }, 100);
    };
    YAHOO.util.Event.on(window,'resize',function(){
      throttle(YAHOO.example.autoGrid.switch,window);
    });
    
  };
  return {
    switch:switchGrid
  };
}();

Let's go through it step by step:

YAHOO.example.autoGrid = function(){
  var container = YAHOO.util.Dom.get('doc') || 
                  YAHOO.util.Dom.get('doc2') || 
                  YAHOO.util.Dom.get('doc4') || 
                  YAHOO.util.Dom.get('doc3') ||
                  YAHOO.util.Dom.get('doc-custom');
  if(container){

First we check if there is actually a YUI Grid in the current document, by testing for the presence of the correct IDs. If there is, we execute the rest of the code.

    var sidebar = null;
    var classes = container.className;
    if(classes.match(/yui-t[1-3]|yui-left/)){
       var sidebar = 'left';
    }
    if(classes.match(/yui-t[4-6]|yui-right/)){
       var sidebar = 'right';
    }

We define sidebar as null, retrieve the class name of the container element and check if there was a column structure defined. In addition to the preset YUI Grids classes we also defined yui-left and yui-right here. These styles allow you to not have a sidebar without the script functionality but to get one once the script determines that there is enough space for one.

    function switchGrid(){
      var currentWidth = YAHOO.util.Dom.getViewportWidth();
      if(currentWidth > 950){
        container.id = 'doc2';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t3' : 'yui-t6';
        }
      }
      if(currentWidth < 950){
        container.id = 'doc';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t2' : 'yui-t5';
        }
      }
      if(currentWidth < 760){
        container.id = 'doc3';
        if(sidebar){
          container.className = sidebar === 'left' ? 'yui-t1' : 'yui-t4';
        }
      }
      if(currentWidth < 600){
        container.id = 'doc3';
        container.className = '';
      }
    };
    switchGrid();

The method switchGrid() does all the work we defined. We set up the different cases for applying IDs and classes and call the method immediately after it's been defined.

    /* 
      Throttle by Nicholas Zakas to work around MSIE's resize nasties.

http://www.nczonline.net/blog/2007/11/30/the_throttle_function

    */
    function throttle(method, scope) {
      clearTimeout(method._tId);
        method._tId= setTimeout(function(){
        method.call(scope);
      }, 100);
    };
    YAHOO.util.Event.on(window,'resize',function(){
      throttle(YAHOO.example.autoGrid.switch,window);
    });

For full flexibility, we also apply an event listener that re-checks the grid specifications when the user resizes the browser. As Internet Explorer has a nasty habit of firing the resize event while the user resizes the window, we need to throttle the execution of switchGrid(). This is explained in detail on Nicholas Zakas' blog.

  };
  return {
    switch:switchGrid
  };
}();

As the throttle method needs a public method to call from setTimeout() we return a pointer to switchGrid.

That's all. You can try out the effect on the demonstration page. If you define your sidebar independent of size, you can create some wonderfully dynamic and flexible sites with this little script.

The Yahoo! User Interface Library (YUI) has an ample assortment of
components. Nevertheless, there will be always some functionality you want that a library like YUI hasn’t anticipated or hasn’t built yet.
Sometimes you just want a subset of the many options a component might provide; in other cases, you may have a default configuration that you’d like to bake into a component to facilitate consistent use across your site. The flexibility built into YUI provides intrinsic support for extending, customizing, or creating wholly new components. If you find yourself in one of these situations, then building your own library of YUI-based components may make good sense.

This lengthy article is meant to get you started creating your own custom components using the tools available to you within YUI, including the Element Utility and the Event Utility. Understanding these tools can save you lots of time and make it easy to create API-driven components that expose powerful hooks to implementers making use of your work.

• Customizing Existing YUI Components
  • Using YAHOO.lang.extend
  • Creating and Using Shortcuts for Common YUI References
  • Registering a Component with YUI
• Developing Wholly New Widgets with YUI

• The YUI Element Utility as a Foundation for Component Development
• Managing DOM Events and Custom Events with Element
• A Closer Look at extend
• Element and AttributeProvider
• Adding a render Method
• Adding a Destructor
• Subclasses
• Bundling Functionality: The Field Object and the Fields Object

(more…)

We’ve been obsessed with the canvas tag for a while now; we think it represents a huge opportunity for creative interfaces on the web, and current browser support for the tag is excellent (as long as you don’t mind using excanvas.js for IE6/7). That being said, there are some limitations. The only available built-in transformations are translation, rotationg and scale. Performing a complex transformation, such as keystoning an image so that it can be used in a faux 3D environment, has been difficult.

However, there is an easy way to simulate arbitrary transformations on images in canvas. If you cut the image into slices, you can redraw each slice with different dimensions. The code is simple: using the slicing variation of the drawImage method, it’s possible to take a slice of a source image and draw it to the canvas. This slice can be scaled horizontally and vertically according to a formula. As the number of slices increases, the edges of the image become smoother and less jagged. It’s important to note that you only need one copy of the source image, and that drawing many slices doesn’t mean there are many copies of the image in the page. You are able to use one source image to draw multiple images on a destination canvas.

Creating a keystone effect looks complex but is actually very straightforward:

function keystoneAndDisplayImage(ctx, img, x, y, pixelWidth, 
								 scalingFactor) {
	var h = img.height,
	     w = img.width,
        
	    // The number of slices to draw.
	    numSlices = Math.abs(pixelWidth),
        
	    // The width of each source slice.
	    sliceWidth = w / numSlices,
        
	    // Whether to draw the slices in reverse order or not.
	    polarity = (pixelWidth > 0) ? 1 : -1,

	    // How much should we scale the width of the slice 
	    // before drawing?
	    widthScale = Math.abs(pixelWidth) / w,
        
	    // How much should we scale the height of the slice 
	    // before drawing? 
	    heightScale = (1 - scalingFactor) / numSlices;

	    for(var n = 0; n < numSlices; n++) {

		// Source: where to take the slice from.
		var sx = sliceWidth * n,
		    sy = 0,
		    sWidth = sliceWidth,
		    sHeight = h;
		
		// Destination: where to draw the slice to 
		// (the transformation happens here).
		var dx = x + (sliceWidth * n * widthScale * polarity),
		    dy = y + ((h * heightScale * n) / 2),
		    dWidth = sliceWidth * widthScale,
		    dHeight = h * (1 - (heightScale * n));

		ctx.drawImage(img, sx, sy, sWidth, sHeight, 
        			  dx, dy, dWidth, dHeight);
	}
}

We take slices from the source image one at a time, apply a horizontal and vertical transformation, and then draw it in the correct order. This also allows us to do something interesting; if the slices are drawn in reverse order, we can reverse the image. The keystone demo page shows this code in action. The two sliders control the values entered into the function as pixelWidth and scalingFactor. Keystoning has a lot of potential applications. For instance, If you animate both width and scaling, you can create a page turning effect for any image.

You can apply any transformation to the slices. If you were to scale the height of the slices based on a parabolic curve, you could create a cylindrical distortion that mimics a panorama view. We set up a Quicktime VR-style panorama using this technique. Be sure to view it with the rest of the canvas both shown and hidden to see how it works. It would also be possible to add an animating flag-ripple effect to any image, just by varying dy. We believe that image slicing transformations have a lot of applications in mimicing 3D environments and creating image effects. All you have to do is apply a formula to change the slice dimensions or position.

Mastering Grails columnist (and author of books on topics ranging from Java to GIS) Scott Davis gave a fantastic talk on using YUI with Grails at the 2007 Rich Web Experience in San Jose. Thanks to Jay Zimmerman and his No Fluff Just Stuff conference team, that talk is now available freely on video from the RWE website.

Modifying a DOM element’s style during user interaction is one of the
pillars of creating DHTML interfaces that transition from state to state in a
smooth, and (hopefully) intuitive way. Every HTMLElement in the DOM
contains style, a collection of properties corresponding to the
CSS properties understood by the browser. For JavaScript and CSS enabled browsers, the following two paragraphs would contain red text:

<-- Paragraph 1 -->
<p style="color: #f00">This paragraph is red</p>

<-- Paragraph 2 -->
<p id="x">This paragraph's color will be red after the JavaScript runs</p>
<script type="text/javascript">
(function () {
    var el = document.getElementById('x');

    el.style.color = '#f00';

})();
</script>

Even CSS properties that aren’t applicable to a given element will have representation in that element’s style collection. For example, even the <br> element will have the el.style.letterSpacing property.

Names have been changed to protect the innocent

The style property names in JavaScript are camel cased versions of their CSS
counterparts, so font-family in CSS becomes
el.style.fontFamily in the style collection. "float" is a reserved word in
JavaScript, so the CSS float property is given a different name. In Internet
Explorer, styleFloat is used, where Firefox, Safari, and Opera all
use cssFloat (Opera also supports styleFloat, actually). Additionally, each browser has a host of proprietary CSS properties that also show up in the style collection (e.g. -moz-border-radius, which becomes el.style.MozBorderRadius in Firefox). Other than styleFloat/cssFloat, the browser vendors largely agree on non-proprietary property names.

The madness and the method

I set out to document which properties were present in each A Grade browser’s style collection (making no claims about their functional support for specific values).

For each browser, I used a simple for (var prop in el.style) method to iterate the style collection, and cross checked in a development tool if available. Specifically, I used the following:

* – Safari does not enumerate unassigned style properties, so for ( in ) doesn’t show anything useful.

All tests were done on a Macbook Pro running OSX 10.4. The IEs and FF2 were tested on Parallels instances running Windows XP. I only documented properties that weren’t prefixed with a vendor identifier (e.g. -moz), and omitted methods and meta fields such as setProperty and length. The only exception to this being cssText, which I’ll talk more about later. So without further ado…

(more…)