Je fais suivre ici un échange consécutif au commit 13110 qui repasse la dist en Transitional, parce que ça nous concerne tous et toutes :
Début du message réexpédié :
Début du message réexpédié :
Bonsoir tout le monde,
Je ne suis pas certain que "le retour en arrière" dû au passage de la
dist en Transitionnal soit un bon choix. Voici quelques idées en
faveur du doctype Strict qu'on utilisait avant.
Je pense qu'il ne faut pas voir la non validité d'une page comme une
sanction mais plutôt comme une indication que quelque chose cloche
dans le code de la page. Avec un docype Transitionnal certaines «
grossièretés » ne seront plus signalées par le validateur HTML.
Comme l'indiquait l'auteur de ce billet daté de 2006 voici la liste
des balises « interdites » lors de l'utilisation d'un doctype strict :
basefont, font, center, applet, dir, menu , isindex, s, strike, u
Et voici la liste des attributs non autorisés :
align, bgcolor, border, clear, color, compact, face, height, hspace,
type, vspace
http://www.456bereastreet.com/archive/200609/no_more_transitional_doctypes_please/
Dans cet article l'auteur indique qu'il ne voit que deux raisons de
continuer à utiliser un doctype transitionnal :
1 - lorsque le CMS qu'on utilise ne peut pas générer du code en accord
avec le doctype strict
2 - lorsque les pages du site utilisent des iframes
Pour le point 1, je crois que SPIP est capable de générer du code en
accord avec le doctype strict et je n'ai pas vu d'iframes dans la
dist.
A propos de l'attribut target : il m'arrive souvent de déconseiller
aux gens l'utilisation de cette « chose » pour forcer l'ouverture
d'une nouvelle fenêtre. Je ne vais pas tenter de vous convaincre du
fait que c'est mal et irrespectueux, on est tous d'accords sur ce
sujet, non ? De plus, le webmestre qui veut imposer cette horreur aux
visiteurs de son site peut très bien obtenir le même comportement avec
un bout de jQuery appliqué aux liens de class vilaine_popup ou
spip_out (il y a pas un plugin qui fait ça par hasard ?).
http://css.alsacreations.com/Bases-et-indispensables/DTD-comment-choisir
Sur cette page on peut lire ceci :
Utilisez de préférence XHTML1.0 Strict : c'est a priori la plus
adaptée à vos besoins et c'est la plus facile à utiliser et à
apprendre.
Si vous utilisez des iframe ou un attribut target, Utilisez XHTML1.0
transitional.
Une idée me vient en écrivant ce message. Comme le fait remarquer
Romy, les webmestres peuvent subir le fait que leurs rédacteurs
collent des balises dépréciées par un doctype strict dans le texte
d'un article. On pourrait filtrer ces balises et attributs dans les
fonctions typos ? Filtrage qu'on pourrait désactiver quand "la barre
typo SPIP anti-erreurs XHTML" sera dispo.
Autre vision du problème : on estime qu'une personne qui décide de
coller du html dans son article est responsable et sait ce qu'elle
fait.
Et pour finir avec un peu de tendresse : bises à toutes et à tous 
b_b
Je suis d'accord avec tout ce que tu dis, mais...
Mais explique-moi comment SPIP évite aux rédacteurs de faire la grossière erreur d'employer des <center> et autres choses qui sont monstrueuses en XHTML Strict (mais tolérées en Transitionnal) ?
Puisque <center> n'est pas tolérée en Strict, que propose SPIP pour palier à cette balise qui manque tant à nos chers amis les rédacteurs ?
Si passer en Strict n'impose que des restrictions, c'est non.
Pas mieux : pourquoi SPIP génère-t-il le code en bloc dans une balise <code> alors qu'il existe une balise <pre> spécialement pour ça ? (etc.)
Tant que SPIP n'explore mieux le potentiel des balises XHTML et ne propose pas de paliatifs aux besoins manquants pour éviter les erreurs, y'a pas à péter plus haut que son cul : on reste modestement en Transitionnal.
Le temps n'est pas encore venu de passer en Strict, ni sur le Web, ni dans SPIP.
Je pense beaucoup de mal de la DTD XHTML prétendument strict, mais qu'on puisse balancer des affirmations péremptoires sur ce qui est bon pour le Web et ce qui ne l'est pas me laisse tout de même pantois. Je crois que cette DTD dit seulement que les documents HTML qui l'utilisent ont renoncé à des balises dont l'effet est plus utilement assuré par les CSS associées. La question c'est de savoir si ne pas donner cette indication est plus grave que les erreurs que pourront introduire les rédacteurs non prévenus. Pour moi la réponse est non.
Committo,Ergo:Sum
Mettre un doctype strict sans donner aux redacteurs les moyens de le respecter est un dévoiement du standard.
Avant de vouloir imposer un doctype strict, soyons pedagogique pour les rédacteurs en les informant de leurs erreurs. Alors après seulement il sera temps de mettre du strict par défaut dans la dist.
Mais actuellement, la dist est faite de telle façon qu'un webmestre qui veut respecter ce qu'il annonce et repasser en transitional alors que la dist lui impose le strict, est obligé de forker tous les squelettes principaux pour les mettre en transitional.
C'est contre-productif, et va a l'encontre même de la réutilisation.
Je dis ça, mais amha la dist n'est de toute façon pas du tout architecturée pour être réutilisée en contexte de production.
Cédric
Cette double négation étant incompréhensible, je reprends.
Je pense qu'indiquer par un doctype xhtml strict que les squelettes de la dist sont écrits avec beaucoup de soin me parait une information indispensable à donner. Précisons dans la doc que les Webmestres doivent soit former leur rédacteur, soit passer en transitionnal s'il veulent éviter des erreurs de validation trop fréquentes, voilà tout. Mais ne nous prétendons pas moins "pro" que nous le sommes en réalité.
Committo,Ergo:Sum
un webmestre qui veut respecter ce qu'il annonce et repasser en transitional alors que la dist lui impose le strict, est obligé de forker tous les squelettes principaux pour les mettre en transitional.
C'est contre-productif, et va a l'encontre même de la réutilisation.
On parle de fork quand le code change en assumant une incompatibilité. Un jeu de squelettes étant justement prévu pour être remplaçable par un autre avec retour en arrière à tout moment, ce vocabulaire dramatique est ici trompeur. Et franchement, remplacer toujours la même première ligne dans 14 fichiers sur 36, quel travail énorme.
Je dis ça, mais amha la dist n'est de toute façon pas du tout architecturée pour être réutilisée en contexte de production.
??? alors que dire des dist des versions précédentes!
Committo,Ergo:Sum
La question c'est de savoir si ne pas donner cette indication est plus grave que les erreurs que pourront introduire les rédacteurs non prévenus. Pour moi la réponse est non.
Cette double négation étant incompréhensible, je reprends.
Je pense qu'indiquer par un doctype xhtml strict que les squelettes de la dist sont écrits avec beaucoup de soin me parait une information indispensable à donner. Précisons dans la doc que les Webmestres doivent soit former leur rédacteur,
Nous ne vivons pas dans le même monde... si tu voyais de quoi sont capables les rédacteurs, même formés...
Par ailleurs, comme je le disais dans mon autre mail, il est illusoire d'arriver à un résultat correct sans une information digne de ce nom dans l'espace privé, du type "Attention, vous avez saisi du contenu qui n'est pas joli joli..."
soit passer en transitionnal
ce qui oblige a reforker tous les squelettes, donc a perdre tout bénéfice de la réutilisation
s'il veulent éviter des erreurs de validation trop fréquentes, voilà tout.
Mais ne nous prétendons pas moins "pro" que nous le sommes en réalité.
Rien à voir. Le doctype n'est pas là pour récompenser la qualité des squelettes de la dist, mais pour être utilisé par les webmestres qui font avec leurs moyens.
Pour l'auto satisfaction, on a le mail d'annonce, dans lequel on devrait bien trouver une petite place pour ça !
Cédric
Je veux simplement dire que les personnes qui savent coder et maintenir un site en XHTML 1.0 Strict sont actuellement rares, tant dans SPIP que sur le Web. Ne présumez pas des capacités des utilisateurs.
si tu voyais de quoi sont capables les rédacteurs, même formés...
Je le sais parfaitement. Mais si on ne leur dit pas qu'il existe des règles, ils ne changeront jamais.
ce qui oblige a reforker tous les squelettes, donc a perdre tout bénéfice de la réutilisation
Encore une fois le mot "fork" est trompeur ici, et je ne vois pas de quelle réutilisation tu parles.
Committo,Ergo:Sum
Emmanuel Saint-James a écrit :
Encore une fois le mot "fork" est trompeur ici, et je ne vois pas de quelle réutilisation tu parles.
Je crois que ce qu'il veut dire, c'est que la dist n'étant pas faite avec des INCLURE et autres noisettes, changer la structure html, le gabarit de la page (que ce soit pour changer le doctype ou pour changer le nom de la div #entete par exemple) oblige à modifier tous les fichiers de la dist et à les recopier dans son répertoire squelettes.
C'est assez frustrant effectivement alors qu'on peut facilement faire une seule page pour le gabarit qui inclut les autres, et changer le doctype ne reviendrait qu'à surcharger qu'un seul fichier.
Cependant, je suis aussi partisan de laisser en doctype strict. Personne n'avait ralé jusque là pendant plus d'un an de ce changement, et la sortie de la version 2 va peut-être amener de nouveaux plugins pour gérer peut être mieux ces histoire de code pas propre écrits par les rédacteurs.
Cependant, ce n'est pas si évident car avec le code des modeles dans l'écriture des articles, ça risque de perturber les analyseurs de syntaxe.
Je qui par contre en désaccord sur le fait que la dist doit être le lieu d'expression de toutes les possibilités de SPIP. Etant donné qu'elle sert de base de construction, d'exemple pour de nombreux auteurs, elle devrait à mon sens être plus simple et plus facile d'emploi (justement avec des noisettes).
Maintenant, elle est comme elle est et ça ne m'empêche pas de dormir ! Loin de là.
D'ailleurs, ça va être l'heure 
Beaux rêves à tous.
...
Cependant, je suis aussi partisan de laisser en doctype strict. Personne
n'avait ralé jusque là pendant plus d'un an de ce changement, et la sortie
de la version 2 va peut-être amener de nouveaux plugins pour gérer peut être
mieux ces histoire de code pas propre écrits par les rédacteurs.Cependant, ce n'est pas si évident car avec le code des modeles dans
l'écriture des articles, ça risque de perturber les analyseurs de syntaxe.
tu peux analyser le résultat du texte interprété qui lui est censé
être strict, inconvénient c'est plus difficile de mettre en évidence
ce qui cloche
A+
Emmanuel Saint-James a écrit :
Encore une fois le mot "fork" est trompeur ici, et je ne vois pas de quelle réutilisation tu parles.
Cependant, je suis aussi partisan de laisser en doctype strict. Personne n'avait ralé jusque là pendant plus d'un an de ce changement
Peut-être parce qu'ils repassent en Transitional comme moi ? Peut-être parce qu'ils n'en savent rien et ne consultent pas les validateurs ? Ce qui n'empêche pas d'autres de se moquer, plus ou moins gentiment.
Du coup j'en profite pour râler dès maintenant sur le passage de l'espace privé en Strict : quand on voit l'archaïsme de notre interface, savoir qu'elle est codée en Strict... prête à rire (prenons le fil d'Ariane, tiens !). Mieux vaut rester en Transitional pour continuer tranquillement nos améliorations, puisque c'est à ça que sert ce DOCTYPE.
Je qui par contre en désaccord sur le fait que la dist doit être le lieu d'expression de toutes les possibilités de SPIP. Etant donné qu'elle sert de base de construction, d'exemple pour de nombreux auteurs, elle devrait à mon sens être plus simple et plus facile d'emploi (justement avec des noisettes).
La dist pédagogique c'est fini, faut oublier !
Celle-ci est bâtarde : un chouïa trop compliquée pour être exemplaire et pédagogique, mais pas assez optimisée pour être vraiment pratique, modulaire, déclinable. C'est un entre-deux. Deux point zéro.
Cependant, je suis aussi partisan de laisser en doctype strict. Personne n'avait ralé jusque là pendant plus d'un an de ce changement
DEUX ans
Peut-être parce qu'ils repassent en Transitional comme moi ? Peut-être parce qu'ils n'en savent rien et ne consultent pas les validateurs ? Ce qui n'empêche pas d'autres de se moquer, plus ou moins gentiment.
Qui ? Quelle autorité ont-ils ? Combien sont-ils sur les milliers d'utilisateurs de SPIP ?
Du coup j'en profite pour râler
Tu parles d'un profit. Il faudrait peut-être arrêter l'auto-flagellation et les retours en arrière. SPIP n'est pas parfait, ce n'est pas une raison pour se laisser intimider par les donneurs de leçons, car les autres CMS ne sont pas parfaits non plus. Avec l'article W3C Go Home, SPIP a eu suffisamment longtemps la réputation de se contre-foutre des standards du W3C; dire clairement qu'on n'est parafaitement capable de les respecter malgré leur insuffisance est selon moi prioritaire sur toute autre considération.
Committo,Ergo:Sum
cedric.morin@yterium.com a écrit :
Je dis ça, mais amha la dist n'est de toute façon pas du tout architecturée pour être réutilisée en contexte de production.
Une des raisons est, je crois, cette idée énoncée sotto-voce comme quoi la dist se devait d'être moche pour que les utilisateurs mettent les mains dans le cambouis. Ce qui, vous conviendriez avec moi, schlinge je judéochrétinisme à quelques encablures. Faire du downgrade va, amha, dans le même sens. Au lieu d'éduquer, puisqu'il s'agît de cela, par la beauté on veut le faire par la douleur.
A +
Luis
comme le suggère Matthieu, un <INCLURE{fond=inc-doctype}> (ou un #INCLURE) ne ferait qu'un fichier à modifier, ce qui ne règle pas la discussion
ensuite, si Spip ou un plugin peut analyser le code produit, il peut de lui-même modifier le doctype de la page en question (article par article...) si nécessaire
Claude
+1 et merci de l'avoir dit
pierre
ps : pourquoi ne pas proposer une dist configurable (cfg,php,autre) qui offrirait autant de points de vue que souhaité, nécessaire.... ?
Pour moi c'est typique de ce qu'on n'arrête pas de faire dans le core :
mettre en avant des trucs techniques dont on est fier au lieu de rendre service aux utilisateurs.
Que SPIP et la dist produisent du code de très bonne qualité, c'est un fait indéniable auquel je souscrit et je suis parfaitement d'accord qu'il ne faut pas se priver de le dire haut et fort.
Que pour autant on impose le DOCTYPE strict par défaut aux webmestres, par contre, ne leur rend pas service du tout.
Combien crois-tu qu'il y ait de personnes capables de *produire* et *maintenir* un site collaboratif en xhtml 1.0 strict en France (c'est plus facile pour un site autogéré) ?
Je peux t'assurer que ça ne se compte pas en milliers, et même peut être pas en centaines. Et si tu fais l'intersection avec ceux qui utilise SPIP, ça devient ridicule.
Pour les autres, on leur éloigne d'autant la perspective d'arriver à valider leur site correctement, renforçant par la même l'idée que les standards sont de toutes façon impossible à atteindre (combien de fois a-t-on déjà entendu ça de la part de webmestres qui découvraient que leur site générait des centaines d'erreurs dans le validateur du w3c).
Ceux qui voudront vraiment se donner de la peine (une minorité) changeront le DOCTYPE, en personnalisant l'ensemble des article.html, rubrique.html ...., ce qui les privera aussitôt du bénéfice des upgrades et corrections de bugs dans la dist de SPIP. Pour ceux-là on aura apporté que des complications.
Les autres (l'immense majorité) n'auront soit même pas conscience du problème, soit laisseront ça comme cela, ne sachant qu'y faire.
Avec pour résultat des centaines, voire milliers de site annonçant fièrement un doctype xhtml 1.0 strict et bardés d'erreurs.
Est-ce que ça va vraiment améliorer l'image que se font de SPIP ceux qui s'intéressent aux standards, aux normes, et qui sont intégrateurs ou prescripteurs ?
Absolument pas.
Est-ce que ça contribue à diffuser les standards ?
Pas plus.
La diffusion et le respect des standards ne se décrète pas d'un coup de DOCTYPE. Cela se construit patiemment avec de la formation en amont, et en mettant à disposition des outils que les webmestres et les rédacteurs peuvent utiliser au quotidien.
La dist en est un, mais elle ne suffit pas. Il manque cruellement de quoi accompagner les rédacteurs.
Pour conclure, je suis convaincu que fixer des objectifs trop ambitieux aux webmestres est contre-productif et a plus de chances de les dégoûter que de les encourager, et qu'au final, ça ne sert ni l'image de SPIP, ni la diffusion des standards. Pour ces deux points, que chacun montre l'exemple à son niveau, sur les sites qu'il maîtrise, ce sera bien plus constructif que de vouloir imposer à tous une exigence qu'on peine soi même à atteindre.
Allez, pour illustrer mes propos, des petits exemples, pas totalement pris au hasard (oui je sais, c'est un peu bas...) :
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.sauvonslarecherche.fr%2F&charset=(detect+automatically)&doctype=Inline&group=0
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.reinventer-luniversite.fr%2F&charset=(detect+automatically)&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.591
et même celui là, construit sur la dist (je plaide coupable) :
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.spip-contrib.net%2F&charset=(detect+automatically)&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.591
La seule qui travaille bien ici c'est Romy :
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.spip.net%2Ffr_rubrique91.html&charset=(detect+automatically)&doctype=XHTML+1.0+Transitional&group=0&user-agent=W3C_Validator%2F1.591
http://validator.w3.org/check?uri=http%3A%2F%2Fromy.tetue.net%2F&charset=(detect+automatically)&doctype=XHTML+1.0+Transitional&group=0&user-agent=W3C_Validator%2F1.591
Alors accordons lui le crédit de savoir de quoi elle parle ...
Cédric
La seule qui travaille bien ici c'est Romy :
whoa l'autre !! moi aussi je valide
-- Fil