FAQ Topic - I get an error when trying to access an element by getElementById but I know it is in the document. What is wrong? (2009-06-26)
FAQ server
FAQ Topic - I get an error when trying to access an
element by getElementById but I know it is in the document.
What is wrong?
-----------------------------------------------------------------------
You cannot access elements that appear in the document after you try
to read them with a DOM method like ` document.getElementById `.
You can either:
A) include your script after the HTML element it refers to, or
B) use the "load" event to trigger your script.
Example A:
<div id="snurgle">here</div>
<script type="text/javascript">
(function(){
var snurgle = document.getElementById('snurgle');
})();
</script>
Example B:
<script type="text/javascript">
window.onload = findElement;
function findElement(){
var snurgle = document.getElementById('snurgle');
};
</script>
</head>
The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/
--
The sendings of these daily posts are proficiently hosted
by http://www.pair.com.
Dr J R Stockton
dk>, Thu, 25 Jun 2009 23:00:02, FAQ server <javas...@dotinternet.be>
posted:
>-----------------------------------------------------------------------
>FAQ Topic - I get an error when trying to access an
>element by getElementById but I know it is in the document.
>What is wrong?
>-----------------------------------------------------------------------
"Why can getElementById fail to find an element?"
>You cannot access elements that appear in the document after you try
>to read them with a DOM method like ` document.getElementById `.
That can be read to give the intended meaning. But its more natural
interpretation, to one accustomed to reading good English, is that the
act of attempting doc.gEBI disables subsequent access. Omit.
>You can either:
^ It may not yet have been created.
>
> A) include your script after the HTML element it refers to, or
that
> B) use the "load" event to trigger your script.
C) have the access triggered manually, so that it naturally occurs after
the element (but not necessarily the whole page) is loaded.
> Example A:
>
><div id="snurgle">here</div>
><script type="text/javascript">
>(function(){
>var snurgle = document.getElementById('snurgle');
>})();
></script>
>
> Example B:
>
><script type="text/javascript">
>window.onload = findElement;
>function findElement(){
>var snurgle = document.getElementById('snurgle');
>};
></script>
></head>
Probably worth including <head>. And AFAICS snurgle cannot be accessed
outside findElement and is not accessed within it, which makes the
example confusing.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Garrett Smith
> In comp.lang.javascript message <4a440178$0$48238$1472...@news.sunsite.
> dk>, Thu, 25 Jun 2009 23:00:02, FAQ server <javas...@dotinternet.be>
> posted:
>> -----------------------------------------------------------------------
>> FAQ Topic - I get an error when trying to access an
>> element by getElementById but I know it is in the document.
>> What is wrong?
>> -----------------------------------------------------------------------
> Subject is too long.
ACK.
Lets move this to a new "Errors" section:
"X is null or undefined"
> "Why can getElementById fail to find an element?"
>
>> You cannot access elements that appear in the document after you try
>> to read them with a DOM method like ` document.getElementById `.
>
>
> That can be read to give the intended meaning. But its more natural
> interpretation, to one accustomed to reading good English, is that the
> act of attempting doc.gEBI disables subsequent access. Omit.
ACK.
The wording is totally confusing. Please, can you write something up for
that?
>
>> You can either:
> ^ It may not yet have been created.
>> A) include your script after the HTML element it refers to, or
> that
>> B) use the "load" event to trigger your script.
>
> C) have the access triggered manually, so that it naturally occurs after
> the element (but not necessarily the whole page) is loaded.
>
>
>> Example A:
>>
>> <div id="snurgle">here</div>
>> <script type="text/javascript">
>> (function(){
>> var snurgle = document.getElementById('snurgle');
>> })();
>> </script>
>>
>> Example B:
>>
>> <script type="text/javascript">
>> window.onload = findElement;
>> function findElement(){
>> var snurgle = document.getElementById('snurgle');
>> };
>> </script>
>> </head>
>
> Probably worth including <head>.
That means "<title>" is necessary (to be valid) and, omitting a doctype
might be taken as a recommendation, so it would then require a doctype,
too, but then we would still have an incomplete document, with no body tag.
The example is best preceded by, and followed with "...".
And AFAICS snurgle cannot be accessed
> outside findElement and is not accessed within it, which makes the
> example confusing.
>
ACK. We need a section on Functions. I'll get to that, but first I need
an overview of what that contains. The section will contain an entry on
closures link to Richard's FAQ "Note" on closures (which will be moved
and edited). Possibly also to kangax' article, though that might need a
bit more review first.
Functions:
Overview: Syntax and grammar:
FunctionDeclaration
FunctionExpression
FunctionStatement
* How can I declare a function?
* What is (function(){ ... })(); ?
* Why is typeof document.images "function" in some browsers?
Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/
Jorge
> (...)
> <script type="text/javascript">
> window.onload = findElement;
> function findElement(){
> var snurgle = document.getElementById('snurgle');};
This last semicolon should not be there. And, there's no need to
pollute the global context, so, why not :
window.onload= function () {
var snurgle = document.getElementById('snurgle');
...
};
?
--
Jorge.
Garrett Smith
> On Jun 26, 1:00 am, "FAQ server" <javascr...@dotinternet.be> wrote:
>> (...)
>> <script type="text/javascript">
>> window.onload = findElement;
>> function findElement(){
>> var snurgle = document.getElementById('snurgle');};
>
^^^
>
> This last semicolon should not be there. And, there's no need to
> pollute the global context, so, why not :
>
> window.onload= function () {
> var snurgle = document.getElementById('snurgle');
> ...
> };
>
That works.
Dr J R Stockton
27 Jun 2009 15:00:06, Garrett Smith <dhtmlk...@gmail.com> posted:
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <4a440178$0$48238$1472...@news.sunsite.
>> dk>, Thu, 25 Jun 2009 23:00:02, FAQ server <javas...@dotinternet.be>
>> posted:
>>> -----------------------------------------------------------------------
>>> FAQ Topic - I get an error when trying to access an
>>> element by getElementById but I know it is in the document.
>>> What is wrong?
>>> -----------------------------------------------------------------------
>> Subject is too long.
>
>ACK.
>
>Lets move this to a new "Errors" section:
"Reported Errors".
>"X is null or undefined"
The FAQ should not, and should not appear to, express error messages
literally, since they generally vary from browser to browser, and
probably more so when non-browsers are included.
>> "Why can getElementById fail to find an element?"
>>
>>> You cannot access elements that appear in the document after you try
>>> to read them with a DOM method like ` document.getElementById `.
>> That can be read to give the intended meaning. But its more
>>natural
>> interpretation, to one accustomed to reading good English, is that the
>> act of attempting doc.gEBI disables subsequent access. Omit.
>
>ACK.
>
>The wording is totally confusing. Please, can you write something up
>for that?
* An element can only be accessed after it has been created
* JavaScript is case-sensitive
* IDs must be unique; the access may find a duplicate ID
* The element reference may be incorrectly expressed
>>> You can either:
>> ^ It may not yet have been created.
>>> A) include your script after the HTML element it refers to, or
>> that
>>> B) use the "load" event to trigger your script.
>> C) have the access triggered manually, so that it naturally occurs
>>after
>> the element (but not necessarily the whole page) is loaded.
I doubt whether it is necessary to include any of those, or any
examples; once the problem is understood, the cure should be easy but
will depend on circumstances.
>>> Example A:
>>>
>>> <div id="snurgle">here</div>
>>> <script type="text/javascript">
>>> (function(){
>>> var snurgle = document.getElementById('snurgle');
>>> })();
>>> </script>
>>>
>>> Example B:
>>>
>>> <script type="text/javascript">
>>> window.onload = findElement;
>>> function findElement(){
>>> var snurgle = document.getElementById('snurgle');
>>> };
>>> </script>
>>> </head>
>> Probably worth including <head>.
>
>That means "<title>" is necessary (to be valid) and, omitting a doctype
>might be taken as a recommendation, so it would then require a doctype,
>too, but then we would still have an incomplete document, with no body
>tag.
>
>The example is best preceded by, and followed with "...".
In such cases, one can put
<script type="text/javascript"> // in the Head
which seems better than putting a closer without its opener.
Danny Wilkerson
1) make sure no other code is redefining your window.onload like auto
inserted ads on free hosts or other included javascript files.
2) move window.onload = findElement; to somewhere after the
findElement function. You might be assigning the event to a function
that does not exists yet. I am not going to go to the trouble of
running your code to check this but either way it makes sense to
assign onload to a function which is already created.
3) check the page for multiple elements with the same id. Id's should
only be used once per page. You most likely will not find the element
if it's named twice.
If neither of the 2 above work, then try window.document.getElementById
(). someone might have tried creating a variable/object "document"
before your code and thereby overriding the inferred window.document.
It's also possible that someone changed the
window.document.getElementById object but it's extremely unlikely.
Garrett Smith
> In comp.lang.javascript message <h264pa$7te$1...@news.motzarella.org>, Sat,
> 27 Jun 2009 15:00:06, Garrett Smith <dhtmlk...@gmail.com> posted:
>> Dr J R Stockton wrote:
>>> In comp.lang.javascript message <4a440178$0$48238$1472...@news.sunsite.
>>> dk>, Thu, 25 Jun 2009 23:00:02, FAQ server <javas...@dotinternet.be>
>>> posted:
>>>> -----------------------------------------------------------------------
>>>> FAQ Topic - I get an error when trying to access an
>>>> element by getElementById but I know it is in the document.
>>>> What is wrong?
>>>> -----------------------------------------------------------------------
>>> Subject is too long.
>> ACK.
>>
>> Lets move this to a new "Errors" section:
>
> "Reported Errors".
>
>> "X is null or undefined"
>
> The FAQ should not, and should not appear to, express error messages
> literally, since they generally vary from browser to browser, and
> probably more so when non-browsers are included.
>
Probably. Understanding what those error messages mean and what causes
them seems like it would be helpful for beginners.
>
>>> "Why can getElementById fail to find an element?"
>>>
>>>> You cannot access elements that appear in the document after you try
>>>> to read them with a DOM method like ` document.getElementById `.
>>> That can be read to give the intended meaning. But its more
>>> natural
>>> interpretation, to one accustomed to reading good English, is that the
>>> act of attempting doc.gEBI disables subsequent access. Omit.
>> ACK.
>>
>> The wording is totally confusing. Please, can you write something up
>> for that?
>
>
> * An element can only be accessed after it has been created
s/created/parsed
But that answer is not complete either, because it does not consider the
possibility of the element being created via createElement.
Instead:
"An element cannot be accessed before it exists in the DOM"
Is simpler and avoids the earlier confusion.
> * JavaScript is case-sensitive
That's a basic syntax feature of the language. Unlikely to be a problem
here.
> * IDs must be unique; the access may find a duplicate ID
> * The element reference may be incorrectly expressed
I don't know what that means.
[snip examples]
>
> I doubt whether it is necessary to include any of those, or any
> examples; once the problem is understood, the cure should be easy but
> will depend on circumstances.
>
Possibly not. I've shortened the examples.
| 8.8 I get an error when trying to access an element by getElementById
| but I know it is in the document. What is wrong?
|
| An element cannot be accessed before it exists in the DOM.
|
| Either: A) include your script after the HTML element it refers to, or
| B) use the "load" event to trigger your script.
|
| Example A:
|
| <div id="snurgle">here</div>
| <script type="text/javascript">
| document.getElementById("snurgle");
| </script>
|
| Example B:
|
| // In the HEAD.
| <script type="text/javascript">
| window.onload = findElement;
|
| function findElement(){
| var snurgle = document.getElementById("snurgle");
| }
| </script>
Garrett
Garrett Smith
> 3 suggestions
>
> 1) make sure no other code is redefining your window.onload like auto
> inserted ads on free hosts or other included javascript files.
>
Hosting mayhem is not going to be covered in the FAQ.
The section on posting covers such problems well-enough:
> 2) move window.onload = findElement; to somewhere after the
> findElement function. You might be assigning the event to a function
> that does not exists yet. I am not going to go to the trouble of
> running your code to check this but either way it makes sense to
> assign onload to a function which is already created.
You obviously did not run the code. It sounds like your understanding of
variable instantiation is incorrect or uncertain.
>
> 3) check the page for multiple elements with the same id. Id's should
> only be used once per page. You most likely will not find the element
> if it's named twice.
That is a different problem and would not result in an error being
thrown. It touches a good point, though: Two elements with the same ID
means the document is not valid.
Invalid HTML is usually correlated with developer confusion and false
expectations. A frequent and easily preventable source of errors is
invalid HTML.
* Create a simplified example of the problem
* Validate your HTML and CSS:
* http://validator.w3.org/
* http://jigsaw.w3.org/css-validator/
That's pretty much covered in "postCode" in the FAQ:
http://jibbering.com/faq/#postCode
Thomas 'PointedEars' Lahn
> Danny Wilkerson wrote:
>> 2) move window.onload = findElement; to somewhere after the
>> findElement function. You might be assigning the event to a function
>> that does not exists yet. I am not going to go to the trouble of
>> running your code to check this but either way it makes sense to
>> assign onload to a function which is already created.
>
> You obviously did not run the code. It sounds like your understanding of
> variable instantiation is incorrect or uncertain.
While you are correct that variable instantiation happens before execution,
Danny brings up an important point: the case should be considered that the
`findElement' were the identifier of an initialized variable, as in
var findElement = function(/* ... */) {
/* ... */
};
That does not look to me as so strange a pattern (for example, no need to
create a function object if certain preconditions for its use are not met),
and then it would matter where `findElement' was initialized with or
assigned the Function object reference.
That said, references to `window.onload' should be removed, and the
standards-compliant approach be suggested instead.
PointedEars
Jorge
> Danny Wilkerson wrote:
> > 3 suggestions
>
> > 1) make sure no other code is redefining your window.onload like auto
> > inserted ads on free hosts or other included javascript files.
>
> Hosting mayhem is not going to be covered in the FAQ.
>
> The section on posting covers such problems well-enough:
>
> > 2) move window.onload = findElement; to somewhere after the
> > findElement function. You might be assigning the event to a function
> > that does not exists yet. I am not going to go to the trouble of
> > running your code to check this but either way it makes sense to
> > assign onload to a function which is already created.
>
> You obviously did not run the code. It sounds like your understanding of
> variable instantiation is incorrect or uncertain.
>
>
>
> > 3) check the page for multiple elements with the same id. Id's should
> > only be used once per page. You most likely will not find the element
> > if it's named twice.
>
> That is a different problem and would not result in an error being
> thrown.
As the element found might not be the one you were looking for, rest
assured that it's going to bite you, for sure.
> It touches a good point, though: Two elements with the same ID
> means the document is not valid.
>
> Invalid HTML is usually correlated with developer confusion and false
> expectations. A frequent and easily preventable source of errors is
> invalid HTML.
>
> * Create a simplified example of the problem
> * Validate your HTML and CSS:
> *http://validator.w3.org/
> *http://jigsaw.w3.org/css-validator/
Validating the source .html file won't catch any problems with
dynamically inserted elements...
--
Jorge.
Garrett Smith
> Garrett Smith wrote:
>> Danny Wilkerson wrote:
>>> 2) move window.onload = findElement; to somewhere after the
>>> findElement function. You might be assigning the event to a function
>>> that does not exists yet. I am not going to go to the trouble of
>>> running your code to check this but either way it makes sense to
>>> assign onload to a function which is already created.
>> You obviously did not run the code. It sounds like your understanding of
>> variable instantiation is incorrect or uncertain.
>
> While you are correct that variable instantiation happens before execution,
More to the point, Danny is wrong for posting something that suggests
otherwise and doing so without testing or reading the relevant
specifications.
> Danny brings up an important point: the case should be considered that the
> `findElement' were the identifier of an initialized variable, as in
>
> var findElement = function(/* ... */) {
> /* ... */
> };
>
That is your code, and it is obviously not what Danny responded to. The
code in the FAQ is simple and works.
>
> That said, references to `window.onload' should be removed, and the
> standards-compliant approach be suggested instead.
NAK
Dr J R Stockton
2000yqk.googlegroups.com>, Sun, 28 Jun 2009 12:15:22, Danny Wilkerson
<dannywi...@gmail.com> posted:
>3 suggestions
>
>1) make sure no other code is redefining your window.onload like auto
>inserted ads on free hosts or other included javascript files.
The FAQ is [substantially, at least] written on the assumption that, for
a given page, the code which is executed by the browser is the code
which was written by the author for that page.
That assumption can be made false in various ways, including
Use of author's include files, which may contain forgotten material;
Use of associates' include files, which may contain unknown material;
Use of library-type files, possibly intermittently updated;
Voluntary inclusion of gadgets from such as Google;
Compulsory insertions made by the server;
Coding 'eval' of an uncontrolled string;
The user copying and changing the page, then blaming the author.
IMHO, the FAQ should say something concise about such possibilities.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3 6.20 ; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Danny brings up an important point: the case should be considered that the
>> `findElement' were the identifier of an initialized variable, as in
>>
>> var findElement = function(/* ... */) {
>> /* ... */
>> };
>
> That is your code, and it is obviously not what Danny responded to.
I know. Hence my saying "brings up an important point" and not "points
out". Learn to read.
> The code in the FAQ is simple and works.
It is too simple at that. To begin with, the declaration of the global
function is unnecessary and potentially harmful (depending on the runtime
environment, function identifier, and used libraries.)
>> That said, references to `window.onload' should be removed, and the
>> standards-compliant approach be suggested instead.
>
> NAK
Why not? Why should the FAQ show an example that only works under certain
conditions when it could provide an example that worked everywhere?
PointedEars
Dr J R Stockton
28 Jun 2009 23:09:27, Garrett Smith <dhtmlk...@gmail.com> posted:
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <h264pa$7te$1...@news.motzarella.org>, Sat,
>> 27 Jun 2009 15:00:06, Garrett Smith <dhtmlk...@gmail.com> posted:
>>> The wording is totally confusing. Please, can you write something up
>>> for that?
>> * An element can only be accessed after it has been created
> s/created/parsed
Elements are not parsed (in this context); source code is parsed.
>But that answer is not complete either, because it does not consider
>the possibility of the element being created via createElement.
It does not need to discriminate, AFAIK, between methods of creation.
If it does so need, that will need to be explained.
>Instead:
> "An element cannot be accessed before it exists in the DOM"
>
>Is simpler and avoids the earlier confusion.
You're again writing for the knowledgeable. The target reader may not
understand what you mean by DOM. To my mind, the DOM is a mixture of a
schema for creating code-dependent structures and the structure provided
in an empty page.
Some elements, such as Math.random, are created before any user code can
execute, and so are always findable.
>> * JavaScript is case-sensitive
>That's a basic syntax feature of the language. Unlikely to be a problem
>here.
On the contrary : it is easy to forget, and so should be here. You are
not writing an International Standard, in which it can be assumed that
the reader of any sentence in it has already read, understood, and
memorised all previous sentences and all of any other required
standards.
>> * IDs must be unique; the access may find a duplicate ID
>> * The element reference may be incorrectly expressed
>
>I don't know what that means.
Example : I had a button which called Fn(this). Initially, function
Fn(B) { ... } only toggled the button's value, and a global Boolean.
Later, I wished in Fn to access another element of the form that
contained the button, and wrote something like form.otherelement.value.
To a human, the intent is clear enough; but script requires a preceding
"B.".
Garrett Smith
> Garrett Smith wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Danny brings up an important point: the case should be considered that the
>>> `findElement' were the identifier of an initialized variable, as in
>>>
>>> var findElement = function(/* ... */) {
>>> /* ... */
>>> };
>> That is your code, and it is obviously not what Danny responded to.
>
> I know. Hence my saying "brings up an important point" and not "points
> out". Learn to read.
>
That is not exactly what you wrote.
| Danny brings up an important point
As I understood Danny's post, he didn't "bring up" the case you are
considering. Instead, he posted what looks like a misunderstanding of
the actual code that he did not attempt to run.
Consider the case of someone who tries to change the example to the way
you wrote it.
Anyone converting function declaration to a function expression would
probably know well enough to hit "reload" and would soon figure out that
the former works and the latter does not. Then again, anyone who did
that might already know it.
>> The code in the FAQ is simple and works.
>
> It is too simple at that. To begin with, the declaration of the global
> function is unnecessary and potentially harmful (depending on the runtime
> environment, function identifier, and used libraries.)
>
From an organizational perspective, the creating a |findElement|
property on the global object is not necessary.
Having an identifier is helpful, for debugging.
Adding a closure is ugly for such a simple task.
(function(){
window.onload = findElement;
function findElement(ev) {
//
}
})();
>>> That said, references to `window.onload' should be removed, and the
>>> standards-compliant approach be suggested instead.
>> NAK
>
> Why not? Why should the FAQ show an example that only works under certain
> conditions when it could provide an example that worked everywhere?
>
<body onload...> does not work everywhere; and will fail to work in my
Firefox, because I am running NoScript.
Where does window.onload not work that <body onload...> does work?
Garrett Smith
> In comp.lang.javascript message <h29lqq$9lc$1...@news.motzarella.org>, Sun,
> 28 Jun 2009 23:09:27, Garrett Smith <dhtmlk...@gmail.com> posted:
>> Dr J R Stockton wrote:
>>> In comp.lang.javascript message <h264pa$7te$1...@news.motzarella.org>, Sat,
>>> 27 Jun 2009 15:00:06, Garrett Smith <dhtmlk...@gmail.com> posted:
>
>>>> The wording is totally confusing. Please, can you write something up
>>>> for that?
>>> * An element can only be accessed after it has been created
>> s/created/parsed
>
> Elements are not parsed (in this context); source code is parsed.
>
>> But that answer is not complete either, because it does not consider
>> the possibility of the element being created via createElement.
>
> It does not need to discriminate, AFAIK, between methods of creation.
> If it does so need, that will need to be explained.
>
>> Instead:
>> "An element cannot be accessed before it exists in the DOM"
>>
>> Is simpler and avoids the earlier confusion.
>
> You're again writing for the knowledgeable. The target reader may not
> understand what you mean by DOM. To my mind, the DOM is a mixture of a
> schema for creating code-dependent structures and the structure provided
> in an empty page.
We have:
| 2.4 What is the document object model?
I think changing that to:
| 2.4 What is the DOM (Document Object Model)?
Would be helpful. The entry needs a total rewrite though. Look:-
| This is the collection of objects provided by each browser.
That's roughly what you said, isn't it? I think that is completely a
wrong answer and misleading to the Math.random example. The Document
Object Model (DOM) is a model for Document objects etc.
The DOM entry should be changed and in a way so that the answer to "An
element cannot be accessed before it exists in the DOM" can be easily
understood.
>
> Some elements, such as Math.random, are created before any user code can
> execute, and so are always findable.
>
I see, so code such as the following:-
document.getElementById( Math.random );
should work just fine.
Kidding, of course ;-)
Given the topic in question is regarding getElementById, Math.random or
other non-Elements seem unlikely to pose a problem for most.
>
>
>>> * JavaScript is case-sensitive
>> That's a basic syntax feature of the language. Unlikely to be a problem
>> here.
>
> On the contrary : it is easy to forget, and so should be here. You are
> not writing an International Standard, in which it can be assumed that
> the reader of any sentence in it has already read, understood, and
> memorised all previous sentences and all of any other required
> standards.
>
I don't think it's a problem. Modern OO languages are case-sensitive.
CSS is case-sensitive. I don't see case-sensitivity issues, except maybe
occasionally getElementByID (instead of getElementById).
>>> * IDs must be unique; the access may find a duplicate ID
>>> * The element reference may be incorrectly expressed
>> I don't know what that means.
>
> Example : I had a button which called Fn(this). Initially, function
> Fn(B) { ... } only toggled the button's value, and a global Boolean.
> Later, I wished in Fn to access another element of the form that
> contained the button, and wrote something like form.otherelement.value.
> To a human, the intent is clear enough; but script requires a preceding
> "B.".
>
I think you're saying that [[scope]], as we discussed earlier, is of
consideration. Event handler attributes' scope and context is out of
context here.
Dr J R Stockton
september.org>, Thu, 2 Jul 2009 00:28:34, Garrett Smith
or | 2.4 What is the Document Object Model (DOM)?
>
>Would be helpful. The entry needs a total rewrite though. Look:-
>
>| This is the collection of objects provided by each browser.
>
>That's roughly what you said, isn't it? I think that is completely a
>wrong answer and misleading to the Math.random example. The Document
>Object Model (DOM) is a model for Document objects etc.
If that is the case, no further explanation should be needed.
>The DOM entry should be changed and in a way so that the answer to "An
>element cannot be accessed before it exists in the DOM" can be easily
>understood.
No; "in the DOM" is unnecessary and seems incompatible with
<http://www.w3.org/TR/DOM-Level-3-Core/introduction.html> (which can be
shortened into an answer for FAQ 2.4).
>> Some elements, such as Math.random, are created before any user code
>>can
>> execute, and so are always findable.
>>
>
>I see, so code such as the following:-
>
>document.getElementById( Math.random );
>
>should work just fine.
It will, no doubt, do whatever it should do. In FF 3.0.11, it returns
an Object which is not a function, and which is === null.
But I wrote "findable", not "findable by getElementById".
>Given the topic in question is regarding getElementById, Math.random or
>other non-Elements seem unlikely to pose a problem for most.
The topic is over-particular; and the reference to Math.random was
intended as illustration, not draft.
FAQ Topic - Why can I not access an element?
That will be found both by those using getElementById and by those
trying to access elements by other means. The entry will be more
useful.
>>>> * JavaScript is case-sensitive
>>> That's a basic syntax feature of the language. Unlikely to be a problem
>>> here.
>> On the contrary : it is easy to forget, and so should be here. You
>>are
>> not writing an International Standard, in which it can be assumed that
>> the reader of any sentence in it has already read, understood, and
>> memorised all previous sentences and all of any other required
>> standards.
>>
>
>I don't think it's a problem. Modern OO languages are case-sensitive.
>CSS is case-sensitive. I don't see case-sensitivity issues, except
>maybe occasionally getElementByID (instead of getElementById).
The degree of problem depends on the skill of the typist, and on the
font and eyeballs used when reading the source. It's easy to make a
mistake and not notice it, either because the upper- and lower- case
versions differ only in size or because one has mis-remembered what case
the ID really uses.
>>>> * IDs must be unique; the access may find a duplicate ID
>>>> * The element reference may be incorrectly expressed
>>> I don't know what that means.
>> Example : I had a button which called Fn(this). Initially, function
>> Fn(B) { ... } only toggled the button's value, and a global Boolean.
>> Later, I wished in Fn to access another element of the form that
>> contained the button, and wrote something like form.otherelement.value.
>> To a human, the intent is clear enough; but script requires a preceding
>> "B.".
>
>I think you're saying that [[scope]], as we discussed earlier, is of
>consideration. Event handler attributes' scope and context is out of
>context here.
No. The Event only caused the attempted access, not its failure.
Consider describing the Highway from Mexico City to Managua, and
forgetting El Salvador.
Really, there are three basic reasons for element access failure :
* No such element
* No such element yet
* One does not access that sort of element like that.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Garrett Smith wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Danny brings up an important point: the case should be considered that the
>>>> `findElement' were the identifier of an initialized variable, as in
>>>>
>>>> var findElement = function(/* ... */) {
>>>> /* ... */
>>>> };
>>> That is your code, and it is obviously not what Danny responded to.
>> I know. Hence my saying "brings up an important point" and not "points
>> out". Learn to read.
>
> That is not exactly what you wrote.
Learn to read!
> | Danny brings up an important point
Yes, that is what I said. "Hence my saying" means "Therefore I said" in
proper English.
> As I understood Danny's post, he didn't "bring up" the case you are
> considering.
He brought up the point of using a function expression (probably without
knowing, but that makes no difference).
> [snipped pointless babble]
>
>>> The code in the FAQ is simple and works.
>> It is too simple at that. To begin with, the declaration of the global
>> function is unnecessary and potentially harmful (depending on the runtime
>> environment, function identifier, and used libraries.)
>
> From an organizational perspective, the creating a |findElement|
> property on the global object is not necessary.
From all perspectives it isn't necessary, and potentially harmful. "Avoid
globals" is one of the first thing one should learn in client-side scripting.
> Having an identifier is helpful, for debugging.
You're reaching. Any decent debugger can set a breakpoint in a function
expression. Some (like Firebug) can even recognize the "debugger" keyword.
> Adding a closure is ugly for such a simple task.
Non sequitur. I have not suggested using a closure at all.
> (function(){
> window.onload = findElement;
>
> function findElement(ev) {
> //
> }
> })();
Completely unnecessary!
window.onload = function(ev) {
// ...
};
That said, `ev' is not of much use here in any case.
>>>> That said, references to `window.onload' should be removed, and the
>>>> standards-compliant approach be suggested instead.
>>> NAK
>> Why not? Why should the FAQ show an example that only works under certain
>> conditions when it could provide an example that worked everywhere?
>
> <body onload...> does not work everywhere;
Where does it not work? It has been working since the earliest Netscape
versions (that is, even when HTML did not specify it yet), and it is
specified in HTML 4.01, XHTML 1.0, and XHTML 1.1 (Intrinsic Events module).
You are not arguing with a user agent that is FUBAR, are you?
> and will fail to work in my Firefox, because I am running NoScript.
And `window.onload' will work with NoScript? If yes, a bug in NoScript to
be fixed ASAP but nothing considerable for the general environment. If no,
a red herring. Irrelevant in any case.
> Where does window.onload not work that <body onload...> does work?
Whereever this proprietary property is not implemented or implemented
differently. And window.onload does not handle the `load' event of the
document, but that of the window.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann