"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
<snip>
... . However, I'm not sure of the extent to which one
should test[1]. If anyone can answer that question,
I'd be most grateful.
<snip>[1] Should *every* property and method accessed be tested?
If a member is supported by one element, say replaceNode
on a HTMLDivElement, can it be assumed that is will also
be supported on another element, say a HTMLSelectElement?
Generally it must be safest to confirm the existence (and to some extent
behaviour) of everything prior to using it and, given that everything is
potentially subject to modification, probably to continue testing it as
the script executes.
In practice continually checking everything would be extremely
inefficient and it doesn't seem too unreasonable to assume that if a
feature exists when tested the first time is will continue to exist.
Obviously subject to the script itself not altering it.
While the user is in a position to execute javascript URLs at any point
and so modify the environment in most respects they are not going to do
that. Some things, like killing off onsubmit and oncontextmenu handlers,
might be reasonably common but users are unlikely to be modifying DOM
Core methods in a running page. And if the user has an attitude about
submit handlers or interfering with the contextmenu they will probably
run something like Proximatron and the consequences will be stable once
the page has loaded.
Mostly I would assume that the DOM is stable and that a feature that
exists for one test would exist for all subsequent tests. Indeed for
scripts where execution speed is significant I prefer to have an
initialisation function set-up a script for execution, verifying *all*
the features required by the script and doing things like assigning one
of a number of feature specific functions based on the results of those
tests (usually as methods of JavaScript objects/prototypes). If the
tests are passed then the script is allowed to execute freely without
re-testing the features required, though it remains a good idea to
verify that, for example, elements looked-up in the DOM by ID are not
returned null.
There are also times when I would not bother to test every feature
because some exist in pairs, such as pageXOffset and pageYOffset. If I
have verified that typeof pageXOffset == 'number' it seems reasonable
that pageYOffset is also a defined number property in the environment.
Though all of the examples of this I can think of right now are related
to X/Y co-ordinate pairs, widths and heights, and top and left values.
It cannot be carried as far as groups of properties such as
clientWidth/Height/Top/Left as browsers exist that have
clientWidth/Height but do not define clientTop/Left. The pairs exist
together but not the whole group.
An area of particular danger is to assume, for example, that confirming
the existence of any one feature of the DOM Core Node interface method
is a basis from which the other features of that interface can be
inferred.
But the gist of your question is more the extent to which the existence
of features on one object can be used to infer the existence of the same
feature on another object.
If two objects are DOM elements of the same type I would assume that a
positive result for a feature on one is a basis for assuming that the
same feature would exist on the other. For elements of different types I
would tend to be more cautions but in reality it does seem to be the
case that if any element has a feature that would be expected to be
common to all elements then it is common to all elements. With a number
of caveats: specifically, in IE 4 elements within the HEAD are not as
amenable to dynamic modification as elements in the BODY, and in IE 5
the W3C Core DOM Level 1 Node interface is implemented on all DOM
elements _except_ for the document.
That implies that inferring that features found on an element within the
BODY will be both present and functional on elements within the HEAD may
be problematic, and that inferring anything about the document from any
element within the document may not be valid, even if the feature is a
DOM Core Node interface method that Document *should* implement. So
inferring that a verified common feature of one element will be present
on another of a different type is probably reasonable so long as the
inference is not carried too far.
How far is too far is going to be a matter of judgement, but it must be
better to err on the side of caution. And if well implemented even a
strategy of cautions and comprehensive testing does not have to
significantly impact oh the performance of a script.
It is probably worth mentioning that there is one browser feature that I
don't think that I have ever bothered to verify, and that is -
document - as a property of the global/window object. Perversely that
is one property/feature that does not appear in a single pertinent
specification, but without it virtually nothing is possible.
Richard.
