VK said:
Or rather not.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"
http://www.w3.org/TR/html401/loose.dtd">
http://www.w3.org/TR/html4/loose.dtd
is the recommended URI, pointing to the latest HTML version.
<html>
<head>
<title>JavaScript</title>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
Use this only if you really know what you are doing. It is recommended
only for resources that are not served via HTTP. Because it is potentially
harmful for resources that are served via HTTP: the HTTP Content-Type
header takes precedence over this, and if both values are different, the
result is most certainly not what you would expect (without knowing this).
<script type="text/javascript">
function swap() {
var tmp = $('para1').innerHTML;
$('para1').innerHTML = $('para2').innerHTML;
$('para2').innerHTML = tmp;
The return value of $() should be tested before it is used with
property accessors, to avoid runtime errors.
`innerHTML' is a proprietary property that should be tested before
it is read or written to. Standards compliant access methods should
be preferred, mixing standards compliant and proprietary features
should be avoided.
tmp = document.forms['myForm'].elements['text1'].value;
document.forms['myForm'].elements['text1'].value
= document.forms['myForm'].elements['text2'].value;
document.forms['myForm'].elements['text2'].value = tmp;
One wants to optimize here:
var
es = document.forms['myForm'].elements,
text1 = es['text1'],
text2 = es['text2'];
tmp = text1.value;
text1.value = text2.value;
text2.value = tmp;
Further feature tests might be appropriate.
}
function $(id) {
return document.getElementById(id);
}
"The dollar sign is intended for use only in mechanically generated code."
(ECMAScript Language Specification, Edition 3 Final, 7.6 Identifiers)
And the method as is, allowing a shorter identifier aside, is entirely
redundant. It only adds up to stack memory usage.
</script>
</head>
<body>
<p id="para1">This is first line</p>
<p id="para2">Here is second line</p>
<form name="myForm" action="" method="post">
This `form' element does not need a name, ...
<input type="text" name="text1" value="This is first value"><br>
<input type="text" name="text2" value="This is second value"><br>
(and type="text" is redundant, that is the default attribute value)
<input type="button" value="Swap" onClick="swap()">
.... if this line is changed to
<input type="button" value="Swap" onclick="swap(this);">
because as per DOM Level 0, each DOM object representing a form control has
a `form' property that refers to the DOM object representing the ancestor
`form' element. And `this' in an intrinsic event handler attribute value
refers to the object that handles the event (provided that the default
`scripting' language is an ECMAScript implementation, which is the case
here); that is the `input' element here.
Furthermore, items that require support of client-side scripting should
be generated by it:
<script type="text/javascript">
document.write(
'<input type="button" value="Swap" onclick="swap(this);">');
</form>
</body>
</html>
In the first swap block (getElementById) you are using DOM 1 methods.
These days it would be rather W3C DOM Level 2, although
Document::getElementById() was already defined in W3C DOM Level 1 indeed.
`innerHTML' as used "in the first swap block" does not qualify as a DOM
Level 0 feature, since neither IE nor Netscape before version 4 supported
it.
In the second swap block (document.forms) you are using form-specific
methods from DOM 0.
True, as this also works with NN3/IE3.
You can use DOM 1 instead of DOM 0. Thus you can give ID's to form
elements and retrieve getElementById('ElementID').value.
Where the latter would be rather inefficient, considering that
the same syntax can be used with IDs for ID-aware user agents.
You cannot use DOM 0 instead of DOM 1
Yes, you can.
because DOM 0 simply doesn't have an ability to address any given element
on the page.
True. Specific elements would be required, such as `input' and `textarea'
elements, and it would be best if they were children of a `form' element
then. However, `textarea' elements can be formatted with CSS so that they
look like a `p' or `div' element; only users with UAs that do not support
CSS (properly) would have to see fixed-font display and things like that.
In any case .value property appertains to form elements. DOM elements
like <p> <div> etc. do have innerHTML and nodeValue properties instead.
There is no such thing as a "DOM element". And a DOM element _object_,
representing a _markup_ element, does not need to have any of these
properties. Neither is the term "DOM" restricted to the W3C DOM, nor
does it imply support of proprietary features like `innerHTML'.
PointedEars
but at least it