Forums

Here's a recap of some of the interesting moments from the call (that I managed to write down):

Tip: Anim supports passing a function to calculate to/from values as a first step when run() is called. E.g.

Using a function for a to.height anim value

Click here to see the revision history on this Gist.

Event Binder is used to handle user interaction that might occur before the application logic is set up, or even before YUI is loaded.

A couple approaches to setting up the pre-lib event capturing are:
http://gist.github.com/453059
http://gist.github.com/447676

It was suggested that we could turn the config setup into a game of code golf! (For fun, of course. Golf is bad for maintainability)

There was some functional overlap noted between gallery-event-binder and Eric F's gallery-component-manager-base (http://yuilibrary.com/gallery/show/base-componentmgr), so there may be room here for collaboration.

Caridy pointed out that there is a gap here for pages that leverage multiple instances of YUI. The pre-lib caching will have no idea about which instance the event is relevant to, and because the YUI instances are properly sandboxed, they won't know if there are other instances that might need access to the events for redispatch. In short, the single global subscription model gets a little hairy on pages with multiple YUI instances, and he asked for suggestions.

In the discussion about Slider's DOM structure and skin loading strategy, Eric F briefly described his approach at progressive enhancement without a FOUC. Eric, if you want to describe that or link to it here, that would be great.

Anthony P (apipkin) suggested a sliding doors technique in response to my raising the issue of maintaining a flexible layout plan when balancing the needs of a rail with end caps and thumb that might need to be limited inside the rail boundaries or move outside them. Anthony, if you want to elaborate on that here, that would be great. The solution I'd settled on when creating Slider was to allow implementers to use the 'gutter' config of DDContrain plugin used with the thumb's Drag instance to limit or extend the boundaries of the draggable area, and use long or short end caps to affect a smaller draggable area in a custom skin. This is an incomplete solution, though, so I welcome further discussion on the point.

Another tip: Use Y.Env.____ as a storage place for module state that must be managed globally on the page. This should be a rare occasion, such as when leveraging JSONP (as does the gallery-jsonp module) or monitoring a location hash change as is done by the History Lite module.

Charles reminded us that configuring skins for Gallery modules is different today than for core modules. Definitely still rough around the edges, and it's on our todo list to make that easier. Suggestions are welcome, of course!

From Jeff's Slider resource walk through, he noted that the layers are set up to allow changes to be applied to one layer to apply color theming. The primary reason for more complex layering is the requisite antialiasing for rounded corners. To preserve the right shades for the corner pixels, they need to be color shifted to match the underlying background or they end up looking like awkwardly colored sharp corners.

The resources in the linked zip bundle include reference lines to help skin developers align new bitmaps with the css that manages the current skins. That way, implementers could create a new thumb image, but continue to use the css associated with one of the known skins (caching bonus).

...

That's all I remember or wrote down. By all means, add the stuff you remember or thought particularly useful.

I'll create a new thread for the next Open Hours when the topics and guest(s) are finalized.