Geckozone

Il faudrait que le "validator" envoit un "warning" (différent de "error") si le document XHTML 1.0 est envoyé en text/html

Toto a écrit :Il faudrait que le "validator" envoit un "warning" (différent de "error") si le document XHTML 1.0 est envoyé en text/html

Le problème c'est qu'il n'envoie ni warning ni error D'ailleurs la page du validateur elle-même est valide XHTML 1.0 alors qu'elle ne contient pas de <meta http-equiv="Content-Type"

Et avec un fichier testé en local, ça donne des choses comme ça

Toto a écrit :Il faudrait que le "validator" envoit un "warning" (différent de "error") si le document XHTML 1.0 est envoyé en text/html

Je pense que non, enfin il ne peut pas deviner si tu as bien suivi les règles de compatibilité HTML ou pas... Mais si tu l'as fait c'est légitime et il ne devrait pas y avoir de pénalisation.

Ptit Lutin a écrit :Le problème c'est qu'il n'envoie ni warning ni error D'ailleurs la page du validateur elle-même est valide XHTML 1.0 alors qu'elle ne contient pas de <meta http-equiv="Content-Type"

C'est normal, normalement on envoie ce genre de choses vraiment dans les en-têtes HTTP et pas dans un équivalent meta.

Live Http Headers révèle que le type envoyé par la page du validateur est bien text/html

calimo a écrit :Tiens donc... je parlais évidemment des nightlies du tronc, c'est pas le genre de trucs qui vont être corrigées dans Aviary

Je reviens sur le sujet initial
Testé avec une nightly du tronc et c'est OK
(reste plus qu'à attendre la synchronisation entre le tronc et la branche... Gecko 1.8 et Firefox 1.1 je suppose)

Personnellement, j'utilise le Doctype "XHTML 1.0" et le Type "text/html" pour les raisons suivantes:

http://blog.alsacreations.com/2005/04/0 ... r-le-xhtml

* Toute balise ouvrante doit être fermée
* Balises et attributs en minuscules
* Valeurs entre quotes (apostrophes) ou double quotes (guillemets)
* Chaque propriété doit avoir une valeur (pas de propriété vide)
* Les balises doivent être correctement imbriquées

Non seulement, la syntaxe est plus rigoureuse mais en plus, elle est interprétée correctement par tous les navigateurs. La différence d'affichage entre les différents navigateurs dépend surtout des styles css.

Bonne méditation.

Guilhem.

Guilhem a écrit :Personnellement, j'utilise le Doctype "XHTML 1.0" et le Type "text/html"

Les navigateurs qui rencontrent text/html interprète la page avec le parser HTML et pas XML (même Firefox)... non ?
Dans ce cas, la page est considérée comme du HTML mal formé. Et l'interprétation est laissée au navigateur avec les incertitudes qui cela comporte.

Donc écrire du XHTML en sachant qu'il sera interprété par le parser HTML, je ne vois pas trop l'intérêt.
Pourtant dans l'absolu je préférerais aussi faire du XHTML (pour sa rigueur également), mais dans ces conditions c'est vraiment dommage

Si j'ai dis une anerie (ou plusieurs ), faut pas hésiter à le signaler.

la page est considérée comme du HTML mal formé

Mais qu'est du HTML mal formé ?

Chez moi, les balises sont correctement interprétées et l'affichage correct grâce à la gestion des css...

Guilhem a écrit :Mais qu'est du HTML mal formé ?

Je veux dire par là que d'un côté dans le DOCTYPE tu précises que c'est du XHTML 1.0 (donc destiné au parser XML), de l'autre tu indiques text/html (donc destiné au parser HTML)... donc au navigateur de traiter ce XHTML comme du HTML (c'est ce que je nomme du HTML mal formé).

Guilhem a écrit :Chez moi, les balises sont correctement interprétées et l'affichage correct grâce à la gestion des css...

Elles sont peut-être bien interprétées parce que les navigateurs (et les parsers HTML) sont assez tolérants.
C'est ce que disais calimo:

calimo a écrit :

Ptit Lutin a écrit :Si je veux écrire une page en xhtml fonctionnant à la fois sous Firefox et IE comment je fais ?

IE ne supporte pas le XHTML. Au mieux il traite le XHTML que tu lui as envoyé en text/html comme du html malformé, exactement comme Firefox, les navigateurs sont suffisemment tolérant pour que ça passe mais ça devrait pas. Cf. http://hixie.ch/advocacy/xhtml

Tu as tout à fait raison ! 8)
Ma question était plutôt:
Et alors ? Cela change quoi pour l'internaute que ce soit du XHTML ou du HTML, à partir du moment où le site s'affiche correctement ?

On est d'accord alors
Ton XHTML est considéré comme du HTML.

Ce qui me gène c'est de laisser la responsabilité de l'interprétation au navigateur. Pour imager ma pensée, écrire du XHTML pour qu'il soit traité comme du HTML, c'est comme acheter du tissu de qualité pour en faire un chiffon. Je préfère acheter du tissu bas de gamme si c'est pour en faire un chiffon (très imagé je reconnais )

c'est comme acheter du tissu de qualité pour en faire un chiffon. Je préfère acheter du tissu bas de gamme si c'est pour en faire un chiffon (très imagé je reconnais Mort de rire Clin d'oeil )

Ton chiffon n'aura pas le même aspect que ton tissu haut de gamme ! Alors qu'ici, si ton navigateur interprête le XHTML comme de l'HTML, le résultat sera le même que si tu envoyais au client de l'HTML...

Je m'immisce dans la discussion sur la pointe des pieds et en raclant ma gorge, un peu de gêné de prendre la parole ... Allez hop, je me lance :

Guilhem a écrit :Cela change quoi pour l'internaute [...], à partir du moment où le site s'affiche correctement ?

Ton propos n'est ni faux, ni idiot; cependant on connait les dérives possibles de ce genre d'attitude. Suivez mon regard vers le moteur d'un navigateur obsolète.

Voili, je vous remercie de m'avoir écouté (raclement de gorge). Je vous laisse, maintenant.
[Humpfff se retira alors comme il est apparu. Sur la pointe des pieds. Façon moonwalk]

Suivez mon regard vers le moteur d'un navigateur obsolète

Ta remarque n'est valable que si le XHTML est beaucoup plus permissif que le HTML. Or il ne l'est pas, bien au contraire ! Je ne vois pas ce que cela comporte comme risque de coder plus rigoureusement et proprement !
M'enfin... J'ai l'impression que vos nuances s'arrêtent sur les mots. Oui, je code en XHTML et le navigateur interprête en HTML et alors ? Mon code est beaucoup plus propre...

Guilhem a écrit :

c'est comme acheter du tissu de qualité pour en faire un chiffon. Je préfère acheter du tissu bas de gamme si c'est pour en faire un chiffon (très imagé je reconnais)

Ton chiffon n'aura pas le même aspect que ton tissu haut de gamme ! Alors qu'ici, si ton navigateur interprête le XHTML comme de l'HTML, le résultat sera le même que si tu envoyais au client de l'HTML...

Ce qui compte dans mes tissus (premier prix ou haut de gamme) ce n'est pas l'aspect mais l'usage: Si tu dis "regardez mon beau tissu ! (équivalent à "regardez mon site est en XHTML 1.0 et le code source avec des balises fermées correctement etc...") mais que tu l'utilises comme chiffon (c'est à dire que tu l'envoies en text/html) c'est un peu dommage non ? même si le tissu de qualité nettoie aussi bien que le chiffon (c'est à dire que le rendu est le même dans les navigateurs)

En clair, où est l'intérêt de rendre ton code valide XHTML 1.0 (donc XML) s'il est géré comme du HTML ? (à part pouvoir dire "mon code est valide XHTML 1.0")

A mon avis, du HTML 4.01 bien écrit est aussi valable (et sûrement plus cohérent dans sa finalité) que du XHTML envoyé en text/html.

Pour moi, les deux choses cohérentes sont:
du HTML envoyé en text/html : HTML 4.01 par exemple
du XHTML envoyé en application/xhtml+xml : XHTML 1.1

Humpfff a écrit :Voili, je vous remercie de m'avoir écouté (raclement de gorge). Je vous laisse, maintenant.
[Humpfff se retira alors comme il est apparu. Sur la pointe des pieds. Façon moonwalk]

tu es le bienvenu Humpfff . Je pense que tu as bien saisi où je voulais en venir.

Guilhem a écrit :Je ne vois pas ce que cela comporte comme risque de coder plus rigoureusement et proprement !. Oui, je code en XHTML et le navigateur interprête en HTML et alors ? Mon code est beaucoup plus propre...

Mais ta rigueur est vaine puisque de toute manière c'est géré comme du HTML