«

VK wrote:

> Thomas 'PointedEars' Lahn wrote:
>> wrote:
>> >> Is it all?
>> > A
>> > APPLET
>> > AREA
>> > BASE
>> > INPUT type=image
>> > META (sometimes contains URLs...)
>> > everything that takes "longdesc".
>
> INPUT type=image
> At least one hit to the piggybank.

And I missed "APPLET". Adding OBJECT.

> But I'm affraid by usability same as Image -

Full ACK

> see higher in this thread.

"Higher"?

> Here is the property dump of SCRIPT object in Firefox 1.5 I'm wondering
> if any of properties could be checked for presence / availability
> during the script loading to emulate onreadystatechange functionality.
> Not to say I cannot do it myself - but someone may have an immediate
> answer or comment.

It is not possible to determine if a script was loaded by inspecting the
properties of a HTMLScriptElement object. What would be possible is to
determine if a certain variable was declared and holding a value different
from `undefined'. That said, "loading scripts" after the document was
loaded is still unreliable.


PointedEars

Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:


>That said, "loading scripts" after the document was loaded is still unreliable.

No more unreliable than trying to load them when the page is loading.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Randy Webb wrote:

> Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>> That said, "loading scripts" after the document was loaded is still
>> unreliable.
>
> No more unreliable than trying to load them when the page is loading.

Nonsense.


PointedEars

Randy Webb wrote:
> Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>
>
> >That said, "loading scripts" after the document was loaded is still unreliable.
>
> No more unreliable than trying to load them when the page is loading.
>

if (scriptObject.readyState == 'complete')
in IE works just fine and reliable - at least seems so, I did not check
it under all circumstances.

It is a shame that others did not implement anything so convenient and
obvious - except for XMLHttpRequest - they must be thinking that after
such glorious achievement they can take a rest for another year or two.


The previous script properties dump was irrelevant (sorry for that) as
it was for inline script. Below the properties dump for external script
for Firefox 1.5 Win98 SE

So much of useless crap they put in it - and nothing really useful.
That's still would be the best to check the state w/o any in-script
helpers, to keep the data out of implementation.

nodeName = SCRIPT
nodeValue = null
nodeType = 1
parentNode = [object HTMLHeadElement]
childNodes = [object NodeList]
firstChild = null
lastChild = null
previousSibling = [object Text]
nextSibling = null
attributes = [object NamedNodeMap]
ownerDocument = [object HTMLDocument]
insertBefore = function insertBefore() {
[native code]
}
replaceChild = function replaceChild() {
[native code]
}
removeChild = function removeChild() {
[native code]
}
appendChild = function appendChild() {
[native code]
}
hasChildNodes = function hasChildNodes() {
[native code]
}
cloneNode = function cloneNode() {
[native code]
}
normalize = function normalize() {
[native code]
}
isSupported = function isSupported() {
[native code]
}
namespaceURI = null
prefix = null
localName = SCRIPT
hasAttributes = function hasAttributes() {
[native code]
}
tagName = SCRIPT
getAttribute = function getAttribute() {
[native code]
}
setAttribute = function setAttribute() {
[native code]
}
removeAttribute = function removeAttribute() {
[native code]
}
getAttributeNode = function getAttributeNode() {
[native code]
}
setAttributeNode = function setAttributeNode() {
[native code]
}
removeAttributeNode = function removeAttributeNode() {
[native code]
}
getElementsByTagName = function getElementsByTagName() {
[native code]
}
getAttributeNS = function getAttributeNS() {
[native code]
}
setAttributeNS = function setAttributeNS() {
[native code]
}
removeAttributeNS = function removeAttributeNS() {
[native code]
}
getAttributeNodeNS = function getAttributeNodeNS() {
[native code]
}
setAttributeNodeNS = function setAttributeNodeNS() {
[native code]
}
getElementsByTagNameNS = function getElementsByTagNameNS() {
[native code]
}
hasAttribute = function hasAttribute() {
[native code]
}
hasAttributeNS = function hasAttributeNS() {
[native code]
}
id =
title =
lang =
dir =
className =
text =
htmlFor =
event =
charset =
defer = false
src = file:///D:/JS/external.js
type = text/javascript
ELEMENT_NODE = 1
ATTRIBUTE_NODE = 2
TEXT_NODE = 3
CDATA_SECTION_NODE = 4
ENTITY_REFERENCE_NODE = 5
ENTITY_NODE = 6
PROCESSING_INSTRUCTION_NODE = 7
COMMENT_NODE = 8
DOCUMENT_NODE = 9
DOCUMENT_TYPE_NODE = 10
DOCUMENT_FRAGMENT_NODE = 11
NOTATION_NODE = 12
offsetTop = 0
offsetLeft = 0
offsetWidth = 0
offsetHeight = 0
offsetParent = null
innerHTML =
scrollTop = 0
scrollLeft = 0
scrollHeight = 0
scrollWidth = 0
clientHeight = 0
clientWidth = 0
tabIndex = -1
blur = function blur() {
[native code]
}
focus = function focus() {
[native code]
}
style = [object CSSStyleDeclaration]
removeEventListener = function removeEventListener() {
[native code]
}
dispatchEvent = function dispatchEvent() {
[native code]
}
baseURI = file:///D:/JS/TMP1135285699.htm
compareDocumentPosition = function compareDocumentPosition() {
[native code]
}
textContent =
isSameNode = function isSameNode() {
[native code]
}
lookupPrefix = function lookupPrefix() {
[native code]
}
isDefaultNamespace = function isDefaultNamespace() {
[native code]
}
lookupNamespaceURI = function lookupNamespaceURI() {
[native code]
}
isEqualNode = function isEqualNode() {
[native code]
}
getFeature = function getFeature() {
[native code]
}
setUserData = function setUserData() {
[native code]
}
getUserData = function getUserData() {
[native code]
}
DOCUMENT_POSITION_DISCONNECTED = 1
DOCUMENT_POSITION_PRECEDING = 2
DOCUMENT_POSITION_FOLLOWING = 4
DOCUMENT_POSITION_CONTAINS = 8
DOCUMENT_POSITION_CONTAINED_BY = 16
DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC = 32

VK wrote:

> Randy Webb wrote:
>> Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>> > That said, "loading scripts" after the document was loaded is still
>> > unreliable.
>> No more unreliable than trying to load them when the page is loading.
>
> if (scriptObject.readyState == 'complete')
> in IE works just fine and reliable - at least seems so, I did not check
> it under all circumstances.

"Reliable" means it works under _all_ circumstances.

> It is a shame that others did not implement anything so convenient and
> obvious [...]

It is not. They just did not expect that people would try to add `script'
elements in order to load and execute scripts after the document was
loaded. ISTM that it does what it does if it does is merely coincidental,
which is why I am strongly recommending against it.

> The previous script properties dump was irrelevant (sorry for that) as
> it was for inline script. Below the properties dump for external script
> for Firefox 1.5 Win98 SE

It is still irrelevant, stop posting such.


PointedEars

Thomas 'PointedHead' Lahn babbled the following incoherently in
comp.lang.javascript:
> Randy Webb wrote:
>>Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>>>That said, "loading scripts" after the document was loaded is still
>>>unreliable.
>>No more unreliable than trying to load them when the page is loading.
> Nonsense.

I can load .js files dynamically just as reliably as I can load them
statically. Either something is reliable and always works, or, it is
unreliable and doesn't always work. Since external files can never
"always be loaded" then it is unreliable. As is loading them
dynamically. That makes them both unreliable. And unreliable is not
relative. If two things are both unreliable, then they are equally
unreliable.

In the future, it might help you if you would endeavor to understand the
language I am using and the meanings of what I post. It would keep you
from replying as much and keep me from correcting you so much.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Thomas 'PointedEars' Lahn said the following on 12/22/2005 7:20 PM:
> VK wrote:
>>Randy Webb wrote:
>>>Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
>>>>That said, "loading scripts" after the document was loaded is still
>>>>unreliable.
>>>No more unreliable than trying to load them when the page is loading.
>>if (scriptObject.readyState == 'complete')
>>in IE works just fine and reliable - at least seems so, I did not check
>>it under all circumstances.
> "Reliable" means it works under _all_ circumstances.

And loading .js files is _never_ reliable as there will be circumstances
where it won't load. Remember that, it will prove beneficial to you.

>>It is a shame that others did not implement anything so convenient and
>>obvious [...]
> It is not.

What is not? The convenience of readyState? The obviousness of
readyState? Or that it is a shame? It is a shame indeed that no other
browser gives you a method to tell when a script has loaded.

> They just did not expect that people would try to add `script'
> elements in order to load and execute scripts after the document was
> loaded.

And how do you know what the programmers at MS "expected"? Or is that
more of your holier-than-thou-but-worthless thought process?

> ISTM that it does what it does if it does is merely coincidental,
> which is why I am strongly recommending against it.

Recommending against what? Using readyState or loading .js files
dynamically?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Randy Webb napisal(a):
> As is loading them
> dynamically. That makes them both unreliable. And unreliable is not
> relative. If two things are both unreliable, then they are equally
> unreliable.
>

Internet is unreliable.

Thomas 'PointedEars' Lahn wrote:
> "Reliable" means it works under _all_ circumstances.

Then let's define exactly what "reliable" would mean in this case and
what circumstances should be expected.

(pseudo-code)

Variant 1 - hardcoded kill
[remove existing node] scriptObject
[add new node] scriptObject
[assign] scriptObject.src = newURL

Does removing the node devalidate the current script context of
scriptObject - so it would be free for garbage collection?

What moment such devalidation occurs (if it does) - immediately upon
removing the node? somewhere later?

What moment we can try to access new scriptObject? When the
text/javascript input stream is closed? When interpreter finished some
tuneup job somether after? Or even while text/javascript input stream
is still open?

If newURL doesn't exists or is not reachable: do we have any formal
signs to see the trouble?

How scriptObject.defer = true affects (if it does) on anything above?

(defer is now supported by IE, FF, Opera - not sure about Safari 2.x.
Safari 1.x and Konqueror in any shall perform form are out of the loop
as hopeless cases)


Variant 2 - soft replacement
scriptObject.src = newURL1
...
scriptObject.src = newURL2
...
etc.

Same questions but getting even more tricky.
I doubt very much that there are any written standards for it - but I
can be crossly mistaken.
If I'm write though then the answers have to be found from experiments.
The most stable (wide spread) behavior should be announced as the
standard then and submitted to W3C as standard proposal - so future
browser developers could refer to it. Will it be accepted by W3C or not
is not important - there are plenty of standards which are sitting as
proposals for years.

Erratic behaviors in particular browsers/versions should be found and
fixed by JavaScript means.

Does it have any sense?

Randy Webb wrote:
> ...
> And unreliable is not
> relative. If two things are both unreliable, then they are equally
> unreliable.

A has a 10% chance of failing, and B has a 90% chance of failing.
A and B are equally unreliable??