I wish to comment on the recommendation that NodeLists returned by
the selectors API will be static.
I feel this removes one of the great benefits of live collections,
that is, that once a collection is created, it is automatically
updated by the browser itself. This provides the possibility of
creating a collection once and reusing it without having to create it
again.
If the static NodeList model is maintained, it either means that the
NodeList will have to be re-created every time a function wishes to
access it, or separate native functions will have to be written to
update the collection as the document is modified. The second
approach is clearly less than optimal as there may be functions
modifying the document that the native methods aren't aware of.
I suspect there are two motivations for the choice of static
collections:
1. A number of popular javascript libraries have selector APIs that
return static arrays, therefore a change to live collections would
place them at a disadvantage
2. Novice script writers are confused by live collections
In regard to the first issue, I believe it can be worked around quite
simply by those libraries providing an option to return live or
static collections. Then users have the choice of which type they want.
For the second issue, it is a matter of user (i.e. script programmer)
education. The current libraries hide live collections behind APIs
that return static collections, often novices start out using a
library and are never exposed to live NodeLists. Also, there are
only a limited number of live collections and their use has not been
greatly exploited.
I have been told that the reason for not having live collections is
for performance, but I find that hard to understand. The current
live collections are much faster than their native javascript
emulations, I can't see that getting a collection every time it is
required will be faster than getting it once and using it many times.
For your consideration.
Robert Green
