If you need to store just key/value pairs mapped to an element, why not use the new jQuery.data method (aka "Expando Management")? I'm using this in a caption plugin I'm writing to store the id of the caption element to its image. The code is fast and has been working super smooth for me, I prefer it to a global lookup table. It's easy to miss the documentation for it, I only see it here:
http://docs.jquery.com/Release:jQuery_1.2/Internals Charles doublerebel.com On Sep 23, 4:31 am, "Erik Beeson" <[EMAIL PROTECTED]> wrote: > > I do it like this: > > <div id="div1" class="{field1: 'value1', field2: 'value2'}"></div> > > It costs more performance-wise, but I think it is worth it in terms of > > flexibility and clarity, which is why I went out of my way to fine- > > tune the metadata plugin. > > I went with the nested script block because I think it's the only way that's > actually valid HTML. The custom attribute version could at least be valid > XHTML (I think?), but the "data in the class attribute" version makes me > cringe to think of what the poor browser must be trying to do with that data > (like look for a CSS definition for a class called "{field1:" or some such). > I know it works, it just pains me a little to see, and I couldn't bring > myself to use it. > > About short-circuiting, I said it was un-reliable because it wasn't > > > being used by my browser. Now I've looked over the original code and > > realised that the original statement was: > > if ( this.nodeType == 9 || $.isXMLDoc(this) || this.metaDone ) return; > > ...when it should have been... > > if ( this.metaDone || this.nodeType == 9 || $.isXMLDoc(this) ) return; > > ...in order for short-circuiting to work. Indeed, this would have > > stopped $.isXMLDoc(this) being executed over and over again. > > Right. I'm not sure why metaDone isn't checked first anyways. Regardless of > the addition function call(s), it seems like the logical thing to check > first: "if we haven't already done this, and it isn't X or Y... then do it". > Not "if we shouldn't do it because of X, or if we shouldn't do it because of > Y, or if we shouldn't do it because we already have." > > It's probably worth opening a bug report for these issues that you've raised > so that they don't get lost. > > --Erik