Bonsoir.
Etant empêtré sur de la maintenance de Thunderbird, je tenais à vous
remercier avant de partir en weekend.
C'est extrêmement intéressant et l'explication qui frôle la limite de
mes connaissances me permet de mieux comprendre les imbrications.
Toujours aussi passionnant !
Bon weekend.
Cédric.
Mitch a écrit :
Cédric Schmitz a écrit :
Merci pour ces explications.
J'ai tenté ce genre d'explication, mais ça ne parle pas à grand monde
en fait.
Rappelle-leur un truc: en IT, ne pas suivre la tendance c'est se
retrouver au chômage. La veille technologique, ça les concerne aussi:
la période glaciaire de IE 6 est terminée.
Les concepteurs de sites que je côtoie utilisent des outils sans
savoir comment ça tourne (comme trop souvent).
Eh ben... Dis-leur de vite apprendre, parce que avec la folie des
standards qui se développe chez les éditeurs de navigateurs, même sous
IE 8 leurs styles et scripts vont bomber! Et qu'ils ne comptent pas
trop sur le mode de compatibilité, ça n'a jamais bien marché ce truc!
Ce qui fait que parler de DOM et de XML a un adepte de Dreamweaver
n'a aucun sens... pour lui.
Un utilisateur de Dreamweaver n'est pas un auteur de site web. C'est
un graffiteur d'Internet (je parle du type avec une bombe de peinture
qui écrit FUK sur les bords d'autoroute, pas la catégorie artiste
urbain avec un aérographe). J'imagine que dès qu'il faut faire un
contenu un peu plus interactif, ils sortent du Flash (sans penser à
ceux qui ne veulent/ne peuvent pas utiliser Flash, comme les
non-voyants, les utilisateurs de navigateurs mobiles, les gens en
entreprise avec un pare-feu très strict, ou les utilisateurs de
systèmes et navigateurs 64-bit)?
Dois-je en conclure qu'un navigateur se connecte systématiquement au
DOM (ou l'implémente de lui même) lorsqu'il lit l'entête du fichier ?
Il ne se 'connecte' pas: le DOM (Document Object Model, ou Modèle
d'Objets du Document) est un 'arbre virtuel' que le navigateur
construit pour modéliser le contenu du document. Cette arbre part de
la fenêtre active et descend sur le document, lequel se divise en head
et body (oui, comme les balises du même nom) lesquels se divisent en
branches qui peuvent porter plusieurs noeuds (balises). L'intérêt
d'utiliser le DOM, c'est que tu le construis avec du (X)HTML, mais
comme c'est un standard, tu peux le naviguer avec un autre langage,
comme le CSS et le JavaScript. L'en-tête de fichier (type MIME et
DOCTYPE conjugués) détermine le mode de compatibilité du DOM: grosso
modo, en mode quirks, tu as le DOM 0 de IE 4. En mode Strict (IE 6+,
Mozilla 1+, Opera 6+), tu as le DOM 1 (qui sert de base aux DOM 2 et
3, lesquels sont des super ensembles du DOM 1).
Comme sur un arbre réel, chaque noeud déclenche la sortie d'une
nouvelle branche, laquelle peut comporter plusieurs noeuds etc.
Quelle importance? Imagine le cas suivant, souvent généré par une
ancienne version de Dreamweaver ou par Frontpage:
<p>Une phrase <b>avec une partie grasse, <i>une partie grasse et en
italiques,</b> et une partie italique seulement</i> avant fin de la
phrase</p>
Si tu regardes de plus près, tu remarqueras que cette partie comporte
une erreur: la balise B est ouverte avant la balise I, et est ensuite
fermée dans la balise I. Problème:
- puisque B est ouverte avant I: B contient I;
- puisque B et I sont définies en HTML pour être fermées
explicitement, la fermeture de I après la fermeture de B signifie: I
contient B;
- une branche ne peut se regreffer sur elle-même, sinon elle devient
son propre parent (ce qui rend les deux conditions ci-dessus
mutuellement exclusives).
Si tu scriptes (et si je me rappelle bien, comme je code en XHTML
exclusivement ce type d'erreur ne m'arrive plus):
- sous IE, naviguer entre B et I en utilisant parentNode (ou
object.parent) te fait entrer dans une boucle sans fin, qui peut
planter le navigateur et même la machine;
- sous Firefox, la non-fermeture de I entraîne que B est gardé ouvert
jusqu'à la fermeture de la branche principale (ici, P);
- sous Opera, la fermeture de B entraîne la fermeture de I, et la
création d'une balise anonyme I après B.
Résultat: un plantage (IE), un style non appliqué (Firefox) ou un
noeud supplémentaire (Opera). Va créer un script qui parcoure le DOM
tout seul après ça!
D'un autre côté, en faisant du XHTML, un navigateur moderne (Opera ou
Firefox, en utilisant le type MIME du XHTML, soit
application/xhtml+xml) balancera une erreur 'sèche' sur l'erreur, ce
qui entraîne la correction obligatoire de l'erreur, qui crée un DOM
correct, qui rend la rédaction d'un script fonctionnant de la même
manière sur tous les navigateurs beaucoup plus simple (grosso modo, tu
crées sous Firefox, ça marche sous Opera et Safari, et avec un minimum
de corrections stylistiques et syntaxiques sous IE 6 et 7).
L'autre intérêt c'est la possibilité d'utiliser la flexibilité du XML,
et donc d'ajouter, directement dans le document racine, d'autres
éléments XML non HTML comme le MathML (sympa pour écrire une formule
mathématique proprement) ou le SVG (graphiquement surpuissant).
L'avantage de procéder comme ceci plutôt que d'intégrer des objets,
images etc. c'est que comme c'est du XML, les noeuds de ces 'espaces
de nom' (namespaces) peuvent être intégrés au DOM directement, et
navigués comme le reste du document.
Traduction: en XHTML, tu peux tracer 25 ellipses en SVG, et rendre
chacune indépendamment cliquable (ou faire suivre la souris, ou faire
pivoter sur elle-même etc.), sans Flash, dans un seul fichier texte
(donc une seule requête HTTP) qui peut lui-même être intégré dans un
autre document XML et repris dans une application.
A côté, faire mumuse avec les API de Flash, c'est moins flexible, plus
lourd et moins portable.
Bon, certains vont te répondre que DHTML de Microsoft avec les objets
MSO et VML permettent déjà de faire ça, et que les gens n'utilisent
que IE. Tu peux leur répondre que:
- ça ne marche pas sous Firefox ni sous Mac, et donc 30% des
internautes français sont virés de leur site (ça fait quand même
beaucoup),
- ça demande une révision avec chaque ancienne version d'IE (IE5, 6 et
7 doivent être testés séparément et sont des versions supportées par
Microsoft donc utilisées),
- ça ne fonctionnera plus avec IE 8.
Note: sous IE, ça ne marche pas encore très bien, parce que IE (même
8) est incapable de lire du XHTML comme étant du XML (oui, ils sont
pathétiquement à la traîne chez MS). Par contre, même sous IE,
utiliser une syntaxe 'comme XHTML' propre diminue radicalement le
temps d'affichage (bénéfice immédiat) et le nombre d'erreurs de
construction du DOM (bénéfice visible en note 2).
Note 2: tu peux, à l'aide de scripts, 'couper' des branches ou en
'faire pousser' de nouvelles, ou simplement modifier les valeurs de
branches qui sont déjà là. Si ton arbre est bien défini (note 1), tu
peux réécrire intégralement la page avec du script (selon les actions
utilisateur, par exemple). Si, en plus, tu utilises JavaScript pour
lire des données externes à la page et agir selon ces données pour
modifier la page déjà chargées, tu te retrouves avec une page dont le
contenu change selon les interventions client et serveur avec le temps
sans nécessité de la recharger; tu peux donc, littéralement,
programmer une application temps réel dans le navigateur, et d'autant
plus facilement que la page suit un DOM de type XML et que les données
chargées sont de type XML aussi. Et là, on attaque le gros morceau: on
modifie de manière décalée (entre 2 chargements de page depuis le
serveur) la structure XML d'une page à l'aide de JavaScript: c'est
donc du JavaScript et du XML asynchrones, en anglais Asynchronous
Javascript And XML - communément raccourci en AJAX (ce qui me mène à
la note 3).
Note 3: si ils te disent que puisque les applis Google fonctionnent
sous IE, c'est que IE est super pour AJAX, tu peux leur dire de
regarder de plus près:
- le code AJAX pour IE doit être développé séparément de celui pour
tous les autres navigateurs, car IE est pathétique côté support du DOM
et de ses méthodes; l'utilisation de hacks spécifiques pour
circonvenir les erreurs de conception, les erreurs d'exécution et
l'incapacité de IE de supporter des modifications 'live' du document
rendent sa manipulation plus délicate que les autres navigateurs;
- pour suivre le point précédent, le code développé pour IE est plus
long et plus lourd que pour les autres navigateurs, car il faut
également réfréner les fuites mémoire inhérentes au gestionnaire de
mémoire d'IE, lequel est incapable de gérer la mémoire sans une canne,
un bavoir et 3 infirmières pour lui tenir la main;
- si ils te sortent que IE a 'inventé' AJAX avec XmlHttpRequest,
rappelle-leur que c'est Firefox qui a intégré cet objet directement
dans le navigateur le premier, sans aucune difficulté, et que sa
version est plus flexible que la version IE d'origine, ce qui a
entraîné l'explosion d'AJAX;
- pour bien enfoncer le clou, dis-leur de sortir un chronomètre et de
déterminer la différence en temps de chargement d'une appli AJAX sous
Firefox et/ou Opera, comparé avec IE - et rappelle-leur que passé 8
secondes, un internaute a tendance à aller voir ailleurs (chez moi,
Gmail charge en 3 secondes sous Firefox, en 12 secondes sous IE 6
quand il ne plante pas en route);
- enfin, rappelle-leur qu'avec Gmail, Google Apps, Yahoo! Mail,
Hotmail et tous ces sites comme YouTube, eBay, Amazon etc. qui
utilisent tous AJAX (et non plus du Flash clignotant à tous les
étages, ou seulement pour les pubs), leurs commanditaires vont finir
par leur demander des choses qu'ils ne pourront plus faire car ils s'y
seront pris trop tard pour les comprendre (et ce, surtout au niveau de
la rapidité de l'application développée: AJAX étant basé sur un
langage de script, la moindre erreur d'optimisation peut entraîner des
pertes de performance abominables - et donc, inacceptables).
Mais c'est un sujet passionnant !!!
Je veux oui!
Cédric.
Mitch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
