Bonjour Cédric,
La raison de l'utilisation de balises autofermantes provient de
l'ascendant XML du XHTML, et ce pour une raison simple: en XML, auxune
balise ne peut être considéré automatiquement fermée, elles doivent
toutes être explicitement fermées; ceci provient du fait que le XML est
une spécification plus simple que le HTML 'réel': en HTML, une balise P
ouverte peut être considérée fermée dès que:
- une nouvelle balise P s'ouvre,
- certains éléments de type bloc s'ouvrent (comme les listes, mais pas
les images),
- son parent se ferme,
- la balise est explicitement fermée.
Pour couper court à toutes ces règles qui peuvent être différemment
interprétées selon les navigateurs (par exemple, selon le mode
d'affichage, une TABLE fermera ou pas une balise P), XHTML utilise la
règle que toute balise doit être explicitement fermée - même les balises
autocontenues.
Dans ce dernier cas, le XML utilise la notation <balise /> pour indiquer
la fermeture de balise; par chance, la barre / est ignorée par les
navigateurs HTML si elle est précédée d'un espace, ce qui autorise la
création de pages XHTML lisibles par un navigateur HTML "classique"
(note: en SGML, dont le HTML est un sous-ensemble, la barre oblique
signifie la fermeture de la balise; le caractère > suivant serait donc
une aberration. Seulement, aucun navigateur actuel n'implémente la
syntaxe SGML complète).
Finalement: le XHTML ne vise pas à simplifier le code en en réduisant la
quantité. Il vise à simplifier la syntaxe, via ces tenants:
- séparation du contenu et de la forme: les paramètres de style ne sont
plus valides;
- séparation du contenu et des actions: les paramètres d'action ne sont
plus valides;
déjà, rien que là, ça diminue la quantité de paramètres par objet à
connaître (tout est réuni dans 'script' et 'style' si tu veux rester en
mode atomique, mais bien entendu getElementById ou #id en ECMAscript et
CSS ont la même efficacité)
- simplification de la construction du DOM: comme les balises doivent
être correctement imbriquées et fermées, le navigateur n'a plus besoin
de faire d'efforts pour reconstruire un arbre correct;
- simplification de la navigation du DOM: le DOM étant désormais
contruit formellement, sans erreur et avec (normalement) aucune
variation quel que soit le navigateur, tout code manipulant/modifiant le
DOM ou les propriétés d'éléments du DOM fonctionnera avec moins de
problèmes;
avec ces points-là, la conclusion précédente devient beaucoup plus
intéressante: tu peux vraiement sortir de ta page tout ce qui est
présentation et script, pour les réunir dans des fichiers externes.
Perso, depuis que je me force à utiliser le XHTML 1.0 Strict, je passe
beaucoup moins de temps à déboguer mon code, et celui-ci est beaucoup
mieux rangé.
Mitch
Cédric Schmitz a écrit :
Bonjour.
Voilà plusieurs semaines que je me documente sur le XHTML.
J'ai quelques interrogations, et je voulais savoir si vous aviez des
pistes sur une liste de diffusion tout aussi sympathique que celle d'OOo.
J'ai par exemple du mal à répondre à cette critique: passer de <br> en
HTML à <br /> en XHTML allourdi le code...
Filiation XML ou pas.
Les discours technique de filiation XML et sémantique sont encore peu
considérés tout comme utiliser un standard ouvert...
Merci d'avance.
Cédric.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
