Client Scoped ID
From RuntimeWiki
NOTE: This feature has been moved to the inactive list due to discussion at the OpenAjax F2F meeting on 2008-03-21:
Basically, there appear to be other ways to achieve the underlying requirement that won't require fundamental changes to how IDs are processed on the Web.
Contents |
Title
Support for locally-scoped IDs
Detailed write-up
Description
As Ajax applications are more and more generating UI on the client, it is getting common for frameworks to expose templating mechanisms that enable among other scenarios the repeating of an HTML fragment over a data set. It is very useful when doing so to be able to retrieve a specific element by id from a template instance. Currently, ids are supposed to be unique throughout the document, which is a problem for repeated contents as you either have to massage the ids from the template to make them unique or you need a browser API that enables searching of an id within the specific scope of the template instance.
Why Is This Important?
Templating repeated contents is an increasingly important feature of Ajax frameworks and the lack of scoped ids is getting in the way of simple and fast implementations.
Background material that request this feature
Discussion
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.
The world seems to have muddled through without browser support for scoped IDs. There are various techniques for getting around the problem, often ugly, but not more ugly than varous other things that a developer needs to do. If scoped IDs started to become available in some browsers, most developers couldn't take advantage of them until the feature was deployed on a fairly universal basis.
From a standards perspective, it probably doesn't make sense to attempt to take the 'id' attribute in HTML (or the ID concept in XML) and try to change its semantics such that in the future it no longer means unique within the same page but instead just unique within a given tree. The ID features in HTML and XML are too fundamental to attempt to change. Instead, if such as feature were pursued, what we might want instead is a fast implementation within browsers for finding an element within a subtree where the value of a particular custom attribute (e.g.,'ScopedID') whose value matches a given string. For example,
element = document.getElementByAttributeValue(rootelement,attrname,attrvalue);
One of the virtues of this approach is that Ajax libraries could implement the above functionality in JavaScript for older browsers that do not support that API yet.
Even better than document.getElementByAttributeValue(...) would be if the browsers all implemented XPath APIs on a reasonably complete basis. See the related feature request XPath Support.
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.
