Sweeping Design

Those seeking a solution to the Z-Index bug in IE7 which causes thumbnails in the Spry Gallery Widget to grow underneath subsequent thumbnails should see this thread in the Spry Forums. I happened to be working on the problem for a client site as another Spry User asked for a solution in the forums.

Spry Galleries use this structure:

<div id="thumbnails">
  <div class="thumbnail">
    <a href="image.jpg"><img src="image.jpg" /></a>
  </div>
</div>

In short, the solution to the problem is to change the z-index of the thumbnail img’s containing ancestor. I initially tried changing the z-index of div.thumbnail on the suggestion of Adobe Developer Kin Blas, but found - as he’d found before - that when thumbnails shrink back to normal size, they return to the top left corner of the ancestor, ignoring any margins or padding applied to the img.

I eventually found success by setting position:relative on the surrounding anchor (div.thumbnail a) and setting margins and padding to the surrounding div.

Relevant code (from SpryThumbViewer.js) and CSS follow. I’ve also retained a demo.

growThumbnail:

Spry.Utils.addClassName(img, "inFocus");
+  var ancestor = Spry.Utils.getAncestor(img, "a");
+  ancestor.style.zIndex = 150;
        img.style.zIndex = 150;

shrinkThumbnail:

var self = this;
+  var ancestor = Spry.Utils.getAncestor(img, "a");
        Spry.Utils.addClassName(img, "inFocus");
        this.sizeAndPosition(img, 0, 0, this.thumbWidth, this.thumbHeight, function(b){self.behaviorsArray[img.spryID] = null;
        Spry.Utils.removeClassName(img, "inFocus"); });
        img.style.zIndex = 1;
+       ancestor.style.zIndex = 1;

CSS

#thumbnails div {
margin: 12px 8px;
width: 168px;
height: 112px;
float: left;
}
 
#thumbnails div a {
display:inline;
float:left;
height:112px;
width:168px;
position:relative;
}
 
#thumbnails div a img {
border: 1px solid #999999;
height:112px;
width:168px;
position:absolute;
}

Just thought I’d share a tip about making Tabbed Panels more flexible with the CSS Selector.

In working on the Menu page for The Bank Restaurant and Wine Bar, I needed Tabbed Panels with the same custom scroll bar I used on the rest of the site. I chose the fleXcroll kit because it is flexible, unobtrusive, and cross-browser compatible (if poorly documented). Once you figure out how fleXcroll wants you to give it the elements of your scroll bar, activating it is as easy as adding the “fleXcroll” class to the div you want scrolled. This was the same div which wraps my Tabbed Panels (div.TabbedPanelsContentGroup).

No problem, I thought, as fleXcroll makes a big deal about how it “can cope with dynamic updates such as dynamic content injected via AJAX.” The problem, though, is that that Tabbed Panels can’t cope with the wrappers fleXcroll injects inside the panel container, as Tabbed Panels depends on a clean and fixed hierarchy to identify panels as direct descendants of that container. Tabbed Panels thought the fleXcroll wrappers were panels, and things just didn’t work.

Luckily, the CSS Selector provides a much easier method of finding panels and tabs than traversing a fixed hierarchy. Instead of identifying tabs as children of .TabbedPanelsTabGroup (which is identified as the first child of the div you give to Tabbed Panel’s constructor) and panels as children of .TabbedPanelsContentGroup, you simply identify tabs as Spry.$$(”.TabbedPanelsTab”) and panels as Spry.$$(”.TabbedPanelsContent”)!

In SpryTabbedPanels.js, tabs and panels are collected with getTabs() and getPanels():


  var tabs = this.getTabs();
  var panels = this.getContentPanels();


To escape the hierarchical bounds of Tabbed Panels, you just have to change:


Spry.Widget.TabbedPanels.prototype.getTabs = function() {
  var tabs = [];
  var tg = this.getTabGroup();
  if (tg)
    tabs = this.getElementChildren(tg);
  return tabs;
};

to:


Spry.Widget.TabbedPanels.prototype.getTabs = function() {
  var tabs = [];
  tabs = Spry.$$(".TabbedPanelsTab");   // or your selector of choice
  return tabs;
};

and:


Spry.Widget.TabbedPanels.prototype.getContentPanels = function() {
  var panels = [];
  var pg = this.getContentPanelGroup();
  if (pg)
    panels = this.getElementChildren(pg);
  return panels;
};

to:


Spry.Widget.TabbedPanels.prototype.getContentPanels = function() {
  var panels = [];
  panels = Spry.$$(".TabbedPanelsContent");  // or your selector of choice
  return panels;
};

SlickSpeed Selectors Test for Frameworks measures the time javascript frameworks take to return elements with their CSS Selector functions. SlickSpeed is developed by MooTools, but aims to offer unbiased results (indeed, Prototype beat MooTools in my test).

I couldn’t find any results for Spry, so I downloaded the test kit from its home at Google Code. I included Spry 1.6, Prototype 1.6, MooTools 1.2b1, and Dojo 1.0. I tested the default selectors against the default template (an excerpt from As You Like It). I ran the test under Firefox, but will update with results from IE7 and Safari 3 with more toolkits another day. You can run the test yourself here.

Prototype 1.6 and MooTools 1.2b1 basically tie at about 250ms, while Spry and Dojo take about twice as long.

Spry may be excused for finishing last as Adobe just introduced the Spry.$$() CSS Selector in its latest pre-release version 1.6.