developer said:
Ok here is an example.....
function getSpan(){
var elem = document.getElementById("201294_38604_1");
^^^^^^^^^^^^^^
The string values of ID attributes are required to conform with HTML's
specification for ID tokens:-
<quote cite="HTML 4.01 - Basic HTML data types: 6.2 SGML basic types">
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".").
alert("the value of elem is " + elem);
alert("the value inside elem is " + elem.innerHTML);
elem.innerHTML = "" ; // does not work
}
<span id="201287_38614_1"><tr><td colspan="4" align="left" >4 Test
conditional</td></tr><tr><td width="3%"> </td><td align="left"
colspan="3"><textarea name="01287_DDL_DT" rows="3" cols="55" >test
key</textarea></td></tr></span>
In HTML there are only three contexts in which a TR element may appear,
they are as direct children of TBODY, THEAD and TFOOT:-
<quote cite="HTML 4.01 transitional DTD">
<!ELEMENT THEAD - O (TR)+ -- table header -->
<!ELEMENT TFOOT - O (TR)+ -- table footer -->
<!ELEMENT TBODY O O (TR)+ -- table body -->
</quote>
(In XHTML they may also be direct children of TABLE.)
You have specified several TRs as direct children of a SPAN element,
this is an error in HTML.
The SPAN element is an %inline element, and like all %inline elements
may only contain other %inline elements:-
<quote cite="HTML 4.01 transitional DTD">
<!ENTITY % special
"A | IMG | APPLET | OBJECT | FONT | BASEFONT |
BR | SCRIPT | MAP | Q | SUB | SUP | SPAN |
BDO | IFRAME">
....
<!-- %inline; covers inline or "text-level" elements -->
<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; |
%formctrl;">
....
<!ELEMENT SPAN - - (%inline
* -- generic language/style container -->
</quote>
None of TBODY, THEAD, TFOOT or TR are %inline elements, so placing TRs
and/or implied TBODYs inside a SPAN is also and error in HTML.
The first alert does confirm elem is an object, so IE does
not seem to mind that the id starts with a number since it
found it. But the second alert says the (span) object's
contents are blank. So the clear in the third line does not
work.
When you abandon HTML in favour of tag soup mark-up you become subject
to the vagaries of browser error-correction. While a formal
specification may be able to state what would be correct, and how
correct mark-up should be treated, allowing constant handling by all
conforming UAs, it cannot dictate the handling of incorrect mark-up
(except for blanket requirements that incorrect mark-up not be
presented, which is not a realistic stance on an Internet where
technical competence is an unusual novelty). Each browser must implement
its own error-correction strategy, and they cannot even follow each
other as their error-correction code will tend to be private/secret.
So presented with tag-soup a browser will error-correct it as best it
can, and because the visual outcome of error-corrected tag soup in other
browsers is obvious they do all tend to produce the same (or broadly
similar) visual results. Which encourages HTML authors to regard
formally valid HTML mark-up as an irrelevance, as it won't make any
difference to their work. Unfortunately it is under the hood, where the
scripting is done, that differences in the outcome of browser
error-correcting become evident. The browser is trying to create a DOM,
which is supposed to be a tree with well specified parent-child
relationships.
A browser encountering an element in mark-up in a context where it
cannot be placed in the DOM will have to do something with it, and they
tend to vary considerably in what they do. They might move the element
back in the DOM to the last position in which it would have been valid,
or, if possible (as with block level elements) move it towards the root
to the last position where it could validly contain its specified
contest (and now much else besides), it may even ignore the inconstancy
and leave the element where it is. (and in some cases browsers will
ignore the 'tree' concept and allow parts of the DOM to have multiple
parents). I.E. The results of tag soup for the javascript author are a
mess of inconsistently structured DOMs with unexpected parent-child
relationships, and a huge additional headache when trying to write
anything for more than one browser.
In your case it looks like the browser you are using has moved the SPAN
in the DOM to a position where it is structurally valid (in some sense)
and the TRs are no longer its children, so that cannot be found within
its innerHTML (indeed it now appears to have no children).
What would be the best way to clear the contents because
that is what I need to do.
Wrap the table section in a TBODY of its own and use DOM methods to
remove the TBODY from the containing TABLE.
If Span is for Inline elements, what could I use
instead?
TBODY (but not with innerHTML)
Still not valid as a direct child of a TABLE.
Tbody? Should I use the tr and td directly to
build the table?
Probably, the W3C DOM Node manipulation methods are widely supported on
modern dynamic visual browsers and reliable in the context of table
construction/manipulation.
Thanks for any suggestions.
If you are going to script a document always start from the position of
formally valid HTML mark-up. Browsers are fragile, they should not be
kicked.
Richard.
