Discussion:
Mysterious "Unknown runtime error" in a script in a HTA file
(too old to reply)
JJ
2018-10-15 13:31:56 UTC
Permalink
I'm seriously puzzled. The problem seems to occur only for TABLE element,
and if the HTML code is opened as an HTML application. i.e. in *.hta file.

<html>
<head></head>
<body>
<table id="tbl"></table>
<script language="vbscript">

result = ""

'populate result...

tbl.innerHTML = result 'source of error. but how can it?

</script>
</body>
</html>
Evertjan.
2018-10-15 14:13:22 UTC
Permalink
Post by JJ
I'm seriously puzzled. The problem seems to occur only for TABLE element,
and if the HTML code is opened as an HTML application. i.e. in *.hta file.
<html>
<head></head>
<body>
<table id="tbl"></table>
<script language="vbscript">
result = ""
'populate result...
tbl.innerHTML = result 'source of error. but how can it?
try:

document.getElementById("tbl").innerHTML = result;
Post by JJ
</script>
</body>
</html>
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Mayayana
2018-10-15 14:28:41 UTC
Permalink
"Evertjan." <***@inter.nl.net> wrote

| try:
|
| document.getElementById("tbl").innerHTML = result;
|

?? That's the same thing. And it raises the same error.

I've never understood why anyone uses getElementById.
It's a superfluous, overcomplicated version of just
referencing the ID itself. There's nothing wrong with
his tbl.innerHTML.
Evertjan.
2018-10-15 21:22:47 UTC
Permalink
Post by Mayayana
|
| document.getElementById("tbl").innerHTML = result;
|
?? That's the same thing. And it raises the same error.
Okay.
Post by Mayayana
I've never understood why anyone uses getElementById.
It's a superfluous, overcomplicated version of just
referencing the ID itself. There's nothing wrong with
his tbl.innerHTML.
No, it is not,
it is just an remnant in IE, I think, as
just the id-name could also mean a variable that is defined in js.

In modern browsers there is:

document.getElementById("tbl")
document.querySelector("#tbl")
document.querySelectorAll("#tbl")[0]
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Mayayana
2018-10-15 23:04:38 UTC
Permalink
"Evertjan." <***@inter.nl.net> wrote

| > I've never understood why anyone uses getElementById.
| > It's a superfluous, overcomplicated version of just
| > referencing the ID itself. There's nothing wrong with
| > his tbl.innerHTML.
|
| No, it is not,
| it is just an remnant in IE, I think, as
| just the id-name could also mean a variable that is defined in js.
|

Who would use a variable with the same name
as an element ID? If you can't keep them straight
then you might try using naming patterns. In other
words, name a DIV "DivMain" or a TABLE "TabMain".
Don't name a TABLE "i" or "s" and don't name a
variable "TableMain" or "ContentDiv". Problem solved. :)

| In modern browsers there is:
|
| document.getElementById("tbl")
| document.querySelector("#tbl")
| document.querySelectorAll("#tbl")[0]
|

There's nothing modern about it. getElementById
works back at least to IE6. Probably IE4. But it's
not necessary. The following works perfectly fine
in "modern" Firefox:

<HTML>
<HEAD>
</HEAD>
<BODY>
<DIV ID="div1">
</DIV>
<SCRIPT>
div1.innerText="okey doke";
</SCRIPT>
</BODY></HTML>

If you don't trust yourself to keep your variables
separate from your IDs and classes then you can
use those methods, but they are superfluous.
Evertjan.
2018-10-16 08:01:35 UTC
Permalink
Post by Mayayana
| > I've never understood why anyone uses getElementById.
| > It's a superfluous, overcomplicated version of just
| > referencing the ID itself. There's nothing wrong with
| > his tbl.innerHTML.
|
| No, it is not,
| it is just an remnant in IE, I think, as
| just the id-name could also mean a variable that is defined in js.
|
Who would use a variable with the same name
as an element ID? If you can't keep them straight
then you might try using naming patterns. In other
words, name a DIV "DivMain" or a TABLE "TabMain".
Don't name a TABLE "i" or "s" and don't name a
variable "TableMain" or "ContentDiv". Problem solved. :)
|
| document.getElementById("tbl")
| document.querySelector("#tbl")
| document.querySelectorAll("#tbl")[0]
|
There's nothing modern about it. getElementById
works back at least to IE6. Probably IE4. But it's
not necessary. The following works perfectly fine
<HTML>
<HEAD>
</HEAD>
<BODY>
<DIV ID="div1">
</DIV>
<SCRIPT>
div1.innerText="okey doke";
</SCRIPT>
</BODY></HTML>
If you don't trust yourself to keep your variables
separate from your IDs and classes then you can
use those methods, but they are superfluous.
If you trust yourself,
there is no need for any scripting-convention.

You could easily do:

const myChangingValue;
let myConstantValue;

However, in interaction with others, there is.

So if you ask about/discuss your code in this NG,
please don't advocate for your selftrusted shortcuts.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
R.Wieser
2018-10-16 08:50:30 UTC
Permalink
Evertjan,
Post by Evertjan.
So if you ask about/discuss your code in this NG,
please don't advocate for your selftrusted shortcuts.
Although I agree with you that you shouldn't use stupid namings, there is
nothing wrong with using a method that is largely unknown to others (and it
seems that that is all it is).

And just as a quick test I tried the same in Firefox, and it had no problem
with it. IOW, its not just an MS fad (read: its a good indication its part
of the JS spec).

Having said that, it definitily would (as always) be a good idea to mention
when you're using something different than the widely-known-and-used
methods. If only to forego any confusion. :-)

Regards,
Rudy Wieser
Mayayana
2018-10-16 13:34:18 UTC
Permalink
"R.Wieser" <***@not.available> wrote

| Although I agree with you that you shouldn't use stupid namings, there is
| nothing wrong with using a method that is largely unknown to others (and
it
| seems that that is all it is).
|

Shouldn't anyone who does coding use some kind
of system to make their code clear, at least to
themselves? To me that's common sense. A great
example of the problem of not doing that is so-called
"minified" code. Something like:

BooExists = FileExists(FilePath)
becomes:
a = b(c)

That's done partly to obfuscate. It's unreadable code.

I usually use data type or element indicators for things:
iTotal = iSomething * 3
TDMain.padding = 0

When I use someone else's code I usually rename
all the variables as part of my process of familiarizing
myself with the code and making it more readable.
It's the same as if I took over someone else's kitchen.
I'd want to put the plastic wrap in a drawer and put the
plates in the cabinet over the sink. Not because that's
the "right" way to do it but because it's my system
and it works for me.

There's actually a name for prepending variables
with identifiers. I think it's called Hungarian notation.
(I have no idea where that came from.) Many people
in VB use such a notation, prepending s for string,
L for long, Col for collection, etc. Many other people
use prepends like m or g to indicate a variable at
module scope or global scope. Some use both:
gsFilePath.

Whatever works to make your code clear for you
makes sense to me. But it should be clear. You should
be able to read your own code and make sense of it.
If you've got a DIV with a name that sounds to you
like a script variable then you're in trouble. In that case
you're probably a person who looks in every kitchen
cabinet every time he needs a plate.

A related issue of interest: There's a notable difference
between VB* and C-ish code like C++ and javascript.
The former is non-case-sensitive, which helps to make
more readable variable names, like iTotal or AReadingList().
It also means that we can use editors that auto-adjust
variable case, which helps a lot to notice mis-spelled
variables. In other words, if I have sBookListFile and
type sbooklitfile my editor won't capitalize the B, L, F,
which makes it easier for me to see that I mis-spelled it.

C-ish programmers often make fun of that, but all it
really means for them is that they have less options.
Javascript variables end up being nearly all lower case
because it's easier not to have any case at all when it's
case sensitive. But itotal and areadinglist are not as
readable.

Which is right? Whichever works for you. To my
mind C-ish code is a monstrosity that should have
been erased before it spread. But now it's considered
normal and lots of people like it. If it works for them
it's none of my business.

| Having said that, it definitily would (as always) be a good idea to
mention
| when you're using something different than the widely-known-and-used
| methods. If only to forego any confusion. :-)
|

You're heading for a fringe position when you start
thinking of it that way. What you may regard as widely
used is neither here nor there. Both methods are
legitimate methods of browser DOM for all browsers.

I've never used getElementById. I've written a lot
of HTA utlities and webpages, never finding a need for
that method. The fact that Evertjan wasn't familiar
with the ability to refer to an ID as an object doesn't
make it quirky. It just means he didn't know about it.

Everyone has their favorites and everyone
has things they don't like. In VB I've never really
got the point of the IIf method, for instance. But
that's my problem. The fact I don't like it doesn't
make it illegitimate or "not widely used". It's an
official, functional part of the VB language. No more
and no less than any other method. The same is
true of IDs as object referrents in browser DOM.
Div1.innerText is in no way less official than
x = getElementById("Div1").innerText. The former
is also a lot more compact and readable.

While I can accept the idea that some people
want to use getElementById because they're not
comfortable keeping their variables clear, I regard
that as inferior coding practice, excessive complexity,
and wasted functionality. That's just my opinion.
Fortunately, we can all use whatever code we like,
as long as it's valid and it works. Anyone who doesn't
like that can go rant on Twitter:
#IWantToBeOffendedToo :)
R.Wieser
2018-10-16 14:04:10 UTC
Permalink
Mayayana,
Post by Mayayana
Shouldn't anyone who does coding use some
kind of system to make their code clear, at least
to themselves?
What makes you think it wasn't clear - crystal clear even - to JJ ?
Post by Mayayana
That's done partly to obfuscate. It's unreadable code.
I'm going to ignore that, as it isn't even remotely related to the "don't
you use a menthod I do not readily recognise" stance EverJan posted. Nor is
it anything JJ was seemingly aiming for (conciously or not) or advocating.
Post by Mayayana
You're heading for a fringe position when you start
thinking of it that way.
I do not understand how the above is connected to my "just make it clear
when you do" advice. Sorry.
Post by Mayayana
While I can accept the idea that some people
want to use getElementById because they're not
comfortable keeping their variables clear, I regard
that as inferior coding practice, excessive complexity,
and wasted functionality.
True.

But what has that to do with JJs decision to use elements ID as an object ?

I get the feeling we are not even talking about the same thing(s) here ...

Regards,
Rudy Wieser
Mayayana
2018-10-16 14:28:01 UTC
Permalink
"R.Wieser" <***@not.available> wrote

| > Shouldn't anyone who does coding use some
| > kind of system to make their code clear, at least
| > to themselves?
|
| What makes you think it wasn't clear - crystal clear even - to JJ ?
|

Because that's what he said -- that he uses
getElementById to avoid possible mixups between
HTML element IDs and script variables. If he doesn't
know which is which then his code is not clear to him.

| > While I can accept the idea that some people
| > want to use getElementById because they're not
| > comfortable keeping their variables clear, I regard
| > that as inferior coding practice, excessive complexity,
| > and wasted functionality.
|
| True.
|
| But what has that to do with JJs decision to use elements ID as an object
?
|
| I get the feeling we are not even talking about the same thing(s) here ...
|

Maybe not. :)
JJ (and I) was using tbl.innerHTML. Everjan thought
that was invalid code and said to use getElementById
instead.

Both methods use element IDs as objects. Both
are valid DOM scripting. But the first does it directly
while the second unnecessarily adds steps and variables.

tbl.innerHTML = "apple"
document.getElementById("tbl").innerHTML = "apple"

The second version has to reference the document,
find a method and parse "tbl" to get the same pointer
that's already provided by tbl. It's all unnecessary.
As Matthew Curland, one of the developers of VB,
used to say: Every period you use indicates a
referenced object and is therefore less efficient.

In this case, tbl is already an object. It doesn't
need a new reference created, which is what
getElementById does. I don't know whether
getElementById is actually slower. It probably
doesn't matter on the level of human perception.
But it is a clunky, unnecessarily complex way of
doing the job.
R.Wieser
2018-10-16 16:53:53 UTC
Permalink
Mayayana
Post by Mayayana
Because that's what he said -- that he uses
getElementById to avoid possible mixups between
HTML element IDs and script variables.
He did ? Where ? Not in the two post of his in this thread.
Post by Mayayana
JJ (and I) was using tbl.innerHTML.
I saw that JJ posted that as part of his sample code.
Post by Mayayana
Everjan thought that was invalid code and said to use
getElementById instead.
Nope, thats not what he said at all. He expressed he didn't like the
method, because of (his?) possible confusion with variable names.
Post by Mayayana
The second version has to reference the document,
find a method and parse "tbl" to get the same pointer
that's already provided by tbl. It's all unnecessary.
That was not what I was talking (to EvertJan) about. It was soly about the
why of his rejection of the method.
Post by Mayayana
In this case, tbl is already an object. It doesn't
need a new reference created, which is what
getElementById does.
As long as you are *absolutily sure* that that ID - and the same-named
object - exists than I do not see any problem with using it directly. In
all other cases using getElementById and testing for a null is simply a bit
of defensive programming (allowing the script to continue running, instead
of stopping its execution)
Post by Mayayana
But it is a clunky, unnecessarily complex way of
doing the job.
As you might read from the above, I do not agree with you. I think that
both methods have their usage - depending on how sure you are of the
contents of the html page.

In other words, I would not advice the direct object method for webpages
[1], but could imagine that it is prefectly at its place in HTA files

[1] Just think of FireFox plugins (a)like GreaseMonkey, which can cause
elements to disappear without a notice.

Regards,
Rudy Wieser
Mayayana
2018-10-16 18:25:05 UTC
Permalink
"R.Wieser" <***@not.available> wrote


| In other words, I would not advice the direct object method for webpages
| [1], but could imagine that it is prefectly at its place in HTA files
|
| [1] Just think of FireFox plugins (a)like GreaseMonkey, which can cause
| elements to disappear without a notice.
|

You really are nuts. :)

You won't use something like Div1.display = "none"
because you're worried someone might be hacking
your webpage and raise an error? So you check every
object before you use it? What about error trapping?
I thought it was silly that Evertjian was worried he
might mix up his variables and his IDs. Now you're
saying you can't directly reference the object because
it will raise an error. You're not making sense.

Say your page has one of these:

Div1.display = "none"

document.getElementById("Div1").display = "none"

How is the second option more stable than the first
if Div1 doesn't exist? Neither one shows any kind of script
error when I run them in a page that has no Div1.

If you have no idea what your script is doing, or
if you want to anticipate the endless possibilities of
a GreaseMonkey-using visitor, then haven't you error
trapped? You can even check to see whether Div1
is an object if you like, though I've never heard of
anyone doing it:

<html>
<head></head>
<body>
<table id="tbl"><TR><TD></TD></TR></table>
<script language="vbscript">
msgbox IsObject(tbl) 'returns true
tbl.innerHTML = result
</script>
</body>
</html>

My apologies for using VBScript in a VBScript group,
but I didn't know the js corollary of IsObject. :)
R.Wieser
2018-10-16 19:23:28 UTC
Permalink
Mayayana,
Post by Mayayana
You won't use something like Div1.display = "none"
because you're worried someone might be hacking
your webpage and raise an error?
Kiddo, currently I am too tired to humor you. Go look up what "defensive
programming" means. You might learn a thing or two. Goodbye.

Regards,
Rudy Wieser
Mayayana
2018-10-16 20:04:31 UTC
Permalink
"R.Wieser" <***@not.available> wrote

| Kiddo, currently I am too tired to humor you. Go look up what "defensive
| programming" means.

I think I know what that means by listening to you
and Evertjian. You've spent a day coming up with
any and every reason why it's not a good idea to
use something like Div1.display = "none". If you
don't want to use it that's up to you, but you don't
need to come up with reasons why other people
shouldn't use it.

I've kept answering you because this is a worthwhile
point. There's no reason for anyone to be "scared"
into using getElementById through hokey reasoning about
errors, confusing code, the nutty idea that it's old
fashioned, outdated, or IE-only. None of that
is true.
It's not a problem to use getElementById. I know
everyone tends to like to stay with what they know.
But getElementById is unnecessary, excessively
complicated, and superfluous. There's no reason for
other people to develop a poor programming habit.
Evertjan.
2018-10-16 20:38:00 UTC
Permalink
Post by Mayayana
Div1.display = "none"
THAT at least will not work, try:

Div1.style.display = "none"
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Mayayana
2018-10-16 22:19:19 UTC
Permalink
"Evertjan." <***@inter.nl.net> wrote

| > Div1.display = "none"
|
| THAT at least will not work, try:
|
| Div1.style.display = "none"
|

Ah. Good one. I often forget that.
R.Wieser
2018-10-17 07:30:07 UTC
Permalink
Mayayana,
You've spent a day coming up with any and every
reason why it's not a good idea to use something
like Div1.display = "none".
Which is specifically *NOT* what I've been saying.

And by the way: From how many third parties can a webpage download
additional content ? And yes, that includes JS too. Don't you think that
a little bit caution would be a good idea ? Well, I do.

I have absolutily no idea why you thought you needed to try to ridicule me,
but it shows, at least to me, you have been flapping your mouth without
actually enagaging your brains.

You see, in the grandparent I rather specifically mentioned GreaseMonky, but
for some reason you failed to see that its scripts would exactly be "hacking
your webpage" (instead of some fantasized third party).

And as I'm writing GreaseMonkey scripts often with routines that get shared
between several of them it pays to write them with error catching build in.
And yes, that includes checking if the element(s) you're targetting actually
(still) exists. Precisely because than a disappearing element (because of
layout changes you do not have any control over) wont stop the rest of the
(GreaseMonky) script to perform its actions.

I don't know who you actually are angy towards, but I certainly do not wish
to be used as punching bag. Comprende ? Behave yourself.

Regards,
Rudy Wieser
Mayayana
2018-10-17 13:42:25 UTC
Permalink
"R.Wieser" <***@not.available> wrote

| And by the way: From how many third parties can a webpage download
| additional content ? And yes, that includes JS too. Don't you think
that
| a little bit caution would be a good idea ? Well, I do.
|

I don't think it should be allowed at all. The Internet
was designed to separate domains. Third party cookies
subvert that. Scripts and fonts coming from Google
subvert that. Iframes were considered bad manners
and insecure, nearly phased out, before the likes of
Google and Facebok started using them to load ads and
thereby set 3rd-party cookies. I think the solution is
to block browsers from loading external content.

But I don't know what that issue has to do with the
topic of tbl.innerHtml vs getElementById.

If you have anything relevant point to make about
tbl.innerHTML, or want to clarify some misunderstanding
on my part, then that's fine. But I repeatedly asked you
to show some reason why getElementById is somehow
safer and you didn't. You instead came up with unrelated,
tangential topics. If you're going to confuse things then
I'll try to clarify them.

| And as I'm writing GreaseMonkey scripts often with routines that get
shared
| between several of them it pays to write them with error catching build
in.
| And yes, that includes checking if the element(s) you're targetting
actually
| (still) exists.

Suit yourself. But didn't you bring up GreaseMonkey
to make a point? The original question: Why is
getElementById superior? In this case you seem to
be saying that you think it's "safer", less error-prone.
I don't get it. How is it better in checking whether an
object exists?

If IsObject(tbl) then.....

x = getElementById("tbl")
If IsObject(x) then....

Am I missing something?
R.Wieser
2018-10-17 19:59:31 UTC
Permalink
Mayayana,
But didn't you bring up GreaseMonkey to make a point?
Not quite, but if you want to think of it that way than be my guest. Do you
have a problem with it ? If so which one and why.
The original question: Why is getElementById superior?
No, it wasn't. At least not in this thread. And definitily not a
question which I would want to waste my time on.
Am I missing something?
You are trying to yank my chain there, are you. Even if you would have
added brackets around the "if" condition and ment to use a curly bracket
instead of that "then" and IsObject would exist under JS, referencing a
non-existing something (in the first line) will *still* throw an error.

You know, I'm starting to doubt that you are actually Mayayana ...

Regards,
Rudy Wieser

JJ
2018-10-17 19:10:41 UTC
Permalink
Post by Evertjan.
document.getElementById("tbl").innerHTML = result;
Sorry for the late reply.

I'm not looking for a solution to my problem. I was asking how the error
occurs (which is already answered by Mayayana).

And I specifically don't use `getElementById()` because I don't have any
variable named `tbl`. FYI, I'm not an early adopter of newer standards, so
I'll use old specification or even dodgy technique as long as it works.
Especially if the code is for private use.
Evertjan.
2018-10-17 19:36:10 UTC
Permalink
Post by JJ
Post by Evertjan.
document.getElementById("tbl").innerHTML = result;
Sorry for the late reply.
I'm not looking for a solution to my problem. I was asking how the error
occurs (which is already answered by Mayayana).
And I specifically don't use `getElementById()` because I don't have any
variable named `tbl`.
If you don't specify, it might be a name or an id or a js-variable.

That's why

document.querySelector and document.querySelectorAll

are so nice imho, as they specidy by tagName, . and #.
Post by JJ
FYI, I'm not an early adopter of newer standards, so
I'll use old specification or even dodgy technique as long as it works.
How many years does a method to be a method before you no longer consider it
for eary adoption??
Post by JJ
Especially if the code is for private use.
No, it is no longer only for private use, if you show it in this NG.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Mayayana
2018-10-15 14:14:23 UTC
Permalink
"JJ" <***@vfemail.net> wrote

| I'm seriously puzzled. The problem seems to occur only for TABLE element,
| and if the HTML code is opened as an HTML application. i.e. in *.hta file.
|

I don't see where that might come into play. Why
would anyone want to empty a table of content rather
than hide it?
Nevertheless, I tried first showing the existing value
in a msgbox and got <TBODY></TBODY>.

My guess is that from IE's point of view you're
trying to overwrite a read-only property. I've
never used the TBODY tag in my life, but I know
that IE will corrupt HTML with it's own version of
code. It seems to read in an HTML file and put the
content into its own object model. When you then
pull it back out you actually get a different file. And
I'd guess that file's content will also depend on the
IE version. (For instance, in some cases B will be
replaced with STRONG, but I'm not sure if all versions
do that.)

If you comment out the error line and add the line
below, you can see what IE thinks the code is, at least
up to the point where the script runs. You've added it
inline so it won't register HTML that follows:


MsgBox document.body.innerhtml

(assumes quirks mode, as you've written it)
R.Wieser
2018-10-15 15:33:52 UTC
Permalink
JJ,
Post by JJ
tbl.innerHTML = result 'source of error. but how can it?
Maybe because a table doesn't actually have a writable(!) "innerHTML" ?
There are supposed to be other elements in there, like TR and TD

The last time I wrote, in a HTML document, text inside a table element but
outside elements like TD the text got moved to above the table itself.

Also do remind yourself that innerHTML is regarded as pure text, even if
you've put tag-like words in it (stuff surrounded by angle brackets) - it
doesn't get parsed for elements.

Regards,
Rudy Wieser
Mayayana
2018-10-15 15:57:27 UTC
Permalink
"R.Wieser" <***@not.available> wrote

| Maybe because a table doesn't actually have a writable(!) "innerHTML" ?

You're right. It doesn't exist at all for older versions of
IE. In the Win7 MSDN it says this about innerHTML:

The property is read/write for all objects except the following, for which
it is read-only: COL, COLGROUP, FRAMESET, HEAD, HTML, STYLE, TABLE, TBODY,
TFOOT, THEAD, TITLE, TR.

It would have been nice, though, if they'd bothered
to note that in the error rather than just saying
"unspecified".
JJ
2018-10-16 11:07:45 UTC
Permalink
Post by Mayayana
| Maybe because a table doesn't actually have a writable(!) "innerHTML" ?
You're right. It doesn't exist at all for older versions of
The property is read/write for all objects except the following, for which
it is read-only: COL, COLGROUP, FRAMESET, HEAD, HTML, STYLE, TABLE, TBODY,
TFOOT, THEAD, TITLE, TR.
It would have been nice, though, if they'd bothered
to note that in the error rather than just saying
"unspecified".
Oh, it's MSIE specific. Cause when I work with HTML (as a document rather
than HTA), the `innerHTML` of a TABLE element never caused an exception when
assigned to anything.

But the MSDN article doesn't mention that the `innerHTML` readOnly-ness
applies only for IE 9 and older versions. The `innerHTML` property has
become writable in v10 and Edge, and accoring to the DOM specification.
Whether quirks mode is used or not.

I had to convert the script code to JavaScript so that I could test it as
HTML document in MSIE v11 under different modes. e.g. Edge, v10, v9, etc.

And if I check the UserAgent string from a HTA, it says MSIE7 - meaning that
it runs using v7 mode. So, that concludes this problem.

Thank you all.
Mayayana
2018-10-16 13:58:56 UTC
Permalink
"JJ" <***@vfemail.net> wrote

| But the MSDN article doesn't mention that the `innerHTML` readOnly-ness
| applies only for IE 9 and older versions. The `innerHTML` property has
| become writable in v10 and Edge, and accoring to the DOM specification.

I guess that makes sense. What you say holds true
if I open it in Firefox. And if I then ask it to tell me
what the innerHTML is I get a blank message box.

If I remember correctly, it was decided the DOM
standard should support all properties for all elements.
That raises an interesting issue: If you can create
invalid HTML by doing something like setting the
innerHTML of a table to "", is there any point at
which the page will malfunction without error? It
looks like it will. If I do this:

tbl.innerHTML = "apple";
alert(document.body.outerHTML);

...then I get a message showing:

<table id="tbl">apple</table>

In normal usage the text would have been part
of a TD element. But the TR and TD will be stripped.
Even if your sample uses...

<TABLE ID="tbl"><TR><TD></TD></TR></TABLE>

... the TR and TD are gone after the script runs.
So any CSS applied to the TR or TD will also be
gone.

Can of worms is all I can say. :)
I think I prefer the old IE approach of telling
you it's faulty. I don't see any advantage in
allowing one to create faulty and unstable HTML
just to standardize the DOM.
Dave "Crash" Dummy
2018-10-16 16:28:07 UTC
Permalink
Post by JJ
I'm seriously puzzled. The problem seems to occur only for TABLE element,
and if the HTML code is opened as an HTML application. i.e. in *.hta file.
<html>
<head></head>
<body>
<table id="tbl"></table>
<script language="vbscript">
result = ""
'populate result...
tbl.innerHTML = result 'source of error. but how can it?
</script>
</body>
</html>
Try this:

tbl.insertRow
tbl.rows(0).insertCell
tbl.rows(0).cells(0).innerHTML = result

And "result" can include HTML elements, like "<B>Bold</B>"
--
Crash

Today is the first day of the rest of your life,
and there's not a damned thing you can do about it.
Continue reading on narkive:
Loading...