Inconsistent results - why?

Robert Baer

<SWM.HTM listing; does not work; positioning wrong (below main GIF)>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Stripper wells and production</title>
</head>

<SCRIPT LANGUAGE="JavaScript">

</SCRIPT>

<body centered
style="position: centered; height: 431px; width: 760px;" >
<img SRC="Usa52.gif" height="431" width="760" BORDER="0" ALT="USA map">
</BODY>

<div style="position; absolute; top: 55px; left: 257px; "
<img style = "" border="0" alt="X" >
<A onMouseOver="act('one')"
onMouseOut="inact('one')" />
<IMG SRC="om2.gif" NAME="one" BORDER="0" ALT="black X"></A>

</SWM.HTM listing>
*******

<OMX.HTM listing; works & positioning is correct>


<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>HTML onmouse over information and help</title>
</head>

<SCRIPT LANGUAGE="JavaScript">

</SCRIPT>

<body centered
style="position: centered; height: 431px; width: 760px;" >
<img SRC="Usa52.gif" height="431" width="760" BORDER="0" ALT="USA map">
</BODY>

<div style="position: absolute; top: 120px; left: 220px; "
<img style = "" BORDER="0" ALT="X" >
<A onMouseOver="act('one')"
onMouseOut="inact('one')">
<IMG SRC="om2.gif" NAME="one" BORDER="0" ALT="black X"></A>

</OMX.HTM listing>

Apr 9 '06 #1

Subscribe Post Reply

1459

RobG

Robert Baer said on 10/04/2006 9:36 AM AEST:

<SWM.HTM listing; does not work; positioning wrong (below main GIF)>

I guess that is IE's image toolbar. You can turn it off/on in:

Tools->Internet options->Advanced->Multimedia->Enable image toolbar

Is there a question here? If you wondering why your page behaves
strangely, you need to start with valid HTML. You have invalid
attributes and elements outside the body element. What various browsers
do with it will likely be different (or maybe not).

It's the dancing bear syndrome: wonder not how well the bear dances, but
that it dances at all. :-)

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Stripper wells and production</title>
</head>

<SCRIPT LANGUAGE="JavaScript">
The language attribute is deprecated, type is required.

</SCRIPT>

<body centered
There is no 'centered' attribute in HTML 4.
style="position: centered; height: 431px; width: 760px;" >
<img SRC="Usa52.gif" height="431" width="760" BORDER="0" ALT="USA map">
</BODY>
Here your body element is closed, no further HTML elements are allowed,
all that can follow is a closing </HTML> tag.

<div style="position; absolute; top: 55px; left: 257px; "
<img style = "" border="0" alt="X" >
<A onMouseOver="act('one')"
onMouseOut="inact('one')" />
Is this some kind of pseudo XHTML? An A element can't be empty (i.e. it
must have a tag pair), don't use an XHTML tag closure - remove the '/'.

<IMG SRC="om2.gif" NAME="one" BORDER="0" ALT="black X"></A>

Why not put the mouseover on the image itself?

<img src='om2.gif' onmouseover="this.src='om22.gif';"
onmouseout="this.src='om2.gif';" ... >
Mouseovers are frequently done with CSS now as it's more efficient than
pre-loading images, investigate that. If your document is small and
only has two images, pre-loading seems pointless.
[...]
--
Rob
Group FAQ: <URL:http://www.jibbering.com/FAQ>

Apr 10 '06 #2

Robert Baer

RobG wrote:

Robert Baer said on 10/04/2006 9:36 AM AEST:
<SWM.HTM listing; does not work; positioning wrong (below main GIF)>


I guess that is IE's image toolbar. You can turn it off/on in:

Tools->Internet options->Advanced->Multimedia->Enable image toolbar

*** Oh; thanks.

Is there a question here? If you wondering why your page behaves
strangely, you need to start with valid HTML. You have invalid
attributes and elements outside the body element. What various browsers
do with it will likely be different (or maybe not). ** Well, right or wrong, the first one does not work, and the second one
does and ther is no meaningful difference.
That is the question.
However, making fixed is very helpful.
"invalid attributes and elements": i do not have a clue where or what
should be.

It's the dancing bear syndrome: wonder not how well the bear dances, but
that it dances at all. :-)

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Stripper wells and production</title>
</head>

<SCRIPT LANGUAGE="JavaScript">

The language attribute is deprecated, type is required.

** If i leave the "<meta ..." line out, no difference is seen; the two
HTML progs still work differently.
Same difference whether IE or NS is used.


</SCRIPT>

<body centered

There is no 'centered' attribute in HTML 4.

** Maybe, but i have seen it and it works for IE and NS.
But i could use absolute position and hand calculate the proper point.

style="position: centered; height: 431px; width: 760px;" >
<img SRC="Usa52.gif" height="431" width="760" BORDER="0" ALT="USA map">
</BODY>

Here your body element is closed, no further HTML elements are allowed,
all that can follow is a closing </HTML> tag.

<div style="position; absolute; top: 55px; left: 257px; "
<img style = "" border="0" alt="X" >
<A onMouseOver="act('one')"
onMouseOut="inact('one')" />

Is this some kind of pseudo XHTML? An A element can't be empty (i.e. it
must have a tag pair), don't use an XHTML tag closure - remove the '/'.

** Meant to be HTML; will make fixes as you suggest.

<IMG SRC="om2.gif" NAME="one" BORDER="0" ALT="black X"></A>

Why not put the mouseover on the image itself?

<img src='om2.gif' onmouseover="this.src='om22.gif';"
onmouseout="this.src='om2.gif';" ... >
Mouseovers are frequently done with CSS now as it's more efficient than
pre-loading images, investigate that. If your document is small and
only has two images, pre-loading seems pointless.

** CSS? what is that? would rather kiss as much as possible, as i know
so little.
And the app will have a fair number of good-sized images.

[...]

Apr 10 '06 #3

RobG

Robert Baer said on 10/04/2006 11:48 AM AEST:

RobG wrote:
Robert Baer said on 10/04/2006 9:36 AM AEST:
<SWM.HTM listing; does not work; positioning wrong (below main GIF)>

I guess that is IE's image toolbar. You can turn it off/on in:

Tools->Internet options->Advanced->Multimedia->Enable image toolbar

*** Oh; thanks.

Is there a question here? If you wondering why your page behaves
strangely, you need to start with valid HTML. You have invalid
attributes and elements outside the body element. What various
browsers do with it will likely be different (or maybe not).

** Well, right or wrong, the first one does not work, and the second one
does and ther is no meaningful difference.

There is, it is the '/' at the end of the opening A tag in the first
(non-working) version. Your HTML is 'tag soup', that is, the browser
has not been given a DOCTYPE so it must guess how to interpret the
markup. It also encounters a variety of invalid attributes and markup,
so it will use 'quirksmode', which is used whenever the browser is
utterly confused as to what the markup is supposed to do and does its
best to display something.

That is the question.
It was answered - your awful markup was the issue. You can validate
markup here:

<URL:http://validator.w3.org/>
Keep working at it until you get "This document is valid...". Work on
the first couple of errors each time, often they will cause cascading
errors elsewhere that go away when you fix the first ones.

By the time you get a valid document you will have learned a lot about
HTML. There is also a CSS validator when you get around to that.

However, making fixed is very helpful.
"invalid attributes and elements": i do not have a clue where or what
should be.
Use the W3C validator and HTML specification.

It's the dancing bear syndrome: wonder not how well the bear dances,
but that it dances at all. :-)

<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<title>Stripper wells and production</title>
</head>

<SCRIPT LANGUAGE="JavaScript">

The language attribute is deprecated, type is required.

** If i leave the "<meta ..." line out, no difference is seen; the two

The meta tag is irrelevant here, as you've discovered. It's purpose is
largely for validation and fallback if the server fails to set the
content type (the server should always set it).

HTML progs still work differently.
Same difference whether IE or NS is used.
Because your markup is so full of errors that whatever various browsers
may make of it is likely different. And there are different errors in
the two examples you posted.

There are lots of browsers other than IE and Netscape Navigator.

[...]

There is no 'centered' attribute in HTML 4.

** Maybe, but i have seen it and it works for IE and NS.
But i could use absolute position and hand calculate the proper point.

There is no requirement to do that. You don't know how wide the window
is and you don't need to know. Learn more about HTML and CSS, ask such
questions in a relevant new group. But before you do, search their
archives and find other posts that ask the same question.

HTML:
news:comp.infosystems.www.authoring.html

CSS:
comp.infosystems.www.authoring.stylesheets
Some readers there aren't very tolerant of newbies, persist anyway.
[...]

Mouseovers are frequently done with CSS now as it's more efficient
than pre-loading images, investigate that. If your document is small
and only has two images, pre-loading seems pointless.

** CSS? what is that? would rather kiss as much as possible, as i know
so little.

Be careful what you kiss, it may bite :-)

And the app will have a fair number of good-sized images.

Below is an example of what I was referring to, it may not be suitable
for you. Follow-up in a CSS group:

<URL:http://wellstyled.com/css-nopreload-rollovers.html>
Abusing an A element this way is only necessary because IE doesn't
support hover on other elements - but that will change with IE 7 I think.

Poke around alistapart, most of it is pretty good.

<UR:http://www.alistapart.com/>
Here is a brief, valid, document with an image that stays centered
regardless of what size the browser window is (provided there's room of
course):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Center Image</title>
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">

<style type="text/css">
#centerImage {text-align: center;}
</style>

</head>
<body>
<div id="centerImage"><img src="a.gif" alt=""></div>
</body>
</html>

--
Rob
Group FAQ: <URL:http://www.jibbering.com/FAQ>

Apr 10 '06 #4

Lasse Reichstein Nielsen

RobG <rg***@iinet.net.au> writes:

Robert Baer said on 10/04/2006 9:36 AM AEST:

var onef = new Image();
onef.src = "om2.gif";
var oneo = new Image();
oneo.src = "om22.gif"; .... document[imgName].src = eval(imgName + "o.src");

The use of eval here is totally unnecessary:

document[imgName].src = imgName + "o.src";

Sadly not. The eval in this case is the difference between assigning
"oneo.src" and "om22.gif" to the src-attribute of the image with
name "one".

Eval should be avoided, and it can be, but not by simply omitting it
(well, at least not in this case, though too often it really is
completely unnecessary).

Instead the different values that needs to be looked up should be stored
in a structure that allows lookup, and not just as variables with
significant names. E.g.:

var imgs = {one: { o: "omg22.gif", f: "omg2.gif"}};
/* object literal notation equivalent to:
var imgs = new Object();
imgs["one"] = new Object(); // or: imgs.one = new Object();
imgs["one"].f = "img2.gif";
imgs["one"].o = "img22.gif";
*/
.....
document[imgName].src = imgs[imgName].o;

The original code combined crating variables to store URLs of images
and preloading those images. That's not necessary. Instead just add a
preloader that uses the same data to find the URL's to load:

for(var i in imgs) {
var of = imgs[i];
(new Image()).src = of.o;
(new Image()).src = of.f;
}

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Apr 10 '06 #5

Robert Baer

RobG wrote:

Robert Baer said on 10/04/2006 11:48 AM AEST:
RobG wrote:
Robert Baer said on 10/04/2006 9:36 AM AEST:

<SWM.HTM listing; does not work; positioning wrong (below main GIF)>


I guess that is IE's image toolbar. You can turn it off/on in:

Tools->Internet options->Advanced->Multimedia->Enable image toolbar

*** Oh; thanks.

Is there a question here? If you wondering why your page behaves
strangely, you need to start with valid HTML. You have invalid
attributes and elements outside the body element. What various
browsers do with it will likely be different (or maybe not).

** Well, right or wrong, the first one does not work, and the second
one does and ther is no meaningful difference.

There is, it is the '/' at the end of the opening A tag in the first
(non-working) version. Your HTML is 'tag soup', that is, the browser
has not been given a DOCTYPE so it must guess how to interpret the
markup. It also encounters a variety of invalid attributes and markup,
so it will use 'quirksmode', which is used whenever the browser is
utterly confused as to what the markup is supposed to do and does its
best to display something.

That is the question.

It was answered - your awful markup was the issue. You can validate
markup here:

<URL:http://validator.w3.org/>
Keep working at it until you get "This document is valid...". Work on
the first couple of errors each time, often they will cause cascading
errors elsewhere that go away when you fix the first ones.

By the time you get a valid document you will have learned a lot about
HTML. There is also a CSS validator when you get around to that.

However, making fixed is very helpful.
"invalid attributes and elements": i do not have a clue where or
what should be.

Use the W3C validator and HTML specification.

It's the dancing bear syndrome: wonder not how well the bear dances,
but that it dances at all. :-)
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<title>Stripper wells and production</title>
</head>

<SCRIPT LANGUAGE="JavaScript">

The language attribute is deprecated, type is required.

** If i leave the "<meta ..." line out, no difference is seen; the two

The meta tag is irrelevant here, as you've discovered. It's purpose is
largely for validation and fallback if the server fails to set the
content type (the server should always set it).

HTML progs still work differently.
Same difference whether IE or NS is used.

Because your markup is so full of errors that whatever various browsers
may make of it is likely different. And there are different errors in
the two examples you posted.

There are lots of browsers other than IE and Netscape Navigator.

[...]

There is no 'centered' attribute in HTML 4.

** Maybe, but i have seen it and it works for IE and NS.
But i could use absolute position and hand calculate the proper point.

There is no requirement to do that. You don't know how wide the window
is and you don't need to know. Learn more about HTML and CSS, ask such
questions in a relevant new group. But before you do, search their
archives and find other posts that ask the same question.

HTML:
news:comp.infosystems.www.authoring.html

CSS:
comp.infosystems.www.authoring.stylesheets
Some readers there aren't very tolerant of newbies, persist anyway.
[...]
Mouseovers are frequently done with CSS now as it's more efficient
than pre-loading images, investigate that. If your document is small
and only has two images, pre-loading seems pointless.

** CSS? what is that? would rather kiss as much as possible, as i know
so little.

Be careful what you kiss, it may bite :-)

And the app will have a fair number of good-sized images.

Below is an example of what I was referring to, it may not be suitable
for you. Follow-up in a CSS group:

<URL:http://wellstyled.com/css-nopreload-rollovers.html>
Abusing an A element this way is only necessary because IE doesn't
support hover on other elements - but that will change with IE 7 I think.

Poke around alistapart, most of it is pretty good.

<UR:http://www.alistapart.com/>
Here is a brief, valid, document with an image that stays centered
regardless of what size the browser window is (provided there's room of
course):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Center Image</title>
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">

<style type="text/css">
#centerImage {text-align: center;}
</style>

</head>
<body>
<div id="centerImage"><img src="a.gif" alt=""></div>
</body>
</html>

I made the changes you suggested on both files, and the "working" one
still works and is !less! that 12 lines of code!!
---And no JavaScript!
I dare say that the trick(s?) you mentioned cannot be found in any
on-line HTML tutorial.
But the non-working one still would not work, and looked exactly the
same.
I pressed the DOS FC utility to work on them, and there were two
areas it complained about, and visually, those areas were absolutely
identical.
I am guessing that the bad file had embedded control characters or
hex255 (which is just as invisible as a space).
I did not look at the bad file in hex mode; i was so disgusted that i
just tossed it.
So, the next step is to use that nifty utility.
Thanks!

Apr 10 '06 #6

Robert Baer

Lasse Reichstein Nielsen wrote:

RobG <rg***@iinet.net.au> writes:

Robert Baer said on 10/04/2006 9:36 AM AEST:

var onef = new Image();
onef.src = "om2.gif";
var oneo = new Image();
oneo.src = "om22.gif";
...
document[imgName].src = eval(imgName + "o.src");

The use of eval here is totally unnecessary:

document[imgName].src = imgName + "o.src";

Sadly not. The eval in this case is the difference between assigning
"oneo.src" and "om22.gif" to the src-attribute of the image with
name "one".

Eval should be avoided, and it can be, but not by simply omitting it
(well, at least not in this case, though too often it really is
completely unnecessary).

Instead the different values that needs to be looked up should be stored
in a structure that allows lookup, and not just as variables with
significant names. E.g.:

var imgs = {one: { o: "omg22.gif", f: "omg2.gif"}};
/* object literal notation equivalent to:
var imgs = new Object();
imgs["one"] = new Object(); // or: imgs.one = new Object();
imgs["one"].f = "img2.gif";
imgs["one"].o = "img22.gif";
*/
....
document[imgName].src = imgs[imgName].o;

The original code combined crating variables to store URLs of images
and preloading those images. That's not necessary. Instead just add a
preloader that uses the same data to find the URL's to load:

for(var i in imgs) {
var of = imgs[i];
(new Image()).src = of.o;
(new Image()).src = of.f;
}

/L

Yes; i discovered the hard way that "eval" was necessary.
The scheme you gave may be more fundamental or generic or "pure" but
since i know almost nothing about JavaScript (or HTML either), what you
gave is rather confusing to me.
So i hope that you are not too upset if i stick with what i had, as
that scheme was found on the web a few places as sample code and it
looks simple to me (i am maybe too simple-minded).
But i do thank you for giving an alternate.

Apr 10 '06 #7

RobG

Lasse Reichstein Nielsen said on 10/04/2006 4:56 PM AEST:

RobG <rg***@iinet.net.au> writes: [...]
document[imgName].src = eval(imgName + "o.src");

The use of eval here is totally unnecessary:

document[imgName].src = imgName + "o.src";

Sadly not. The eval in this case is the difference between assigning
"oneo.src" and "om22.gif" to the src-attribute of the image with
name "one".

Ooops! I think I suffered from error-correction overload. Using
'o.src' will not work at all, I think the OP meant 'oneo.src' as you've
pointed out. So two errors for the price of one. ;-)

[...]
The original code combined crating variables to store URLs of images
and preloading those images. That's not necessary. Instead just add a
preloader that uses the same data to find the URL's to load:

for(var i in imgs) {
var of = imgs[i];
(new Image()).src = of.o;
(new Image()).src = of.f;
}

Good idea.
--
Rob
Group FAQ: <URL:http://www.jibbering.com/FAQ>

Apr 10 '06 #8

Thomas 'PointedEars' Lahn

Lasse Reichstein Nielsen wrote:

The original code combined crating variables to store URLs of images
and preloading those images. That's not necessary.
IBTD.
Instead just add a preloader that uses the same data to find the URL's
to load:

for(var i in imgs) {
var of = imgs[i];
(new Image()).src = of.o;
(new Image()).src = of.f;
}

I do not think this is a Good Idea. The very point of preloading is to
keep resources in the cache as long as possible. It is unlikely that
created and almost immediately garbage-collected Image objects would
facilitate that in a cross-browser way.
PointedEars

Apr 10 '06 #9

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Lasse Reichstein Nielsen wrote:
Instead just add a preloader that uses the same data to find the URL's
to load: [loop of] (new Image()).src = of.o;
(new Image()).src = of.f;

I do not think this is a Good Idea. The very point of preloading is to
keep resources in the cache as long as possible. It is unlikely that
created and almost immediately garbage-collected Image objects would
facilitate that in a cross-browser way.

I have yet to see a browser where this didn't load the image into the
browser cache. If you want to be certain that the Image object isn't
garbage collected before the image is loaded, just store it somewhere,
i.e.,

var store = [], storeindex = 0;
[loop over data structure:]
(store[i++]=new Image()).src = of.o
(store[i++]=new Image()).src = of.f

It still keeps preloading and lookup data structure separated. Keep
the store array for as long as you want to avoid garbage collection
(but when the image is first in the browsers cache, it'll probably
stay there for a while, independently of whether any page is currently
using it).

One kind of magic thinking that goes around is that you should read
the URL back out from the image objects' src attributes. That does
nothing that just using the URL from anywhere else doesn't do too.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Apr 10 '06 #10

Robert Baer

------- SNIPped -------
Well, it happened again; i started with a valid working "page"
(?proper term here please?) and copied some code from another valid
working "page" and the result was trash; errors all over the place
including in the copied area.
By hand-typing over all of the copied section, including the forcing
of hand-entered <CR> and <LF>, the bad result became good and valid.
There was no visible difference "before" and "after".

So, it would seem that the moral of cut from "this" to paste to
"that" may be the *cause* of errors.
It would be interesting to know if this has been seen with various
text-based editors.

Apr 11 '06 #11

Inconsistent results - why?

Similar topics