Du XHTML 1.1 envoyé au format text/html

calimo · Message par **calimo** » 08 avr. 2006, 16:44

Aaaaaaaaaaarrrrgggg !!!!!!

Hum...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Code : Tout sélectionner

Content-Type: text/html

Les deux sont incompatibles (ne devraient pas être utilisés ensemble)

CF http://sebastienguillon.com/traduction/ ... ml#summary

Rappel, encore une fois :

Pour envoyer du XHTML en text/html, on doit respecter les 16 règles de compatibilité HTML (voir aussi en français où il n'y en a que 13)
XHTML 1.1 ne permet pas de respecter ces 13 règles

=> il est interdit d'envoyer du XHTML 1.1 en text/html

J'ai l'impression d'être un vieux disque rayé à répéter sans cesse cela, mais sincèrement, c'est vraiment important. Il en va de l'accessibilité de la page !
Par pitié, cessez la course à la dernière version de la spec ! Le web n'est pas prêt pour le XHTML.

Aller, un dernier lien pour la route : http://hixie.ch/advocacy/xhtml.fr

SB · Message par SB » 08 avr. 2006, 16:52

calimo a écrit :Les deux sont incompatibles

Non.

calimo a écrit :(ne devraient pas être utilisés ensemble)

Oui.

calimo a écrit :il est interdit d'envoyer du XHTML 1.1 en text/html

Non. Simplement déconseillé. Un script php à placer en tête de page permettra d'envoyer un format application/xhtml+xml aux navigateurs qui l'acceptent :

Code : Tout sélectionner

if( stristr($HTTP_SERVER_VARS["HTTP_ACCEPT"], "application/xhtml+xml") || empty($HTTP_SERVER_VARS["HTTP_ACCEPT"])) 
{
	header("Content-type: application/xhtml+xml");
	echo "<?xml version='1.0' encoding='UTF-8'?>\n";
	echo "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">\n";
	echo "<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">\n";
}
else 
{
	header("Content-type: text/html; charset=UTF-8");
	echo "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">\n";
	echo "<html xmlns="http://www.w3.org/1999/xhtml" lang="fr">\n";
}

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

calimo · Message par **calimo** » 08 avr. 2006, 17:42

SB a écrit :
calimo a écrit :Les deux sont incompatibles
Non.

Si si j'insiste. Ce n'est pas pour rien que la spec XHTML a une appendice "Règles de compatibilité" qui «résume les règles pour les auteurs qui souhaitent que leur document XHTML s'affiche sur les agents utilisateurs [HTML] existants.»

Le XHTML 1.1 est malheureusement incompatible avec ces règles.

SB a écrit :
calimo a écrit :il est interdit d'envoyer du XHTML 1.1 en text/html
Non. Simplement déconseillé.

Désolé de te contredire, mais la définition de SHOULD NOT telle que définie dans la RFC2119 est très claire :

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

Ce n'est pas MUST NOT, mais il y a tellement de conditions que ça l'est presque.

(Edit : en fait déconseillé n'est pas le mot adapté. Les balises de mise en forme sont déconseillées, mais peuvent tout à fait être utilisées (il n'y a pas de should not). Ce n'est pas le cas ici, où il faut vraiment éviter de le faire sauf si on ne peut pas faire autrement et que l'on a bien pesé les problèmes potentiels (aucune des conditions n'ayant visiblement été appliquée par GizMecano).)

Je ne connais aucune page XHTML envoyée en text/html respectant ces conditions

Et celle de GizMecano est très certainement dans ce cas.

Ton code est très joli, mais au final il finit bien par envoyer du XHTML 1.1 en text/html ne respectant pas la note du W3C. Merci l'accessibilité

Edit 2 : un exemple concret de ces incompatibilités : xml:lang="en". En HTML il faut écrire lang="en". En XHTML 1.0 compatible HTML, il faut mettre à la fois lang et xml:lang, En XHTML 1.1, on ne peut plus mettre lang. Il y a donc bien une incompatibilité avec le HTML

Edit 3 : désolé pour les éditions j'ai voulu répondre trop vite

Message par **Benoit** » 08 avr. 2006, 18:20

calimo a écrit :
SB a écrit :
calimo a écrit :Les deux sont incompatibles
Non.
Si si j'insiste. Ce n'est pas pour rien que la spec XHTML a une appendice "Règles de compatibilité" qui «résume les règles pour les auteurs qui souhaitent que leur document XHTML s'affiche sur les agents utilisateurs [HTML] existants.»
Le XHTML 1.1 est malheureusement incompatible avec ces règles.

Heu oui, mais en quoi envoyer du XHTML 1.1 aux navigateurs obsolètes est plus répréhensible que la soupe de balises classique ? S'ils la mangent tant mieux.

Ce qu'il faut surtout éviter c'est de faire de la sorte avec les navigateurs susceptibles de vraiment comprendre le XHTML 1.1. Et il faut savoir que par rapport à du HTML 4.01 strict on gagne peut-être les règles de parsing strictes, mais on perd le rendu incrémental donc la page a l'air de se charger plus lentement.

calimo · Message par **calimo** » 08 avr. 2006, 18:52

Benoit a écrit :Heu oui, mais en quoi envoyer du XHTML 1.1 aux navigateurs obsolètes est plus répréhensible que la soupe de balises classique ?

Le but ici est justement d'essayer de faire mieux que du tag-soup

SB · Message par SB » 08 avr. 2006, 19:09

calimo a écrit :Désolé de te contredire, mais la définition de SHOULD NOT telle que définie dans la RFC2119 est très claire :
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
Ce n'est pas MUST NOT, mais il y a tellement de conditions que ça l'est presque.

Tu confirmes ce que je dis puisque la note stipule qu'il peut exister de bonnes raisons de le faire, voire que ça peut même être utile.
Quant à ces fameuses 16 conditions je te fais remarquer qu'il ne s'agit pas de conditions. En effet, contrairement aux appendices A et B qui eux sont normatifs, l'appendice C est purement informatif. Libre à nous de suivre ces remarques ou pas. D'autant que parmi ces lignes directrices (comme il est plus correct de traduire "guidelines" et non pas règles qui est la traduction de "rules") certaines sont ridicules. C7 nous dit d'utiliser conjointement les attributs lang et xml:lang. Hors en html ce dernier n'existe pas. C8 nous dit d'utiliser conjointement id="#foo" et name="#foo" avec comme exemple une balise <a>. Hors, comme ils le font remarquer à la fin, en xhtml l'attribut name a été abandonné (sauf balises de formulaires). Concrètement si tu suis ces directives tu te retrouves avec une page non valide à la fois en html et en xhtml.

Inutile donc de faire croire que ça nuit à l'accessibilité, le seul moyen de le savoir c'est d'essayer. Avec Lynx en tout cas tout passe correctement. Je n'ai pas d'autres navigateurs spéciaux pour tester.
Ce que personnellement j'ai fait pour mon site, c'est demander, dans ma page accessibilité, à ce que ceux qui trouvent des défauts me les signalent. Jusqu'ici personne ne s'en est plaint de mon xhtml 1.1 envoyé au format text/html. Eventuellement ce qu'on peut reprocher à GizMecano c'est l'absence de cette page accessibilité ainsi que de moyen de le joindre vu que l'adresse mail est montrée sur une image que certains navigateurs ne pourront donc pas afficher.

GizMecano a écrit :même si je précise être tout à fait prêt à le croire sur parole

Justement pas.

GizMecano a écrit :Puis-je, sans faire de bêtises, simplement remplacer le bout de code incriminé par Content-Type: text/xhtml ?

Non, text/xml ou application/xhtml+xml à la rigueur mais essaie ensuite avec Internet Explorer pour rire.

Laisse comme c'est, c'est très bien.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Sébastien Guillon · Message par **Sébastien Guillon** » 08 avr. 2006, 21:50

SB ton code PHP n'est pas terrible, je déconseillerais à qui que ce soit de le reprendre tel quel:

Premièrement il serait bon de passer à la variable

Code : Tout sélectionner

$_SERVER['HTTP_ACCEPT']

et d'oublier

Code : Tout sélectionner

$HTTP_SERVER_VARS["HTTP_ACCEPT"]

.

Ensuite si ce code sert à faire de la négociation de contenu, il échoue sur 2 points principaux :

1. la détection
2. le contenu envoyé

1. La détection

Tu ne tiens pas compte des niveaux de qualité indiqués par l'agent utilisateur.

Voici la détection que j'utilise sur mon site :

Code : Tout sélectionner

<?php
$mime = 'text/html'; // Type par défaut
if(isset($_SERVER['HTTP_ACCEPT']))
{
  if(stristr($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml') || empty($_SERVER['HTTP_ACCEPT']))
  {
    // On a trouvé "application/xhtml+xml", ou bien HTTP_ACCEPT
    // est une chaîne vide (cas du validateur du W3C)

    if(preg_match("/application\/xhtml\+xml;q=0(\.[1-9]+)/i", $_SERVER['HTTP_ACCEPT'], $matches))
    {
      // Si on trouve une valeur Q pour "application/xhtml+xml",
      // on recherche aussi la valeur Q pour "text/html"

      $xhtml_q = $matches[1];
      if(preg_match("/text\/html;q=0(\.[1-9]+)/i", $_SERVER['HTTP_ACCEPT'], $matches))
      {
        $html_q = $matches[1];
        // Si la valeur Q pour le XHTML est supérieure ou égale
        // à celle du HTML, on utilise "application/xhtml+xml"
        if($xhtml_q >= $html_q)
        {
          $mime = 'application/xhtml+xml';
        }
      }
    }
    else
    {
      // Aucune valeur Q n'a été trouvée
      $mime = 'application/xhtml+xml';
    }
  }
}
else
{
  // En cas d'absence totale de HTTP_ACCEPT
  // (comportement anormal de l'Agent Utilisateur)
  $mime = 'application/xhtml+xml';
}
?>

Ce script est très orienté XHTML, car de nombreux choix par défaut préfèrent le type MIME "application/xhtml+xml".

Par exemple si on rencontre une chaîne HTTP_ACCEPT vide, on envoit du "application/xhtml+xml". Ma justification (probablement contestable) est que si un agent ne fait aucune déclaration de préférence, le choix me revient.

Note : j'ai modifié le code pour le coller de façon lisible dans ce post, donc attention à bien le tester avant de l'utiliser.

2. Le contenu

Dans ta version, tu utilises l'attribut "lang" dans un document XHTML 1.1. Ce n'est tout simplement pas valide. Or GizMecano cherche apparemment à avoir un site valide.

Dans le cas où tu envoies le contenu en tant que HTML (text/html) tu peux en effet envoyer le document avec un DOCTYPE XHTML 1.0 en suivant les règles de compatibilités. Dans ce cas tu changes le DOCTYPE en

Code : Tout sélectionner

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

et tu devras utiliser *à la fois* lang et xml:lang à chaque fois que tu définira la langue d'un élément (pas seulement HTML).[/quote]

Message envoyé avec : Opera/8.53 (Windows NT 5.1; U; fr)

SB a écrit :C7 nous dit d'utiliser conjointement les attributs lang et xml:lang. Hors en html ce dernier n'existe pas.

Effectivement, mais en XHTML il existe : où est le problème ?

SB a écrit :C8 nous dit d'utiliser conjointement id="#foo" et name="#foo" avec comme exemple une balise <a>. Hors, comme ils le font remarquer à la fin, en xhtml l'attribut name a été abandonné (sauf balises de formulaires)

Là encore où vois-tu un problème ? L'attribut "name" existe en XHTML pour les éléments "a". L'exemple est correct. Pour les autres cas, on n'a jamais besoin de name en XHTML là où on peut utiliser un ID.

Pour finir GizMecano, je te conseille de passer au DOCTYPE XHTML 1.0 strict (cité plus haut) et de conserver un site en text/html, sans négociation de contenu.

Si tu veux une mauvaise surprise, vas voir le résultat de validation avec un validateur qui estime (c'est une question d'interpétation) que le XHTML1.1 doit être servi en tant que XHTML.

http://www.validome.org/validate/?uri=h ... octypeAUTO

Ressources utiles :

- http://www.w3.org/QA/2002/04/valid-dtd-list.html
- http://themaninblue.com/experiment/DTDMapper/
- http://www.validome.org

calimo · Message par **calimo** » 08 avr. 2006, 22:20

SB a écrit :Tu confirmes ce que je dis puisque la note stipule qu'il peut exister de bonnes raisons de le faire, voire que ça peut même être utile.

Elles peuvent exister. Reste à les trouver, et je dois avouer que je n'ai encore jamais rien vu, lu ou entendu allant dans le sens qu'une telle raison puisse exister !

As-tu seulement compris toutes les implications et soigneusement pesé les intérêts ? C'est la condition pour pouvoir le faire. Si tu ne l'as pas fait, alors tu es en contradictions avec le W3C (que ce soit une note, une règle ou une information, il n'en reste pas moins que c'est une indication sensée de la part de personnes compétentes et qu'il n'y a pas de raison de ne pas la respecter, à moins justement d'avoir compris toutes les implications et soigneusement pesé les intérêts).

SB a écrit :Quant à ces fameuses 16 conditions je te fais remarquer qu'il ne s'agit pas de conditions. En effet, contrairement aux appendices A et B qui eux sont normatifs, l'appendice C est purement informatif. Libre à nous de suivre ces remarques ou pas. D'autant que parmi ces lignes directrices (comme il est plus correct de traduire "guidelines" et non pas règles qui est la traduction de "rules") certaines sont ridicules.

C'est sur que le W3C est ridicule. De toutes façons il édicte des règles complètement déconnectées de la réalité du webdesign et ceux qui les suivent sont des abrutis

Alors si ce ne sont même pas des règles mais justes des indications, on devrait faire le contraire sinon on risque de subir une pression toujours plus forte d'uniformisation des sites qui y perdront leur personnalité

SB a écrit :C7 nous dit d'utiliser conjointement les attributs lang et xml:lang. Hors en html ce dernier n'existe pas.

... et sera ignoré.

Sans "lang" et avec uniquement xml:lang, un navigateur ne supportant pas xhtml (p.ex IE) ne pourra pas détecter la langue du document. Tant pis pour les lecteurs d'écran et navigateurs texte

Bien sûr, les directives d'accessibilité ne sont que des notes, des indications, pas des normes non plus !

Les autres indications sont du même style. Pour les utilisations "courantes" avec des navigateurs "courant", ça ne change rien, mais comme d'habitude on ne maitrise pas la configuration du visiteur, et on ne sait pas ce qui va se passer.

SB a écrit :C8 nous dit d'utiliser conjointement id="#foo" et name="#foo" avec comme exemple une balise <a>. Hors, comme ils le font remarquer à la fin, en xhtml l'attribut name a été abandonné (sauf balises de formulaires). Concrètement si tu suis ces directives tu te retrouves avec une page non valide à la fois en html et en xhtml.

Mais qui fonctionnera correctement partout. Qu'est-ce qui est le mieux ?

SB a écrit :Inutile donc de faire croire que ça nuit à l'accessibilité, le seul moyen de le savoir c'est d'essayer. Avec Lynx en tout cas tout passe correctement. Je n'ai pas d'autres navigateurs spéciaux pour tester.

C'est bien pour ça qu'il y a des directives d'accessibilité ! Parce qu'il est impossible de tout tester (il y a une quasi infinité de configurations possibles), et qu'on s'en remet au W3C pour l'avoir fait à notre place.

SB a écrit :Ce que personnellement j'ai fait pour mon site, c'est demander, dans ma page accessibilité, à ce que ceux qui trouvent des défauts me les signalent. Jusqu'ici personne ne s'en est plaint de mon xhtml 1.1 envoyé au format text/html.

Si quelqu'un avait réellement eu des problèmes, il n'aurait certainement jamais pu te contacter

GizMecano a écrit :Fichtre, je ne pensais vraiment pas cette fois-ci avoir fait une énorme boulette. J'étais même bien content de voir tous les validateurs au vert...

Ben oui, mais le validateur ne fait pas tout

Ce n'est qu'un outil qui peut aider sur certains points, mais il ne peut évidemment pas tout faire. Comme tout outil, il a des limitations. En l'occurence, il ne fait que vérifier que le balisage est correct. Il ne fait pas grand chose d'autre.
Comme le validateur CSS. Il valide la syntaxe, après si tu fais n'importe quoi dans la feuille de style il ne va pas broncher et te dire qu'il ne faut pas mettre 160px mais 180px

GizMecano a écrit :J'avoue bien humblement ne strictement pas comprendre les nuances que mentionne Calimo (et que sont sensées expliciter les liens qu'il donne), même si je précise être tout à fait prêt à le croire sur parole, ses compétences dépassant largement les miennes sur ce point.

Je suis sûr que tu n'as pas "rien" compris

En gros, tu envoies ta page XHTML 1.1 comme du HTML (text/html). Cela pose des problèmes (même si c'est rare), et un des lien que je donnais expliquait pourquoi envoyer du xhtml en text/html est néfaste.
Par exemple parce que les fins de balises " />" devraient être interprétées comme :

"
(retour à la ligne)>"

avec un joli ">".
Et : oui, certains outils le font vraiment

Non, ce n'est pas une blague. Je l'ai découvert en utilisant Thingamablog qui, lui, parsait le SGML (dont fait partie le HTML) correctement, et donc affichait plein de ">" partout

Il y a d'autres joyeusetés de ce genre

GizMecano a écrit :Ce que je comprends vraiment encore moins, c'est que depuis pas mal de temps déjà, on lit de droite comme de gauche que les spécifications XHTML sont meilleures que celles du HTML, et que si je comprends ce que veux dire Calimo, ce ne serait pas si vrai que cela...

À vrai dire, je cherche toujours ce qu'il y a de mieux (en tous cas tant qu'on envoie en text/html). Et franchement, à part le fait qu'il est traité comme du HTML invalide je ne vois pas !
(pour info, Ann Van Kesteren est un contributeur actif de Mozilla et il sait de quoi il parle

)
Par contre du moment qu'on abandonne le text/html pour le application/xhtml+xml, alors là on a tous les avantages du XML, la modularité (svg, mathml), les entités personnalisées, etc.

GizMecano a écrit :Puis-je, sans faire de bêtises, simplement remplacer le bout de code incriminé par Content-Type: text/xhtml ? Ou est-ce que, ne comprenant décidément rien, je ne ferais qu'aggraver la situation ?

Tu peux aussi tout simplement faire du XHTML 1.0 strict en suivant les indications de compatibilité HTML, ça ira tout aussi bien (voire mieux)

(mais n'oublie pas de lire ça pour quand tu passera en application/xhtml+xml, parce que là tu auras des gros problèmes.)

Bon, c'est un peu long, désolé, mais il y a tellement de choses à dire sur ce sujet

calimo · Message par **calimo** » 08 avr. 2006, 22:23

Sébastien Guillon a écrit :Si tu veux une mauvaise surprise, vas voir le résultat de validation avec un validateur qui estime (c'est une question d'interpétation) que le XHTML1.1 doit être servi en tant que XHTML.

http://www.validome.org/validate/?uri=h ... octypeAUTO

Whaaa cool adopté !

Ça faisait longtemps que je me disais que le validateur du W3C devrait faire ça

SB · Message par SB » 09 avr. 2006, 01:38

Sébastien Guillon a écrit :SB ton code PHP n'est pas terrible, je déconseillerais à qui que ce soit de le reprendre tel quel:

J'accepte tout à fait la critique puisqu'il n'est pas de moi. En fait il m'a été donné... sur ce forum dans une discussion analogue il y a quelques mois.

Je vais tester le tien et s'il fonctionne je l'adopte.

Concernant le xhtml envoyé au format text/html, ce que je veux vous faire comprendre c'est qu'un doctype xhtml 1.1 ou xhtml 1.0 strict c'est du pareil au même ! Vous n'avez d'ailleurs qu'à lire les docs dont vous mettez l'adresse. Tiré de pourquoi envoyer du xhtml en text/html est néfaste :

La RFC2854 fait référence à un profile d’utilisation du XHTML compatible avec HTML 4.01. Ce profile est un mythe. Les documents qui suivent les règles de l’Annexe C ne sont pas des documents HTML 4.01 valides. Ils sont juste assez semblables pour qu’un analyseur de soupe de balises soit capable de les traiter de la même façon que la majorité du reste des pages sur le web.

ou

Les DOCTYPE XHTML ne sont pas des DOCTYPE HTML4 valides.

Ça ne s'applique donc pas au seul xhtml 1.1 mais à tous les doctypes xhtml, et à partir du moment où on utilise un parseur SGML le fait d'être en 1.1 plutôt qu'en 1.0 strict n'apportera pas plus d'erreurs.

La seule solution au final, pour les sites pas trop gros car c'est lourd à gérer, c'est bien de faire deux sites différents, un en xhtml et un en html.

Pour finir concernant validome.org :
http://www.validome.org/validate/?uri=h ... octypeAUTO

Donc arrêtez de faire peur à GizMecano.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

SB · Message par SB » 09 avr. 2006, 02:07

Sébastien Guillon a écrit :<?php
$mime = 'text/html'; // Type par défaut
if(isset($_SERVER['HTTP_ACCEPT']))
{
if(stristr($_SERVER['HTTP_ACCEPT'],'application/xhtml+xml') || empty($_SERVER['HTTP_ACCEPT']))
{
// On a trouvé "application/xhtml+xml", ou bien HTTP_ACCEPT
// est une chaîne vide (cas du validateur du W3C)

if(preg_match("/application\/xhtml\+xml;q=0(\.[1-9]+)/i", $_SERVER['HTTP_ACCEPT'], $matches))
{
// Si on trouve une valeur Q pour "application/xhtml+xml",
// on recherche aussi la valeur Q pour "text/html"

$xhtml_q = $matches[1];
if(preg_match("/text\/html;q=0(\.[1-9]+)/i", $_SERVER['HTTP_ACCEPT'], $matches))
{
$html_q = $matches[1];
// Si la valeur Q pour le XHTML est supérieure ou égale
// à celle du HTML, on utilise "application/xhtml+xml"
if($xhtml_q >= $html_q)
{
$mime = 'application/xhtml+xml';
}
}
}
else
{
// Aucune valeur Q n'a été trouvée
$mime = 'application/xhtml+xml';
}
}
}
else
{
// En cas d'absence totale de HTTP_ACCEPT
// (comportement anormal de l'Agent Utilisateur)
$mime = 'application/xhtml+xml';
}
?>

Ça fonctionne, cependant je me demande s'il ne manquerait pas un else $mime = 'application/xhtml+xml'; dans le cas où on trouve une valeur q pour application/xhtml+xml mais pas pour text/html. Est-ce seulement possible ?

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

calimo · Message par **calimo** » 09 avr. 2006, 10:05

SB a écrit :Concernant le xhtml envoyé au format text/html, ce que je veux vous faire comprendre c'est qu'un doctype xhtml 1.1 ou xhtml 1.0 strict c'est du pareil au même !

Dans ce cas, pourquoi ne pas utiliser xhtml 1.0 strict et pouvoir au moins utiliser l'attribut lang ?
Je suis désolé, mais ne pas définir la langue d'un document est un vrai problème !

SB a écrit :Ça ne s'applique donc pas au seul xhtml 1.1 mais à tous les doctypes xhtml, et à partir du moment où on utilise un parseur SGML le fait d'être en 1.1 plutôt qu'en 1.0 strict n'apportera pas plus d'erreurs.

Non, mais le fait d'être en 1.1

SB a écrit :La seule solution au final, pour les sites pas trop gros car c'est lourd à gérer, c'est bien de faire deux sites différents, un en xhtml et un en html.

Ou d'en faire un en vrai HTML

Au moins comme ça on est sûr que ça s'affiche correctement. Et de toutes façons, le prochain langage à sortir sera probablement le HTML 5.0, donc il sera plus facile d'y passer et de profiter de ses nouveautés (le xhtml 2.0, lui, n'est pas près de sortir

)

SB a écrit :Pour finir concernant validome.org :
http://www.validome.org/validate/?uri=h ... octypeAUTO

Donc arrêtez de faire peur à GizMecano.

Et toi, arrête de lui faire croire que tout est parfait

Le xhtml 1.1 envoyé en text/html (à IE par exemple) n'est effectivement pas recommandé (c'est sûr qu'après si on fait des pirouettes pour que ce soit envoyé correctement au validateur

)

SB · Message par SB » 09 avr. 2006, 12:31

calimo a écrit :
SB a écrit :Concernant le xhtml envoyé au format text/html, ce que je veux vous faire comprendre c'est qu'un doctype xhtml 1.1 ou xhtml 1.0 strict c'est du pareil au même !
Dans ce cas, pourquoi ne pas utiliser xhtml 1.0 strict et pouvoir au moins utiliser l'attribut lang ?
Je suis désolé, mais ne pas définir la langue d'un document est un vrai problème !

SB a écrit :Ça ne s'applique donc pas au seul xhtml 1.1 mais à tous les doctypes xhtml, et à partir du moment où on utilise un parseur SGML le fait d'être en 1.1 plutôt qu'en 1.0 strict n'apportera pas plus d'erreurs.
Non, mais le fait d'être en 1.1

Je ne vois pas où est le problème. J'utilise l'attribut lang pour le format xhtml 1.1 et c'est parfaitement compris bien qu'en effet dans l'esprit ce ne soit pas correct. Mais pour une raison simple, c'est qu'à partir du moment où la page est parsée en SGML, ce n'est pas sur l'attribut lang que le parseur va tiquer. Il le comprendra aussi bien avec un doctype xhtml 1.0 strict qu'avec un xhtml 1.1, et de toute façon, comme c'est si bien indiqué dans le document "pourquoi envoyer du xhtml...", quelque soit le doctype xhtml la page sera considéré comme du tag-soupe.
Je préfère garder le xhtml 1.1 même en text/html car la page est codée ainsi, non que j'en sois particulièrement fier, mais à partir du moment où tu as un peu plus bosser que la moyenne des webmestres pour faire quelque chose de correct et que le W3C te félicite et te propose une petite image à placer sur ton site et que tu le fais, autant être crédible. Sinon un internaute avec IE passe, voit marquer valide xhtml 1.1, regarde le code et voit xhtml 1.0 strict. Ben il pense que tu te fous de la gueule du monde.

calimo a écrit :
SB a écrit :Pour finir concernant validome.org :
http://www.validome.org/validate/?uri=h ... octypeAUTO

Donc arrêtez de faire peur à GizMecano.
Et toi, arrête de lui faire croire que tout est parfait
Le xhtml 1.1 envoyé en text/html (à IE par exemple) n'est effectivement pas recommandé (c'est sûr qu'après si on fait des pirouettes pour que ce soit envoyé correctement au validateur )

Je ne lui fais pas croire que tout est parfait, je démontre qu'envoyer du xhtml 1.1 au format text/html n'est pas pire qu'envoyer du xhtml 1.0 strict au même format et qu'il n'y gagnera rien à vouloir mettre deux doctypes différents puisqu'encore une fois pour un parseur SGML l'xhtml 1.1 et le 1.0 strict c'est du pareil au même.
Et le code php ne sert pas de pirouette pour valider le site auprès de validome dont je me moque totalement, il est là pour envoyer de l'application/xhtml+xml à ceux qui le supportent et du text/html aux autres.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Sébastien Guillon · Message par **Sébastien Guillon** » 09 avr. 2006, 13:59

SB a écrit :Pour finir concernant validome.org :
http://www.validome.org/validate/?uri=h ... octypeAUTO

Donc arrêtez de faire peur à GizMecano.

Je te soupçonne d'être de mauvaise foi, SB.

Le site http://suresnes.croix-rouge.fr est servi en tant que application/xhtml+xml, c'est donc normal qu'il soit validé par Validome. Ce n'est pas le cas du site de GizMecano (servi en tant que text/html) et donc il sera rejetté par Validome.

Concernant le xhtml envoyé au format text/html, ce que je veux vous faire comprendre c'est qu'un doctype xhtml 1.1 ou xhtml 1.0 strict c'est du pareil au même !

Non ce n'est pas pareil, au niveau du support de la modularisation par les agents utilisateurs, mais aussi au niveau de la DTD.

- l'attribut "lang" existe en XHTML 1.0 et est autorisé avec le DOCTYPE strict, mais il n'existe pas pas en XHTML 1.1

Tu peux donc avoir un document XHTML 1.0 strict valide qui devient invalide si tu te contentes de changer de DOCTYPE : ces 2 DOCTYPEs ne sont pas interchangeables.

Il faut également bien comprendre que XHTML 1.0 a une liste d'éléments et d'attributs, dont certains sont exclus de la DTD 'strict'. Mais ils font bel et bien partie de XHTML 1.0.
Ces éléments (ex. : 'FONT') et attributs (ex. : 'TARGET') présents en XHTML 1.0 disparaissent purement et simplement de XHTML 1.1, il faut donc faire attention.

Quant au type MIME approprié pour XHTML 1.1, il y a effectivement de la marge pour l'interprétation des textes officiels du W3C, mais le consensus chez la majorité des développeurs web est que si XHTML 1.0 peut être servi en tant que HTML (text/html), il est mauvais de servir du XHTML 1.1 de cette façon, son type MIME approprié étant application/xhtml+xml.

De plus les « avantages » du XHTML, tels que la possibilité de mélanger des éléments issus de différents espaces de nommage (ex. : inclure du MathML) ne sont possibles que si le XHTML est servi avec un type MIME XML (comme application/xhtml+xml).

Ça fonctionne, cependant je me demande s'il ne manquerait pas un else $mime = 'application/xhtml+xml'; dans le cas où on trouve une valeur q pour application/xhtml+xml mais pas pour text/html. Est-ce seulement possible ?

Ce serait très bizarre mais logiquement possible. Ça voudrait dire que text/html a une valeur implicite de 1 et même si la valeur de application/xhtml+xml était explicitement spécifiée comme 1 (ce qui serait anormal : pourquoi le faire pour un type et pas l'autre ?), text/html prendrait logiquement la tête, donc je pense que ce n'est pas utile.

Message envoyé avec : Opera/8.53 (Windows NT 5.1; U; fr)[/quote]

Sébastien Guillon · Message par **Sébastien Guillon** » 09 avr. 2006, 15:08

SB a écrit :Je ne vois pas où est le problème. J'utilise l'attribut lang pour le format xhtml 1.1 et c'est parfaitement compris bien qu'en effet dans l'esprit ce ne soit pas correct.

C'est surtout invalide. L'attribut "lang" n'existe pas en XHTML 1.1, le code que tu envoies à Internet Explorer est invalide, point final.

SB a écrit :Mais pour une raison simple, c'est qu'à partir du moment où la page est parsée en SGML, ce n'est pas sur l'attribut lang que le parseur va tiquer. Il le comprendra aussi bien avec un doctype xhtml 1.0 strict qu'avec un xhtml 1.1, et de toute façon, comme c'est si bien indiqué dans le document "pourquoi envoyer du xhtml...", quelque soit le doctype xhtml la page sera considéré comme du tag-soupe.

Là encore tu fais preuve de mauvaise fois et de méconnaissance du fonctionnement des agents utilisateurs. La page ne sera considérée comme de la soupe de balise que si le XHTML est incorrect ou servi comme du HTML (text/html), comme dans ton cas. Dans le cas d'une page XHTML bien formée et servie en tant que application/xhtml+xml, elle n'est pas traitée comme de la soupe de balise.

Ensuite tu te trompes si tu crois qu'un attribut "lang", inexistant en XHTML 1.1, doit être interprété comme l'attribut lang de HTML, dans une quelconque situation. Tu te reposes sur un mécanisme de gestion des erreurs propre à un navigateur en particulier, or tu ne testes pas la fonctionnalité, ni même l'agent utilisateur et encore moins la version. Tu fais comme si IE était le seul navigateur à qui tu serviras tes pages invalides et que donc elle seront toujours interprétées de la même façon. Et tu te trompes (pour un aperçu des différences de gestion des erreurs, vois : Tag Soup: Crazy parsing adventures et http://software.hixie.ch/utilities/js/live-dom-viewer/).

Or aucune norme ou spécification ne précise comment gérer le (X)HTML inavlide. Tu as donc tout simplement de la chance pour l'instant, mais compter sur la chance n'est pas une base solide à mon avis.

SB a écrit :Je préfère garder le xhtml 1.1 même en text/html car la page est codée ainsi, non que j'en sois particulièrement fier, mais à partir du moment où tu as un peu plus bosser que la moyenne des webmestres pour faire quelque chose de correct et que le W3C te félicite

Le validateur ne te félicite pas. Si tu as un doute, colle le code que tu envoies à IE dans http://validator.w3.org/fragment-upload.html et teste avec le validateur du W3C. Je te passe le suspense : INVALIDE.

SB a écrit :Sinon un internaute avec IE passe, voit marquer valide xhtml 1.1, regarde le code et voit xhtml 1.0 strict. Ben il pense que tu te fous de la gueule du monde.

Même erreur, présentée différemment. Si tu fais une négociation de contenu qui génère 2 versions valides (XHTML 1.1 et XHTML 1.0), ton visiteur peut valider chacune des versions qui lui sont servies, par exemple XHTML 1.1 (en application/xhtml+xml) avec Firefox et XHTML 1.0 (en text/html, suivant ou non les règles de compatibilité HTML) avec IE. Et dans chaque cas, le code pourra être valide.

La confusion vient du fait que pour toi négociation de contenu signifie uniquement changer de DOCTYPE, or, comme je l'ai déjà dit, les DOCTYPEs XHTML 1.0 et XHTML 1.1 ne sont pas interchangeables. Il s'agit de négociatin de contenu pas de négociatin de DOCTYPE. Tu devrais donc modifier le contenu en fonction du DOCTYPE et pas uniquement le DOCTPE en fonction d'un critère arbitraire (présence d'une chaîne dans l'en-tête HTTP ACCEPT).

Si tu utilises mon code PHP pour la détection des capacités de l'agent, le W3C pourra recevoir la version XHTML 1.1 et donc tes « efforts » ne seront pas perdus.

Message envoyé avec : Opera/8.53 (Windows NT 5.1; U; fr)

Geckozone

Du XHTML 1.1 envoyé au format text/html

Négociation de contenu XHTML 1.1 / XHTML 1.0

Re: Négociation de contenu XHTML 1.1 / XHTML 1.0

Re: Négociation de contenu XHTML 1.1 / XHTML 1.0

Re: Négociation de contenu XHTML 1.1 / XHTML 1.0

Re: Négociation de contenu XHTML 1.1 / XHTML 1.0

Re: Négociation de contenu XHTML 1.1 / XHTML 1.0

HTML 1.0 != XHTML 1.1

Soupe de balises et validité

Qui est en ligne ?