Collection d'objets dans window

Bonjour !

De quelles fonctions parles-tu ? S'il s'agit des évènements (OnLoad,
OnKeyPress, ...), ils y sont bien.
S'il s'agit de fonctions contenues dans des scripts, alors, c'est
normal, car javascript (comme vbscript, pythonscript, rubyscript, etc.)
ne fait pas partie du DOM (même s'il peut l'utiliser).

@-salutations
--
Michel Claveau

>>De quelles fonctions parles-tu ?

TOUTES :
Toutes les fonctions dites "in-line", comme
abort ()
add ()
addBehavior ()
AddChannel ()
AddDesktopComponent ()
addElement ()
AddFavorite ()
addImport ()
...alouette, de même que les fonctions globales comme :
alert ()
atob ()
back ()
blur ()
btoa ()...
et même les méthodes du DOM :
getElementById ()
getElementsByName ()
getElementsByTagName ()...

Avec Opera, Safari, Mords-zy-la, elles sont toutes listées dans la
collection sur window ou document,
avec IE c'est peau de zébi.

J'ai fini par trouver un truc :
je les liste toutes dans un tableau à partir de la doc chez Microsoft,
et je vais les examiner
en plus des autre objets trouvés dans la collection.
Mais c'est vraiment une entourloupe.

>>Per exemple, exécute le code ci-dessous,

avec Morzilla tu trouves 72 fonctions,
avec Opera : 61,
avec Safari : 67,
et même le très jeune Chrome de chez Glouglou t'en retourne 58.
Mais chez Microstuff, on est muet :-(

<SCRIPT>
var type, txt = "", tot = 0;
for (var o in document)
{
try
{
type = typeof(document[o])
}
catch(e){type=""}
if (type == "function")
{
txt += o +" : " + type + "<BR>";
tot++;
}
}
if (tot) document.write(txt + "total = " + tot)
else document.write("Peau de zébi")
</SCRIPT>

Re !

Les fonctions que tu cites sont des fonctions (du noyau) de Javascript.
AMHA, elles n'on rien à faire avec l'objet window, et ne font pas partie
du DOM (même si certaines servent à utiliser le DOM).

D'ailleurs, dans les navigateurs que tu cites, la plupart n'acceptent
qu'un seul langage de script (Javascript). Alors que IE en accepte une
bonne dizaine, dont plusieurs qui ne sont pas d'origine/gérés pas
Microsoft. Difficile de mettre les centaines (milliers ?) de fonctions
des différents langages.

Donc, pour moi, la réaction de IE est correcte.

@-salutations
--
Michel Claveau

>>et ne font pas partie du DOM (même si certaines servent à utiliser

le DOM).

Ben voyons, document.getElementById() ça ne fait pas partie du document
dans le DOM ?

>>Alors que IE en accepte une bonne dizaine, dont plusieurs qui ne sont
pas d'origine/gérés pas Microsoft. Difficile de mettre les centaines
(milliers ?) de fonctions des différents langages.

Je ne lui en demande pas tant, puisque mon code se trouve dans une
balise <SCRIPT, il s'agit forcément de Javascript par défaut.

>>Donc, pour moi, la réaction de IE est correcte

Mouais...
Pour « for ... in », la doc dit : « Executes one or more statements for
each property of an object, or each element of an array »
donc en toute logique, ça ne devrait pas s'exécuter pour les objets,
seulement pour les propriétés.
Selon moi, cette restriction est assez débile, pourquoi seulement les
propriétés ?
D'ailleurs tous les autres navigateurs ont décidé d'élargir la boucle à
tous les éléments de l'objet,
Microsoft ne l'a fait que pour les objets, mais pas les méthodes,... pas
très logique,
et non conforme aux specs non plus de toute façon.

Re !

document.getElementById() ça ne fait pas partie du document dans le
DOM ?

Non. Le DOM décrit une hiérarchie de propriétés. getElementById() est
une méthode Javascript ; une méthode de l'objet (javascript) document,
qui est mappé sur l'élément document du DOM. Mais, mappé ne veut pas
dire identique.
Pour résoudre un appel, qu'une implémentation d'un couple
javascript+navigateur utilise la délégation, et un autre l'héritage,
montre bien qu'il ne faut pas généraliser à partir d'un cas particulier.

@-salutations

Michel Claveau

>>Mais, mappé ne veut pas dire identique.

Le terme « mappé » que tu utilises ici est sans doute une tentative de «
traduction » de « binded »
pour lerquel le terme de « lié » me semblerait plus approprié, en plus
de présenter l'avantage d'être vraiment une traduction.

De plus ces méthodes pour « relier » le DOM au standard ECMAScript sont
décrites avec le DOM
(voir http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html ),
et non avec ECMAScript.

Mais ok, laissons getElementById(), prenons la méthode
addEventListener() par exemple :
http://www.w3.org/TR/DOM-Level-2-Events/events.html
Et que dire de nextNode(), ...
Elles sont décrites en toutes lettres dans le DOM, et en font partie
intégrante.

D'ailleurs, le DOM se définit lui-même comme un API : « The DOM is
simply an API »,
et définit de plus un API : « An API is an application programming
interface, a set of functions or methods used to access some
functionality. »
alors ne jouons pas sur les mots : le DOM comporte bien des fonctions ou
méthodes...

C'est l'essence de ma question :
Pourquoi l'énnncé for .. in de Microsoft ne liste pas ces fonctions
alors que tous les autres le font ?
Parce que d'après la doc for ... in ne liste que les propriété ?
Admettons, mais toujours d'après les specs ECMA, une méthode n'est rien
d'autre qu'une fonction faisant
partie d'une propriété :
« Properties are containers that hold other objects, primitive values,
or methods.
[...] and a method is a function associated with an object via a property. »

Et ailleurs :
« An object is a member of the type Object. It is an unordered
collection of properties each of which
contains a primitive value, object, or function. A function stored in a
property of an object is called a
method. »
Donc l'énoncé for ... in qui liste les propriétés d'un objet devrait les
lister toutes, que ces propriétés
contiennent une valeur, un autre objet ou une méthode.

Par contre, ECMA spécifie également qu'une propriété peut avoir l'attribut
« DontEnum : The property is not to be enumerated by a for-in enumeration »
Bon, alors là on tient une explication :
chez Microstuff, on aurait mis le DontEnum sur toutes les méthodes du
DOM, c'est ça la différence.
CQFD.

C'est ça la différence, mais c'est non seulement injustifié, c'est idiot :
Qu'est-ce que ça peut bien leur foutre qu'on en ait la liste des ces
méthodes, puisqu'elles existent
et qu'on peut les utiliser ?

Re !

Ne pas oublier que la norme ECMAscript est sortie AVANT les
spécifications du DOM niveau-2 du W3C.
ECMAscript ne pouvant pas s'appuyer sur ces spécifications, et le DOM
niveau 0 (le précédent du W3C) étant complètement dépassé, il ne
restait, à l'époque que le "DOM-IE4", qui était devenu un standard de
fait.

Ce qui est dommage, c'est que le W3C ait pondu un truc incompatible avec
l'existant.

@-salutations
--
Michel Claveau

>>Ne pas oublier que la norme ECMAscript est sortie AVANT les

spécifications du DOM niveau-2 du W3C.
ECMAscript ne pouvant pas s'appuyer sur ces spécifications.

Peut-être, mais je ne vois pas le rapport, et raison de plus :
ECMAscript n'a pas à s'occuper du DOM qui est une implantation dans
ECMAscript,
ou tout autre langage compatible.
Quand le DOM a été défini, il est venu avec tous ses objets, ses
propriétés et ses méthodes
permettant de les gérer, c'est normal et ce n'est pas à ECMAscript de
s'en soucier.