Josselin wrote:
On 2006-05-29 09:40:15 +0200, "VK" <sc**********@yahoo.com> said: IE does automatical tree correction in such case (so <body> container
is still used instead). I don't know if it's a proper reading of specs
or a rendering bug - but should be mentioned.
That's the point..
this script was written for IE only.... and I am testing it with Firefox
I changed :
this.image = new Image();
document.appendChild(this.image);
to :
this.image = new Image();
Nobody has commented on the *approach* so far, so I feel obliged to do it.
A proprietary Image object is different from a standardized HTMLImageElement
object. At least it should be. Relying on equality because it is so in
one or two (or a handful) UAs is error-prone.
this.image.width="0";
this.image.height="0";
Neither property expects a string value.
document.body.appendChild(this.image);
This will not only fail, it will break in some UAs.
<URL:http://pointedears.de/scripts/test/whatami#inference>
and it works...
By coincidence.
I got it invisible, but there...
Your implementation of an "image cache" is nonsense. Caching, if it happens
at all, happens already when the value of the `src' property of an Image
object is changed -- as the article you are referring to states already.
As for `onreadystatechange', that event handler is IE-only (except of XHR).
Cross-browser (since Image objects were introduced in JavaScript 1.1, and
all vendors have copied DOM Level 0 so far) is `onload', and unsurprisingly
it does not require a bogus image added to the document.
See also <URL:http://pointedears.de/hoverMe>.
Note that without client-side script support nothing is cached; there are
prefetching techniques with HTML, though, that can be exploited here.
F'up2 cljs
PointedEars
--
What one man can invent another can discover.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Adventure of the Dancing Men"