A getElementId question

S

Steven

Hi I'm new to js so this prob is a simple question but I haven't been
able to solve it.

I have 2 text fields which let me pick a graphic file and want to
display then in 2 image place holders so I want to call a function
SetImg passing the id of the input file and the image name to to set
the source to the file value fron the input field. Here is what I have
done

<head>

//Javascript function
<script type="text/javascript" language="javascript">
function SetImg(fieldIn, imageToSet) {
var path = document.getElementById(fieldIn).value;
document.getElementById(imageToSet).scr = path;
}
</script>
</head>

<body>
<form name="form1" method="post" action="">
<input name="Browse1" type="file" id="Browse1" value=""
onchange="SetImg(Browse1, img1)"/>
<input name="Browse2" type="file" id="Browse2" value=""
onchange="SetImg(Browse2, img2)"/>
</form>

<img name="img1" src="" width="64" height="64" alt="">
<img name="img2" src="" width="64" height="64" alt="">
</body>


But this doesn't set the image.Can some please tell me what I'm doing
wrong
 
W

web.dev

Steven said:
<script type="text/javascript" language="javascript">

The language attribute is deprecated, use just the type attribute:

function SetImg(fieldIn, imageToSet) {
var path = document.getElementById(fieldIn).value;
document.getElementById(imageToSet).scr = path;

First, you have a misspelling, should be "src" not "scr":

document.getElementById(imageToSet).src = path;
<input name="Browse1" type="file" id="Browse1" value=""
onchange="SetImg(Browse1, img1)"/>

The getElementById method expects a string as an argument, you are not
passing a string to your function, thus the browser should give you an
error message. To fix this, you should send your strings like so (note
the single quotes and the double quotes):

onchange = "SetImg('Browse1', 'img1')"
<img name="img1" src="" width="64" height="64" alt="">
<img name="img2" src="" width="64" height="64" alt="">

In your function, you try to get a reference to your images by using
the getElementById method. However, your image elements do not have an
id to begin with, therefore the method will fail anyway.
But this doesn't set the image.Can some please tell me what I'm doing
wrong

Take the suggestions from above. Another thing you can do instead is,
instead of using getElementById method to get a reference to your
images, you can also use the document.images collection. For example:

document.images["img1"].src = path;
 
S

Steven

web.dev wrote:

The language attribute is deprecated, use just the type attribute:

<script type = "text/javascript">

Corrected

First, you have a misspelling, should be "src" not "scr":

document.getElementById(imageToSet).src = path;
Corrected

onchange = "SetImg('Browse1', 'img1')"
Corrected

In your function, you try to get a reference to your images by using
the getElementById method. However, your image elements do not have an
id to begin with, therefore the method will fail anyway.

Tried the following
<img name="img1" id"img1" src="" width="64" height="64" alt="">
<img name="img2" id"img2" src="" width="64" height="64" alt="">

No success
Take the suggestions from above. Another thing you can do instead is,
instead of using getElementById method to get a reference to your
images, you can also use the document.images collection. For example:

document.images["img1"].src = path;

Tried this also but still no success (also does this mean "img1" is
hard coded and as I have approx 20 images to set thats why I'm trying
to pass the image to the function?)

Also I put
alert(path); after the line
var path = document.getElementById('fieldIn').value;

but it never shows
 
R

Randy Webb

Steven said the following on 8/21/2006 8:16 PM:
Hi I'm new to js so this prob is a simple question but I haven't been
able to solve it.

If the file is run locally, you can solve it. If it is run from a server
then you won't be able to solve it.
I have 2 text fields which let me pick a graphic file and want to
display then in 2 image place holders so I want to call a function
SetImg passing the id of the input file and the image name to to set
the source to the file value fron the input field. Here is what I have
done

<head>

//Javascript function
<script type="text/javascript" language="javascript">
function SetImg(fieldIn, imageToSet) {
var path = document.getElementById(fieldIn).value;

Why use gEBI at all to get the value of a form input? Use the more
widely supported forms collection. But, you don't even need a reference
to the file input if you code it correctly:

<script type="text/javascript">
function showImage(imagePath,imageName){
document.images[imageName].src = imagePath;
}
</script>


<img src="blank.gif" name="myImage">
<input type="file" onchange="showImage(this.value,'myImage')">
<img src="blank.gif" name="myImage2">
<input type="file" onchange="showImage(this.value,'myImage2')">

Only thing to change to keep adding more is the name of the image and
the second parameter to the function call. Why make it harder than it
has to be?
 
S

Steven

Randy said:
Why make it harder than it
has to be?

I'm new to HTML / Javascript but after several years of programing in
other languages I have learned there is always a hard way and an easy
way to do everything and sometimes it's harder to find the easy way.
Many many thanks for your help your suggestion works a like dream and
no doubt I'll soon be asking for a sloution to another problem but as
it's 2.46am here it's time for a system shut down and by that I mean me
and not the computer
Once again thanks for your help

Steven
 
E

Evertjan.

Steven wrote on 22 aug 2006 in comp.lang.javascript:
Tried the following
<img name="img1" id"img1" src="" width="64" height="64" alt="">
<img name="img2" id"img2" src="" width="64" height="64" alt="">

No success

As expected, try:

id = "img1"

Why bother us with:

width="64" height="64" alt=""

They are not essential to your Q, I think.
 
R

Randy Webb

Evertjan. said the following on 8/22/2006 5:46 AM:
Steven wrote on 22 aug 2006 in comp.lang.javascript:


As expected, try:

id = "img1"

Why bother us with:

width="64" height="64" alt=""

They are not essential to your Q, I think.

They are irrelevant to the Q, but, if you don't include all the properly
valid HTML, someone comes along and gets pedantic and wants to complain
"But your HTML is invalid".

Don't get me wrong, valid HTML is important, but when it is irrelevant
to the question then it doesn't matter.
 
R

Richard Cornford

Randy said:
Evertjan. said the following on 8/22/2006 5:46 AM:

They are irrelevant to the Q, but, if you don't include all the properly
valid HTML, someone comes along and gets pedantic and wants to
complain "But your HTML is invalid".
<snip>

As neither the WIDTH nor the HEIGHT attributes of IMG elements are
required in HTML their omission will not impact upon the validity of
the mark-up.

Richard.
 
R

Randy Webb

Richard Cornford said the following on 8/22/2006 9:36 AM:
<snip>

As neither the WIDTH nor the HEIGHT attributes of IMG elements are
required in HTML their omission will not impact upon the validity of
the mark-up.

True, and the omission of semicolons on single statements per line code
will not impact the sanctity of that code but you know where that
argument goes. Providing the width/height of an IMG (whether via HTML or
CSS) is a "Good Practice" even if it has nothing to do with validity.
Too much is made about "Valid HTML".....
 
R

Richard Cornford

Randy said:
Richard Cornford said the following on 8/22/2006 9:36 AM:

True, and the omission of semicolons on single statements per line
code will not impact the sanctity

Would software that verified sanctity be a sanctiator?
of that code but you know where
that argument goes.

I have observed that it goes on, I am unsure where it may be going.
Providing the width/height of an IMG (whether via HTML or
CSS) is a "Good Practice" even if it has nothing to do with validity.

It is certainly the case that if an IMG specifics its dimensions then
the browser knows how much space to reserve on the canvas for the image
and so does not have to re-low the document when the image actually
shows up and announces its actual dimensions.
Too much is made about "Valid HTML".....

HTML validity has a direct impact upon some browser scripting tasks. It
may be the case that many forms of non-valid mark-up will not be
significant and mark-up validity may not influence many scripted tasks.
Any browser script author has two options in avoiding validity related
issues; 1. Understand the significance of mark-up validity for the
generated DOM structure and make informed decisions about how 'valid' a
document needs to be, or; 2. Employ only valid mark-up and so avoid the
issues without needing to understand them.

I always favour people making informed decisions about what they do
rather than blindly following blanket rules.

Richard.
 
E

Eric B. Bednarz

Richard Cornford said:
It is certainly the case that if an IMG specifics its dimensions then
the browser knows how much space to reserve on the canvas for the image
and so does not have to re-low the document when the image actually
shows up and announces its actual dimensions.

To be pedantic, per specification it is not even possible to specify the
intrinsic dimensions of an image, neither with HTML attributes nor with
CSS properties. If user agents started to correctly implement px as a
relative unit, bitmap images with a width/height override would look
funny in some setups.
HTML validity has a direct impact upon some browser scripting tasks.

HTML validity in the sense of parsing a document with a validating SGML
system is pointless for any web browser task, since no browser (I know
of) works that way. Considering the subject line (and to stay a little
bit on topic ;) here's proof how Opera and Mozilla do not, since they
incorrectly return null

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title></title>
<h1 id='foo'>Bar</h1>
<script type='text/javascript'>
alert(document.getElementById('FOO'));
</script>

because they implement the normative prose and not the normative syntax
(the latter being the only relevant aspect in terms of validation) of
HTML. Bummer. One could conclude that in HTML it is good practice to
write attribute value literals for any attribute that isn't CDATA in
uppercase (it is an unlikely but not impossible scenario that an SGML
parser is actually used, e.g. server-side, to preprocess markup at some
point).

HTML validity issues with a factual impact are purely coincidental.
 
M

Michael Winter

Eric said:
[snip]
HTML validity has a direct impact upon some browser scripting
tasks.

HTML validity in the sense of parsing a document with a validating
SGML system is pointless for any web browser task, since no browser
(I know of) works that way.

Of course, but that isn't what Richard meant. Validity is relevant to
scripting because non-trivial scripts often expect the document tree to
be constructed in a particular way. Invoking error correction mechanisms
may mean that the document tree is fixed in some unpredictable way, and
that the final form may vary between user agents (as each may take a
different approach to correction). The reason, in this context, for
writing a valid document is to eliminate this uncertainty.
Considering the subject line (and to stay a little bit on topic ;)
here's proof how Opera and Mozilla do not, since they incorrectly
return null

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title></title>
<h1 id='foo'>Bar</h1>
<script type='text/javascript'>
alert(document.getElementById('FOO'));
</script>

because they implement the normative prose and not the normative
syntax (the latter being the only relevant aspect in terms of
validation) of HTML.

Could you clarify that, please?

From a superficial analysis (and that might be what you accuse browser
vendors of making), the id attribute is marked CS; case-sensitive. If,
then, "foo" should be considered different from "FOO" because they
differ by case, why would returning null be incorrect? Do you mean that
the specification is wrong here, and that the ID type isn't meant to be
treated case-sensitively? Perhaps something else, rooted in SGML?

[snip]

Mike
 
E

Eric B. Bednarz

Michael Winter said:
Eric B. Bednarz wrote:

Of course, but that isn't what Richard meant. Validity is relevant to
scripting because non-trivial scripts often expect the document tree
to be constructed in a particular way. Invoking error correction
mechanisms may mean that the document tree is fixed in some
unpredictable way, and that the final form may vary between user
agents (as each may take a different approach to correction). The
reason, in this context, for writing a valid document is to eliminate
this uncertainty.

I understand the intention perfectly well; but since browsers do not
support SGML at all, SGML validation of HTML does not guarantee that.
It's an entirely academical process with no practical relevance (the
only benefit of syntactically reverse-engineering HTML to SGML has been
to use SGML tools in the *authoring* process; the same is true for
XHTML).

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title/foo/
<ol<li>foo<>bar</ol>

Nothing unpredictable here.
From a superficial analysis (and that might be what you accuse browser
vendors of making), the id attribute is marked CS; case-sensitive.

I would, if anyone, rather accuse the spec.
Do you mean
that the specification is wrong here,

Yes. Either the prose or the syntax. Note under NAMING in

<http://www.w3.org/TR/REC-html40/sgml/sgmldecl.html>

NAMECASE GENERAL YES

which means that uppercase substitution is to be performed for names and
name tokens (and some other stuff which is not relevant here).

The HTML 'id' attribute has the declared value ID and case substitution
applies, compare that with e.g. the 'name' attribute with the declared
value CDATA (not NAME, btw ;-).

<http://validator.w3.org/check?uri=http://bednarz.nl/tmp/namecase.html&ss=1&sp=1>


HTML as an SGML application has always been ridiculous, but that's old news.
 
R

Richard Cornford

Eric said:
I understand the intention perfectly well; but since browsers
do not support SGML at all, SGML validation of HTML does not
guarantee that.

Not true. A document will not validate until the structural
relationships between the elements conforms with that required by the
type of mark-up being used. This structurally validity in the mark-up
translates directly into a structurally certain DOM (no error correction
is needed in the building of the DOM tree). Much else, and so much that
will have no practical impact for scripting, will also need to be true
before a document validates.
It's an entirely academical process with no practical relevance
<snip>

The relationships between elements in the DOM tree can have considerable
practical relevance if you intend navigating the tree to find elements.
It can be demonstrated, for example, that if a FORM is invalidity placed
between TR elements IE, Mozilla/Gecko and Opera will produced three
structurally distinct DOMs (as they error-correct the mark-up), while to
date nobody has been able to present valid mark-up that did not result
in structurally identical[1] DOMs in all of those browsers (and many
others tried).

Richard.

[1] "structurally identical" is only intended to express the
parent/child/sibling relationships between elements. The variation in
representation of non-significant white space Nodes in the DOM is a
known issue that is handled with the testing of the - nodeType -
property of Nodes while navigating the DOM.
 
M

Michael Winter

Eric said:
[snip]
Validity is relevant to scripting because non-trivial scripts often
expect the document tree to be constructed in a particular way.
[snip]

I understand the intention perfectly well; but since browsers do not
support SGML at all, SGML validation of HTML does not guarantee that.

I wouldn't want to suggest otherwise. If one were to use some of the
syntax afforded by SGML in a HTML document, it would validate, but it
would also be heavily error-corrected at the same time. But since when,
in recent times, has anyone stated that the use of unclosed start-tags
or empty end-tags is a sensible thing on the Web? :)

Validity, on its own, doesn't guarantee a predictable document tree,
true; common sense is also essential. But as most authors would be
unaware of the "exotic" features that SGML provides, and those that are
aware are smart enough not to use them, is "validity", as a stated aim,
so unacceptable? Though "markup that doesn't invoke error correction" is
much more accurate, would it be better understood? Even when suggesting
it to any given poster that might wander into these newsgroups?

[snip]
Yes. Either the prose or the syntax.

I would go with the latter: the practical irrelevance of the SGML
declaration is probably why it was overlooked.

I had noticed that before, but had never really paid much attention to it.

Thank you, Eric.

Mike
 
E

Eric B. Bednarz

Richard Cornford said:
Eric B. Bednarz wrote:

Not true. A document will not validate until the structural
relationships between the elements conforms with that required by the
type of mark-up being used.

I am tempted to ask how one knows what 'type' of markup is being used.
:)
This structurally validity in the mark-up
translates directly into a structurally certain DOM

The structural relationships are just hardcoded in browsers, they
couldn't care less about the grammar defined in the document type
declaration.
(no error correction
is needed in the building of the DOM tree).

As far as web browsers are concerned, no SGML parser is used to build
that tree in the first place. Subsequently results differ and a lot of
valid HTML is not even supported by any browser.
[...] while to
date nobody has been able to present valid mark-up that did not result
in structurally identical[1] DOMs in all of those browsers (and many
others tried).

That's so easy that I suspect an ambush. To paraphrase what has already
been there:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title lang='nl'>Verzin een list</title>
<script type='text/javascript'>
window.onload = function()
{
window.alert(document.getElementsByTagName('LI').length);
}
</script>
<ol
<li>foo
<>bar
<>baz
</ol>

Firefox 1.5.0.6: 1
Opera 9.0: 0
Internet Explorer 5.01 - 7b3: 0
Safari 2.0.4: 1

(nsgmls does not care about script and wins with 3)
 
E

Eric B. Bednarz

Michael Winter said:
Validity, on its own, doesn't guarantee a predictable document tree,
true; common sense is also essential. But as most authors would be
unaware of the "exotic" features that SGML provides, and those that
are aware are smart enough not to use them, is "validity", as a stated
aim, so unacceptable?

Regarding the 'exotic features', some of them frequently appear as
simple typos. Validation is not a useful tool if one doesn't understand
it, and I dare say that most people don't.

I wouldn't consider validity so much as unacceptable but rather as
redundant. What's not acceptable IMO is the popular pathos of
considering markup that is not valid as wrong. Sound syntax can be
assured at production time, for starters.

Doctype sniffing as a defacto industry standard has rendered validation
totally irrelevant anyway.
Though "markup that doesn't invoke error
correction" is much more accurate, would it be better understood? Even
when suggesting it to any given poster that might wander into these
newsgroups?

I don't know, really. Is validation understood by people who wander to
a remote service for it? Seriously.


[id attribute 'case sensitive']
I would go with the latter: the practical irrelevance of the SGML
declaration is probably why it was overlooked.

NAMECASE GENERAL YES was quite unavoidable for
backwards-compatibility -- just like SHORTTAG YES, though the latter could
have been unbundled at least for HTML 4.01 -- so the fault is really
wanting 'id' to be case sensitive, IMO.
 
M

Michael Winter

Eric said:
[snip]
Though "markup that doesn't invoke error correction" is much more
accurate, would it be better understood? ...

I don't know, really. Is validation understood by people who wander to
a remote service for it? Seriously.

Too true. :-/
[id attribute 'case sensitive']
I would go with the latter: the practical irrelevance of the SGML
declaration is probably why it was overlooked.

NAMECASE GENERAL YES was quite unavoidable for
backwards-compatibility ...

Despite the discordance between HTML as an application of SGML, and reality?

It's not clear to me at the moment what you are referring to so I'm
happy take your word for it. You're welcome to explain if you want to,
though if it's entirely academic and not worth the effort, I could
understand why you'd rather not.

Mike
 
R

Richard Cornford

Eric said:
I am tempted to ask how one knows what 'type' of markup is
being used.
:)


The structural relationships are just hardcoded in
browsers, they couldn't care less about the grammar
defined in the document type declaration.

But the structures tolerated by being hard coded into the browser come
from somewhere. For a browser that was expecting to be presenting HTML
it would be remiss not to have hard coded the structures that are
defined in the HTML specifications. They may see no need to be
restricted by them but those defined structures, but where additional
structures may be tolerated they will be included on some criteria
internal to the browser's producers. The practical upshot of which will
be that the common sub-set of supported structures will tend to closely
correspond with the structures defined in HTML specifications (though
not necessarily restricted to the current ones).
As far as web browsers are concerned, no SGML parser is
used to build that tree in the first place.

Fine, that doesn't mean that browsers are not consistent in the DOM
structures they create from some forms of invalid mark-up.
Subsequently results differ and a lot
of valid HTML is not even supported by any browser.

True, but it is how the browsers handle invalid mark-up (and more
specifically how they differ in how they handle it) that has the
practical impact on browser scripting.
[...] while to date nobody has been able to present valid
mark-up that did not result in structurally identical[1]
DOMs in all of those browsers (and many others tried).

That's so easy that I suspect an ambush.

Don't, it was a (considerable) overstatement. There is valid mark-up
that browsers will produce structurally inconstant DOMs from.
To paraphrase what has
already been there:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title lang='nl'>Verzin een list</title>
<script type='text/javascript'>
window.onload = function()
{
window.alert(document.getElementsByTagName('LI').length);
}
</script>
<ol
<li>foo
<>bar
<>baz
</ol>

You described validating as an academic exercise, but here we have an
academically valid example of HTML. By the time anyone has learnt enough
to recognise SGML shorthands they will probably already have realised
that they cannot be used in practice because the browsers do not
properly support SGML.

It remains the case that validating the more normal styles of HTML
mark-up can be more than an academic exercise and does have some
practical consequences, at least for people who intend scripting their
documents. It is one of the ways of avoiding having to jump through some
of the hoops when attempting to write cross-browser code (the other
being learning the official structural relationships between elements
yourself and applying them in isolation).

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,480
Members
44,900
Latest member
Nell636132

Latest Threads

Top