Phase2Results.php" ); ?> Client Element Hash - RuntimeWiki

Client Element Hash

From RuntimeWiki

Jump to: navigation, search



Hashes for DOM elements and associated API.

Detailed write-up


There are basically three approaches to attaching data and behavior to an element:

  • Add an expando to the element (that requires cleaning up and can cause conflicts)
  • Composition (wrap an object around the element)
  • Have a mapping from elements to a table containing the extra contents

That third approach is very interesting because it doesn’t require cleaning up as there are no references between the DOM and JS hanging around. But it requires some sort of unique hash for each element.

It would be interesting if the browsers could generate a unique string for each element (whether or not it has an id) and a way to get back an element from its unique string.

Why Is This Important?

All Ajax frameworks associate extra data to DOM elements. To achieve this in an efficient and unobtrusive way, it is necessary to have a form of element hash, which doesn't exist natively today.

Background material that request this feature

What's New in 1.2: Element Storage


Jon Ferraiolo's comments

We are still early in the discussion, but my thinking is that pragmatism is a big factor in ranking our feature requests, where we have to accept the fact than any proposed new features for browsers will take <n> years to get implemented across all existing browsers and then another <m> years for users to upgrade their browsers on a broad-enough scale such that Ajax toolkit developers can count on the new feature, and thereby rewrite their libraries to toss out older programming techniques and switch over to new techniques that take advantage of the new feature. Therefore, I will tend to place my votes on feature requests that allow the Ajax toolkit community to adopt on an incremental basis, where there is a transition strategy where the toolkit can use existing techniques with older browsers and faster/better techniques in newer browsers.

One question I have on this feature request is whether there is an incremental approach that Ajax toolkits can adopt such that the element hash approach can be used in newer browsers but existing approaches can be used in older browsers. Or would this feature require a cold-turkey switch from old approaches to new approaches?

Let's assume for the moment that this feature can be taken advantage of on an incremental basis. The next question is whether there are better technical approaches for accomplishing the same result. For example, suppose XBL were implemented across all of the popular browsers. Would this be a more robust technical solution than the element hash approach? XBL1 as implemented in Mozilla isn't all that complicated and doesn't require all that much code in the browser, although W3C's current work on XBL (i.e., XBL2) is more complicated and the standards process is likely to take a long time. I mention XBL just as one other potential solution to the problem. There are probably several others.

[Comment by Brad Neuberg to Jon's comment] Jon, who says it will necessarily take years for some of these features to propagate? What if we use Gears, which is open source and exists cross-browser, to augment the browser runtime with some of these features? Gears can auto-update and can push these new features into existing browsers quickly (dependent on Gears getting a larger installed base -- Google backing it helps in this department). Disclosure: I work with Google on Gears.

Bertrand Le Roy's comments

This can clearly be done incrementally: libraries are doing this today with lookup tables, expando attributes on elements to store the lookup key, and references to the DOM element from the JavaScript side (which often requires cleanup). This approach could be replaced with cleaner (loosely coupled) and better performing native element hashes where available.

Even if XBL gets implemented everywhere, there will always be a need to store custom information about an element.

Andrew Dupont's Comments

Automatic keying of DOM nodes is nice, but having to key the nodes manually isn't my biggest pain-point by far. This feature would be much more useful if the relationship were two-way: if, given a hash, you could retrieve the element via a native browser API. You can't get this two-way relationship right now unless you use the ID attribute, and it'd be invasive (and slow) of libraries to annotate elements with IDs willy-nilly.

IE's sourceIndex property is a good model — its value is also the position of the element in the document.all collection, so if you know an element's sourceIndex you have a path back to the element itself. Except an element's sourceIndex is capable of changing with every modification to the DOM tree; we need a guarantee that an element's hash will remain the same over the life of the element and/or page.

Bertrand Le Roy's comments

Andrew's right that this is really useful if it's two-way: you can get a hash from an element and get an element from a hash. Dave Reed pointed out to me that IE already has uniqueId and uniqueNumber on all elements. The API to retrieve an element knowing its uniqueid is simply getElementById. This looks like an interesting model for the other browsers to implement.

Phase I Voting - Vote for Your Top 5 Features

NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:

Phase II Voting

More about this later.

Personal tools