Quelle est actuellement la façon recommandée de servir des documents en
xhtml 1.0 (strict) pour être compatible (si possible) à la fois avec les
standards et les navigateurs existants ? Les deux questions que je me pose
sont :
- type mime : html ou xml ?
- prologue xml : présent ou pas ?
Je me souviens que la dernière fois que j'avais lu des trucs à ce sujet, les
avis semblaient partagés quand à la première question, et que la réponse à
la deuxième était négative : si n'importe quoi (y compris donc un prologue
xml) précédait la déclaration de type de document, IE 6 basculait en mode
quirks et c'était la catastrophe pour le placement en CSS.
Je ne sais pas si la situation a changé (IE6 est-il encore assez présent
pour devoir être pris en compte ?)
Merci d'avance pour vos avis et conseils sur la question.
In article <48aef92e$0$15529$, Patrick Mevzek wrote:
Au moins avec le XHTML servi proprement, si on fait n'importe quoi on a un beau message d'erreur du validateur XML dans le navigateur, et donc on ne *coupe pas* à faire attention et propre !
sauf avec iCab, lui qui se vantait d'avoir un smiley qui indique en permanence si la page est valide ou pas, .... et patati et patata, etc, à propos du code html valide, ce #### il n'en fait pas une (de plus) pour le xhtml (il fait exactement pareil)
du coup on peut consulter les pages web non valides tranquillement .... :-(
In article <48aef92e$0$15529$426a74cc@news.free.fr>,
Patrick Mevzek <pm-N200808@nospam.dotandco.com> wrote:
Au moins avec le XHTML servi proprement, si on fait n'importe quoi on a un
beau message d'erreur du validateur XML dans le navigateur, et donc on ne
*coupe pas* à faire attention et propre !
sauf avec iCab,
lui qui se vantait d'avoir un smiley qui indique en permanence si la
page est valide ou pas, .... et patati et patata, etc, à propos du code
html valide,
ce #### il n'en fait pas une (de plus) pour le xhtml (il fait exactement
pareil)
du coup on peut consulter les pages web non valides tranquillement ....
:-(
In article <48aef92e$0$15529$, Patrick Mevzek wrote:
Au moins avec le XHTML servi proprement, si on fait n'importe quoi on a un beau message d'erreur du validateur XML dans le navigateur, et donc on ne *coupe pas* à faire attention et propre !
sauf avec iCab, lui qui se vantait d'avoir un smiley qui indique en permanence si la page est valide ou pas, .... et patati et patata, etc, à propos du code html valide, ce #### il n'en fait pas une (de plus) pour le xhtml (il fait exactement pareil)
du coup on peut consulter les pages web non valides tranquillement .... :-(
In article <48aedca8$0$31426$, Patrick Mevzek wrote:
Le Fri, 22 Aug 2008 17:19:28 +0200, mpg a écrit: > Quelle est actuellement la façon recommandée de servir des documents en > xhtml 1.0 (strict) pour être compatible (si possible) à la fois avec les > standards et les navigateurs existants ?
> - prologue xml : présent ou pas ?
Standard : oui Navigateurs : comme vous le dites avec IE mieux vaut pas.
Mais là c'est plus embêtant : difficile de changer cela au moment de l'échange.
comme le dit CrazyCat, si on est en UTF-8 on peut tout à fait supprimer la déclaration XML (pas le prologue) sans céder un octet aux Standards :-)
In article <48aedca8$0$31426$426a74cc@news.free.fr>,
Patrick Mevzek <pm-N200808@nospam.dotandco.com> wrote:
Le Fri, 22 Aug 2008 17:19:28 +0200, mpg a écrit:
> Quelle est actuellement la façon recommandée de servir des documents en
> xhtml 1.0 (strict) pour être compatible (si possible) à la fois avec les
> standards et les navigateurs existants ?
> - prologue xml : présent ou pas ?
Standard : oui
Navigateurs : comme vous le dites avec IE mieux vaut pas.
Mais là c'est plus embêtant : difficile de changer cela au moment de
l'échange.
comme le dit CrazyCat, si on est en UTF-8 on peut tout à fait supprimer
la déclaration XML (pas le prologue) sans céder un octet aux Standards
:-)
In article <48aedca8$0$31426$, Patrick Mevzek wrote:
Le Fri, 22 Aug 2008 17:19:28 +0200, mpg a écrit: > Quelle est actuellement la façon recommandée de servir des documents en > xhtml 1.0 (strict) pour être compatible (si possible) à la fois avec les > standards et les navigateurs existants ?
> - prologue xml : présent ou pas ?
Standard : oui Navigateurs : comme vous le dites avec IE mieux vaut pas.
Mais là c'est plus embêtant : difficile de changer cela au moment de l'échange.
comme le dit CrazyCat, si on est en UTF-8 on peut tout à fait supprimer la déclaration XML (pas le prologue) sans céder un octet aux Standards :-)
Le prologue xml est (d'après w3.org) essentiellement à utiliser lorsque
(une déclaration XML est requise)
les pages ne sont ni en UTF-8 ni en UTF-16 et qu'aucun encodage ne peut être déterminé.
Je suppose que le prologue est obligatoire lorsque le XHTML est lu comme de l'XML, non ?
si c'est en UTF-8, non
Vous faites référence à une partie de la recommandation XHTML 1.0 dans un autre fil qu'il me parait important de reprendre ici :
Thomas wrote:
Le prologue xml est (d'après w3.org) essentiellement à utiliser lorsque
(une déclaration XML est requise)
les pages ne sont ni en UTF-8 ni en UTF-16 et qu'aucun encodage ne peut
être déterminé.
Je suppose que le prologue est obligatoire lorsque le XHTML est lu comme
de l'XML, non ?
si c'est en UTF-8, non
Vous faites référence à une partie de la recommandation XHTML 1.0 dans
un autre fil qu'il me parait important de reprendre ici :
<fantome.forums.tDeContes-E17A91.15522723082008@news.free.fr>
Le prologue xml est (d'après w3.org) essentiellement à utiliser lorsque
(une déclaration XML est requise)
les pages ne sont ni en UTF-8 ni en UTF-16 et qu'aucun encodage ne peut être déterminé.
Je suppose que le prologue est obligatoire lorsque le XHTML est lu comme de l'XML, non ?
si c'est en UTF-8, non
Vous faites référence à une partie de la recommandation XHTML 1.0 dans un autre fil qu'il me parait important de reprendre ici :
Pierre Goiffon
Thomas wrote:
Le prologue xml est (d'après w3.org) essentiellement à utiliser lorsque
(une déclaration XML est requise)
Je viens de tomber sur ce billet qui explique très bien les 2 notions, très instructif : http://lachy.id.au/log/2006/09/xml-prolog Appris quelque chose !
les pages ne sont ni en UTF-8 ni en UTF-16 et qu'aucun encodage ne peut être déterminé.
Je suppose que le prologue est obligatoire lorsque le XHTML est lu comme de l'XML, non ?
si c'est en UTF-8, non
En fait mes réponses précédentes manquaient de précisions.
Considérons donc les différents éléments de la recommandation XHTML 1.0 :
- http://www.w3.org/TR/xhtml1/#C_9 "In XHTML-conforming user agents, the value of the encoding declaration of the XML declaration takes precedence."
- http://www.w3.org/TR/xhtml1/#strict "An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol."
J'en déduis que (avec de gros doutes et un manque d'informations évident) :
- XHTML 1.0 servit en text/html Si le codage est déclaré dans les entêtes, il est prioritaire Si pas défini, un navigateur "XHTML conforming" va aller lire le codage dans la déclaration XML, les autres dans le meta. Si pas défini et pas de déclaration XML les navigateurs "XHTML conforming" utiliseront UTF-8 ou UTF-16 pour tenter de lire le document (quid du paramètre charset par défaut présent dans tous les navigateurs ?)
- XHTML 1.0 ou 1.1 servit en application/xml+xhtml Si le codage est déclaré dans les entêtes, il est prioritaire Si pas défini et que pas de déclaration XML (ce qui semble possible à lire la recommandation XHTML 1.1) alors le document sera lu en utilisant UTF-8 ou UTF-16 (et à nouveau : quid du paramètre charset par défaut du navigateur ?)
Thomas wrote:
Le prologue xml est (d'après w3.org) essentiellement à utiliser lorsque
(une déclaration XML est requise)
Je viens de tomber sur ce billet qui explique très bien les 2 notions,
très instructif :
http://lachy.id.au/log/2006/09/xml-prolog
Appris quelque chose !
les pages ne sont ni en UTF-8 ni en UTF-16 et qu'aucun encodage ne peut
être déterminé.
Je suppose que le prologue est obligatoire lorsque le XHTML est lu comme
de l'XML, non ?
si c'est en UTF-8, non
En fait mes réponses précédentes manquaient de précisions.
Considérons donc les différents éléments de la recommandation XHTML 1.0 :
- http://www.w3.org/TR/xhtml1/#C_9
"In XHTML-conforming user agents, the value of the encoding declaration
of the XML declaration takes precedence."
- http://www.w3.org/TR/xhtml1/#strict
"An XML declaration is not required in all XML documents; however XHTML
document authors are strongly encouraged to use XML declarations in all
their documents. Such a declaration is required when the character
encoding of the document is other than the default UTF-8 or UTF-16 and
no encoding was determined by a higher-level protocol."
J'en déduis que (avec de gros doutes et un manque d'informations évident) :
- XHTML 1.0 servit en text/html
Si le codage est déclaré dans les entêtes, il est prioritaire
Si pas défini, un navigateur "XHTML conforming" va aller lire le codage
dans la déclaration XML, les autres dans le meta.
Si pas défini et pas de déclaration XML les navigateurs "XHTML
conforming" utiliseront UTF-8 ou UTF-16 pour tenter de lire le document
(quid du paramètre charset par défaut présent dans tous les navigateurs ?)
- XHTML 1.0 ou 1.1 servit en application/xml+xhtml
Si le codage est déclaré dans les entêtes, il est prioritaire
Si pas défini et que pas de déclaration XML (ce qui semble possible à
lire la recommandation XHTML 1.1) alors le document sera lu en utilisant
UTF-8 ou UTF-16 (et à nouveau : quid du paramètre charset par défaut du
navigateur ?)
Le prologue xml est (d'après w3.org) essentiellement à utiliser lorsque
(une déclaration XML est requise)
Je viens de tomber sur ce billet qui explique très bien les 2 notions, très instructif : http://lachy.id.au/log/2006/09/xml-prolog Appris quelque chose !
les pages ne sont ni en UTF-8 ni en UTF-16 et qu'aucun encodage ne peut être déterminé.
Je suppose que le prologue est obligatoire lorsque le XHTML est lu comme de l'XML, non ?
si c'est en UTF-8, non
En fait mes réponses précédentes manquaient de précisions.
Considérons donc les différents éléments de la recommandation XHTML 1.0 :
- http://www.w3.org/TR/xhtml1/#C_9 "In XHTML-conforming user agents, the value of the encoding declaration of the XML declaration takes precedence."
- http://www.w3.org/TR/xhtml1/#strict "An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol."
J'en déduis que (avec de gros doutes et un manque d'informations évident) :
- XHTML 1.0 servit en text/html Si le codage est déclaré dans les entêtes, il est prioritaire Si pas défini, un navigateur "XHTML conforming" va aller lire le codage dans la déclaration XML, les autres dans le meta. Si pas défini et pas de déclaration XML les navigateurs "XHTML conforming" utiliseront UTF-8 ou UTF-16 pour tenter de lire le document (quid du paramètre charset par défaut présent dans tous les navigateurs ?)
- XHTML 1.0 ou 1.1 servit en application/xml+xhtml Si le codage est déclaré dans les entêtes, il est prioritaire Si pas défini et que pas de déclaration XML (ce qui semble possible à lire la recommandation XHTML 1.1) alors le document sera lu en utilisant UTF-8 ou UTF-16 (et à nouveau : quid du paramètre charset par défaut du navigateur ?)
mpg
Bonjour,
je me permets de relancer cette discussion...
Le (on) vendredi 22 août 2008 18:40, Pierre Goiffon a écrit (wrote) :
D'abord vous demander pourquoi utiliser XHTML : sur le web aujourd'hui cela n'apporte que des contraintes (beaucoup) et aucun avantages.
J'ai effectivement pas mal réfléchi et je me suis dit qu'au fond en effet pour quoi ne pas tout bonnement utiliser de l'HTML strict plutôt, j'ai donc essayé.
Et là j'ai compris qu'un truc que j'aime en XHTML, c'est que les fautes de frappe dans les balises se traduisent beaucoup plus facilement par des erreurs de validation. Je fais souvent des coquilles du genre "fermer" un <li> par un <li> (et non </li>). Je viens de réaliser qu'en HTML c'est légal et que ça a un sens (très différent du sens souhaité, et rendant très moche). Il m'a quand même fallu 5 bonnes minutes pour comprendre pourquoi c'était normal que ça valide en HTML !
Heureusement, tidy produit quand même un avertissement pour ce genre de choses, ce qui me permet de repérer mes fautes de frappe assez facilement.
N'empêche que j'envisage fortement de repasser quand même en XHTML, parce que sincèrement *j'aime* que <li>blabla<li> soit considéré comme une erreur : je ne taperai jamais ça volontairement.
Je me rends compte que tout ça est bien connu des vieux routards des balises qui hantent ces lieux, mais je viens de réaliser de façon personnelle ce que soupe de balise signifie...
Manuel.
Bonjour,
je me permets de relancer cette discussion...
Le (on) vendredi 22 août 2008 18:40, Pierre Goiffon a écrit (wrote) :
D'abord vous demander pourquoi utiliser XHTML : sur le web aujourd'hui
cela n'apporte que des contraintes (beaucoup) et aucun avantages.
J'ai effectivement pas mal réfléchi et je me suis dit qu'au fond en effet
pour quoi ne pas tout bonnement utiliser de l'HTML strict plutôt, j'ai donc
essayé.
Et là j'ai compris qu'un truc que j'aime en XHTML, c'est que les fautes de
frappe dans les balises se traduisent beaucoup plus facilement par des
erreurs de validation. Je fais souvent des coquilles du genre "fermer" un
<li> par un <li> (et non </li>). Je viens de réaliser qu'en HTML c'est
légal et que ça a un sens (très différent du sens souhaité, et rendant très
moche). Il m'a quand même fallu 5 bonnes minutes pour comprendre pourquoi
c'était normal que ça valide en HTML !
Heureusement, tidy produit quand même un avertissement pour ce genre de
choses, ce qui me permet de repérer mes fautes de frappe assez facilement.
N'empêche que j'envisage fortement de repasser quand même en XHTML, parce
que sincèrement *j'aime* que <li>blabla<li> soit considéré comme une
erreur : je ne taperai jamais ça volontairement.
Je me rends compte que tout ça est bien connu des vieux routards des balises
qui hantent ces lieux, mais je viens de réaliser de façon personnelle ce
que soupe de balise signifie...
Le (on) vendredi 22 août 2008 18:40, Pierre Goiffon a écrit (wrote) :
D'abord vous demander pourquoi utiliser XHTML : sur le web aujourd'hui cela n'apporte que des contraintes (beaucoup) et aucun avantages.
J'ai effectivement pas mal réfléchi et je me suis dit qu'au fond en effet pour quoi ne pas tout bonnement utiliser de l'HTML strict plutôt, j'ai donc essayé.
Et là j'ai compris qu'un truc que j'aime en XHTML, c'est que les fautes de frappe dans les balises se traduisent beaucoup plus facilement par des erreurs de validation. Je fais souvent des coquilles du genre "fermer" un <li> par un <li> (et non </li>). Je viens de réaliser qu'en HTML c'est légal et que ça a un sens (très différent du sens souhaité, et rendant très moche). Il m'a quand même fallu 5 bonnes minutes pour comprendre pourquoi c'était normal que ça valide en HTML !
Heureusement, tidy produit quand même un avertissement pour ce genre de choses, ce qui me permet de repérer mes fautes de frappe assez facilement.
N'empêche que j'envisage fortement de repasser quand même en XHTML, parce que sincèrement *j'aime* que <li>blabla<li> soit considéré comme une erreur : je ne taperai jamais ça volontairement.
Je me rends compte que tout ça est bien connu des vieux routards des balises qui hantent ces lieux, mais je viens de réaliser de façon personnelle ce que soupe de balise signifie...
Manuel.
Thomas
In article <g9c0ps$jc1$, mpg wrote:
Je me rends compte que tout ça est bien connu des vieux routards des balises qui hantent ces lieux, mais je viens de réaliser de façon personnelle ce que soupe de balise signifie...
In article <g9c0ps$jc1$1@talisker.lacave.net>, mpg <mpg@elzevir.fr>
wrote:
Je me rends compte que tout ça est bien connu des vieux routards des balises
qui hantent ces lieux, mais je viens de réaliser de façon personnelle ce
que soupe de balise signifie...
Je me rends compte que tout ça est bien connu des vieux routards des balises qui hantent ces lieux, mais je viens de réaliser de façon personnelle ce que soupe de balise signifie...
J'ai effectivement pas mal réfléchi et je me suis dit qu'au fond en effet pour quoi ne pas tout bonnement utiliser de l'HTML strict plutôt, j'ai donc essayé.
Et là j'ai compris qu'un truc que j'aime en XHTML, c'est que les fautes de frappe dans les balises se traduisent beaucoup plus facilement par des erreurs de validation. Je fais souvent des coquilles du genre "fermer" un <li> par un <li> (et non </li>). Je viens de réaliser qu'en HTML c'est légal et que ça a un sens
Ha ? J'ai été surpris de lire ça et pas bien le temps de chercher maintenant, pourriez-vous développer ?
N'empêche que j'envisage fortement de repasser quand même en XHTML, parce que sincèrement *j'aime* que <li>blabla<li> soit considéré comme une erreur : je ne taperai jamais ça volontairement.
Je n'ai jamais considéré cet argument comme solide : dans tous les cas si vous voulez bien faire les choses il faut être extrêmement attentif au source (x)html que vous générez. Les contraintes apportées par XHTML sur la validité XML ne sont à mon sens absolument pas pertinentes et ne permettent absolument pas de se prémunir de mauvaises pratiques (à l'opposé de bonnes pratiques :) )
mpg wrote:
J'ai effectivement pas mal réfléchi et je me suis dit qu'au fond en effet
pour quoi ne pas tout bonnement utiliser de l'HTML strict plutôt, j'ai donc
essayé.
Et là j'ai compris qu'un truc que j'aime en XHTML, c'est que les fautes de
frappe dans les balises se traduisent beaucoup plus facilement par des
erreurs de validation. Je fais souvent des coquilles du genre "fermer" un
<li> par un <li> (et non </li>). Je viens de réaliser qu'en HTML c'est
légal et que ça a un sens
Ha ? J'ai été surpris de lire ça et pas bien le temps de chercher
maintenant, pourriez-vous développer ?
N'empêche que j'envisage fortement de repasser quand même en XHTML, parce
que sincèrement *j'aime* que <li>blabla<li> soit considéré comme une
erreur : je ne taperai jamais ça volontairement.
Je n'ai jamais considéré cet argument comme solide : dans tous les cas
si vous voulez bien faire les choses il faut être extrêmement attentif
au source (x)html que vous générez. Les contraintes apportées par XHTML
sur la validité XML ne sont à mon sens absolument pas pertinentes et ne
permettent absolument pas de se prémunir de mauvaises pratiques (à
l'opposé de bonnes pratiques :) )
J'ai effectivement pas mal réfléchi et je me suis dit qu'au fond en effet pour quoi ne pas tout bonnement utiliser de l'HTML strict plutôt, j'ai donc essayé.
Et là j'ai compris qu'un truc que j'aime en XHTML, c'est que les fautes de frappe dans les balises se traduisent beaucoup plus facilement par des erreurs de validation. Je fais souvent des coquilles du genre "fermer" un <li> par un <li> (et non </li>). Je viens de réaliser qu'en HTML c'est légal et que ça a un sens
Ha ? J'ai été surpris de lire ça et pas bien le temps de chercher maintenant, pourriez-vous développer ?
N'empêche que j'envisage fortement de repasser quand même en XHTML, parce que sincèrement *j'aime* que <li>blabla<li> soit considéré comme une erreur : je ne taperai jamais ça volontairement.
Je n'ai jamais considéré cet argument comme solide : dans tous les cas si vous voulez bien faire les choses il faut être extrêmement attentif au source (x)html que vous générez. Les contraintes apportées par XHTML sur la validité XML ne sont à mon sens absolument pas pertinentes et ne permettent absolument pas de se prémunir de mauvaises pratiques (à l'opposé de bonnes pratiques :) )
Mickaël Wolff
Pierre Goiffon a écrit :
Je n'ai jamais considéré cet argument comme solide : dans tous les cas si vous voulez bien faire les choses il faut être extrêmement attentif au source (x)html que vous générez. Les contraintes apportées par XHTML sur la validité XML ne sont à mon sens absolument pas pertinentes et ne permettent absolument pas de se prémunir de mauvaises pratiques (à l'opposé de bonnes pratiques :) )
Ce genre de chose m'a toujours posé des problèmes existentiels :
<p><div><div><p><p>
Pratiquer le XHTML permet d'éviter au navigateur d'interpréter à sa sauce ce genre d'excentricités.
C'est comme le parenthésage des expressions logiques, c'est souvent inutile, mais parfois ça sauve la vie, et sauvegarde de nombreuses heures de recherche.
Je n'ai jamais considéré cet argument comme solide : dans tous les cas
si vous voulez bien faire les choses il faut être extrêmement attentif
au source (x)html que vous générez. Les contraintes apportées par XHTML
sur la validité XML ne sont à mon sens absolument pas pertinentes et ne
permettent absolument pas de se prémunir de mauvaises pratiques (à
l'opposé de bonnes pratiques :) )
Ce genre de chose m'a toujours posé des problèmes existentiels :
<p><div><div><p><p>
Pratiquer le XHTML permet d'éviter au navigateur d'interpréter à sa
sauce ce genre d'excentricités.
C'est comme le parenthésage des expressions logiques, c'est souvent
inutile, mais parfois ça sauve la vie, et sauvegarde de nombreuses
heures de recherche.
Je n'ai jamais considéré cet argument comme solide : dans tous les cas si vous voulez bien faire les choses il faut être extrêmement attentif au source (x)html que vous générez. Les contraintes apportées par XHTML sur la validité XML ne sont à mon sens absolument pas pertinentes et ne permettent absolument pas de se prémunir de mauvaises pratiques (à l'opposé de bonnes pratiques :) )
Ce genre de chose m'a toujours posé des problèmes existentiels :
<p><div><div><p><p>
Pratiquer le XHTML permet d'éviter au navigateur d'interpréter à sa sauce ce genre d'excentricités.
C'est comme le parenthésage des expressions logiques, c'est souvent inutile, mais parfois ça sauve la vie, et sauvegarde de nombreuses heures de recherche.
Ce genre de chose m'a toujours posé des problèmes existentiels :
<p><div><div><p><p>
Pratiquer le XHTML permet d'éviter au navigateur d'interpréter à sa sauce ce genre d'excentricités.
Ne pas avoir à fermer des LI ou des TR/TD a longtemps été plus que pratique. Mais nous en avons heureusement fini avec des sources HTML de 100Ko et plus contenant toute la mise en forme...
En tout cas, au poste de développeur (et pas d'intégrateur HTML, chacun son truc), je n'ai jamais rencontré d'erreurs générées par un balisage foireux, erreurs qui auraient été évitées par un XHTML valide. De mon expérience pour arriver à des prb avec le "laxisme" de HTML il faut le faire exprès (d'où ma demande de détails à mpg)
Mickaël Wolff wrote:
Ce genre de chose m'a toujours posé des problèmes existentiels :
<p><div><div><p><p>
Pratiquer le XHTML permet d'éviter au navigateur d'interpréter à sa
sauce ce genre d'excentricités.
Ne pas avoir à fermer des LI ou des TR/TD a longtemps été plus que
pratique. Mais nous en avons heureusement fini avec des sources HTML de
100Ko et plus contenant toute la mise en forme...
En tout cas, au poste de développeur (et pas d'intégrateur HTML, chacun
son truc), je n'ai jamais rencontré d'erreurs générées par un balisage
foireux, erreurs qui auraient été évitées par un XHTML valide. De mon
expérience pour arriver à des prb avec le "laxisme" de HTML il faut le
faire exprès (d'où ma demande de détails à mpg)
Ce genre de chose m'a toujours posé des problèmes existentiels :
<p><div><div><p><p>
Pratiquer le XHTML permet d'éviter au navigateur d'interpréter à sa sauce ce genre d'excentricités.
Ne pas avoir à fermer des LI ou des TR/TD a longtemps été plus que pratique. Mais nous en avons heureusement fini avec des sources HTML de 100Ko et plus contenant toute la mise en forme...
En tout cas, au poste de développeur (et pas d'intégrateur HTML, chacun son truc), je n'ai jamais rencontré d'erreurs générées par un balisage foireux, erreurs qui auraient été évitées par un XHTML valide. De mon expérience pour arriver à des prb avec le "laxisme" de HTML il faut le faire exprès (d'où ma demande de détails à mpg)
