469,353 Members | 2,061 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,353 developers. It's quick & easy.

Simple question

I need a simple HTML element whose text I can change dynamically.
What is it? (it doesn't seem to be <div>, since I can't seem to find
what properties a <div> has...)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jul 20 '05 #1
3 1439
On Tue, 27 Jan 2004 15:22:58 +0000 (UTC), Christopher Benson-Manica
<at***@nospam.cyberspace.org> wrote:
I need a simple HTML element whose text I can change dynamically.
What is it? (it doesn't seem to be <div>, since I can't seem to find
what properties a <div> has...)


You can use any element that can contain text: P, DIV, A, SPAN, TD. The
list goes on. You can alter the contents of these elements with either
DHTML (shudders) or the DOM (Document Object Model). However, only newer
browsers will support your website.

Two examples are presented below. The first is written utilising the DOM,
the second uses DHTML. Both assume that a DIV element exists with the ID,
"example".

DOM:

var elem = document.getElementById( 'example' );
var newText = document.createTextNode( 'Your new text' );

elem.appendChild( newText, elem.firstChild );
DHTML:

var elem = document.all[ 'example' ];

elem.innerHTML = 'Your new text';

Though the latter is shorter, the former is preferred for the reason that
it is supported by a wider cross-section of browsers.

That isn't the end of it, unfortunately. As I have already mentioned, some
browsers might not support one of these approaches. Some older versions
might not support either of them. This is where feature testing is
applied. Before you access any method or properties that compose an
object, you should check that the browser has implemented them. 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.

Mike
[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?

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 20 '05 #2
: I need a simple HTML element whose text I can change dynamically.
: What is it? (it doesn't seem to be <div>, since I can't seem to find
: what properties a <div> has...)

You can view http://dns.djwice.com/ or and /next.php
The first one works in most browsers (also older ones since 2000).
The second one has more functions (add and remove elements to a list
(hotmail add e-mail to list)) but will not work in older browsers that do
not support such.

Wouter
Jul 20 '05 #3
"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.
Jul 20 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by gene.ellis | last post: by
2 posts views Thread by Kirk | last post: by
2 posts views Thread by Anurag | last post: by
3 posts views Thread by Peter | last post: by
1 post views Thread by Chris | last post: by
7 posts views Thread by abcd | last post: by
2 posts views Thread by Allain B√łge | last post: by
17 posts views Thread by AlBen | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.