j'essaye d'avoir un doctype html5.
J'ai remplacé dans mes squelettes l'ancien doctype par celui de html5:
<!DOCTYPE html>
et dans la config de Spip, j'ai permis le HTML5.
Or, dans les sources de mes pages, je vois toujours :
<!-- SPIP CORRIGE --><!DOCTYPE html PUBLIC ‘-//W3C//DTD XHTML 1.0
Strict//EN’ ‘http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd’>
<!DOCTYPE html>
Le second DOCTYPE, c'est celui que j'ai précisé dans mon squelette.
Est ce qu'il y a un endroit où je pourrai faire sauter
temporairement cette "correction"?
hé hé, c'est le validateur de SPIP qui ne connait pas html5 et s'empresse de bourrer un autre doctype par dessus.
Il faut sans doute le désactiver, dans ton cas (ce qui n'est pas un mal, puisqu'il ralentit SPIP d'un facteur 3 environ)
* cedric.morin@yterium.com tapuscrivait, le 24/07/2010 11:58:
hé hé, c'est le validateur de SPIP qui ne connait pas html5 et s'empresse de bourrer un autre doctype par dessus.
Il faut sans doute le désactiver, dans ton cas (ce qui n'est pas un mal, puisqu'il ralentit SPIP d'un facteur 3 environ)
Où est-ce que tu vois que le validateur est activé ?
J'ai lu http://www.spip.net/fr_article3541.html
J'ai cherché dans le $xhtml et transformer_xml
À la lecture du code, ils ne me semblent pas actifs par défaut.
J'ai loupé quelque chose ?
hé hé, c'est le validateur de SPIP qui ne connait pas html5 et
s'empresse de bourrer un autre doctype par dessus.
Pourquoi est-ce que le validateur XML vérifie le doctype ?
C'est un concept de SGML, pas de XML.
C'est d'ailleurs précisément pour ça que le doctype de HTML5 ne
correspond pas à la structure habituelle : cette version de HTML est la
première qui n'essaie plus d'être compatible SGML. Du coup le doctype
est uniquement présent pour que les vieux navigateurs se mettent en
"standards mode", mais il n'est plus là en tant que doctype à
proprement parler.
Du coup je vois trois options (mais il en existe peut-être d'autres) :
- désactiver la vérification d'un doctype "bien fait" dans le validateur
XML en se disant que ce sont 2 choses différentes
- faire une exception dans _REGEXP_DOCTYPE pour accepter la chaîne
"<!DOCTYPE html>"
- demander aux webmestres d'utiliser :
<!DOCTYPE HTML SYSTEM "about:legacy-compat">
si elles/ils veulent que leur document soit accepté par le validateur
de SPIP.
La 3e option me semble inacceptable (et absurde), mais il fallait bien
la mentionner car elle marche...
Peut être on peut jouer à "qui-est-ce" ou sa version "devine quels plugins j'ai sur mon site" ?
La seule réponse qu'on peut te donner c'est : essai-erreur.
Avec une dichotomie tu peux t'en tirer en un nombre réduit d'itérations.
Après avoir bien evidemment vérifié que sans plugin tu n'as pas le problème, auquel cas le bug est dans ton dossier squelette.
Une quatrième c'est d'attendre que le W3C arrête de faire n'importe quoi.
Le validateur de SPIP est un validateur XML (car reposant sur SAX)
il est donc exclu de l'appliquer sur qqch qui n'est pas du XML,
par exemple HTML5 (cf. les liens envoyés par N. Krebs, avec qui je suis tout à fait d'accord pour cette fois).
Je suis surpris d'apprendre qu'il existe un plugin utilisant ce validateur.
D'un côté je suis content d'apprendre qu'il soit repris, mais d'un autre ça me laisse perplexe: c'est un outil d'aide à la mise au point qui doit être invoqué manuellement.
Le faire tourne en std c'est effectivement, comme le dit Cédric, faire baisser considérablement les performances du site sans raison.
Une quatrième c'est d'attendre que le W3C arrête de faire n'importe
quoi.
Ça fait des années que le travail sur HTML5 a commencé. Depuis le
début, le groupe de travail du W3C invite à contribution et discussions,
et plus particulièrement de la part d'auteurs de CMS, justement pour
avoir des retours sur ce genre de trucs.
Je tiens à clarifier que moi aussi je trouve ça trop naze de permettre
une syntaxe aussi laxiste (pas de guillemets, de balises fermantes, et
j'en passe), mais d'un autre côté c'est un peu facile de se pointer la
bouche en cœur quand la spec est en final draft et dire "ah mais ça
c'est nul". Et surtout, c'est trop tard, et on peut pas dire qu'on a
pas été invités (enfin "on"... perso j'étais pas encore dans SPIP ^^).
Le validateur de SPIP est un validateur XML (car reposant sur
SAX) il est donc exclu de l'appliquer sur qqch qui n'est pas du XML,
par exemple HTML5 (cf. les liens envoyés par N. Krebs, avec qui je
suis tout à fait d'accord pour cette fois).
Pour pondérer ça, je rappelle juste que HTML5 n'est pas *forcément* du
XML, mais il peut l'être (XHTML5), et donc redevient strict sur les
questions sus-citées. Indiquer qu'un document est du XHTML5 ou pas
dépend uniquement du Content-Type. Et comme la validation XML dans SPIP
est facultative, pas de problème : un dev web qui veut être strict peut
servir ses pages en xhtml, et faire tourner le validateur XML dessus.
Par contre, il faudrait juste que ce dernier accepte <!DOCTYPE html>,
qui je le répète n'est pas du tout une hérésie en termes de XML. Ce
n'est juste pas du SGML, mais le validateur s'appelle xml, pas xml+sgml.
Une quatrième c'est d'attendre que le W3C arrête de faire n'importe
quoi.
Ça fait des années que le travail sur HTML5 a commencé. Depuis le
début, le groupe de travail du W3C invite à contribution et discussions,
et plus particulièrement de la part d'auteurs de CMS, justement pour
avoir des retours sur ce genre de trucs.
Le pb c'est qu'avec une syntaxe aussi incohérente que celle de notre cher CMS,
on est bien mal placés pour donner des leçons.
C'est aussi vraisemblablement la raison pour laquelle Dreamweaver
a des interfaces avec Drupal, Joomla et Wordpress mais pas avec SPIP.
Il faudrait quand même qu'un jour on admette que certains choix initiaux de SPIP
nous plombent à beaucoup d'égards.
Je tiens à clarifier que moi aussi je trouve ça trop naze de permettre
une syntaxe aussi laxiste (pas de guillemets, de balises fermantes, et
j'en passe), mais d'un autre côté c'est un peu facile de se pointer la
bouche en cœur quand la spec est en final draft
Le W3C a été capable de faire des choses excellentes (IDL & SVG),
plutôt bonnes (XHTML 1.0 transitionnal et CSS2) et tellement mauvaises
qu'il a fini par les récuser de fait (XHTML 2). La responsabilité du chef
du groupe de travail est déterminante à chaque fois. Dans le cas de HTML5 il a été
clairement dénoncé comme un autocrate sourd et aveugle. A mon avis HTML5,
du moins dans sa définition actuelle, n'aura pas plus de succès que XHTML2.
Le validateur de SPIP est un validateur XML (car reposant sur
SAX) il est donc exclu de l'appliquer sur qqch qui n'est pas du XML,
par exemple HTML5 (cf. les liens envoyés par N. Krebs, avec qui je
suis tout à fait d'accord pour cette fois).
Pour pondérer ça, je rappelle juste que HTML5 n'est pas *forcément* du
XML, mais il peut l'être (XHTML5), et donc redevient strict sur les
questions sus-citées. Indiquer qu'un document est du XHTML5 ou pas
dépend uniquement du Content-Type. Et comme la validation XML dans SPIP
est facultative, pas de problème : un dev web qui veut être strict peut
servir ses pages en xhtml, et faire tourner le validateur XML dessus.
Par contre, il faudrait juste que ce dernier accepte <!DOCTYPE html>,
qui je le répète n'est pas du tout une hérésie en termes de XML. Ce
n'est juste pas du SGML, mais le validateur s'appelle xml, pas xml+sgml.
S'il s'agit juste de rajouter des "?" dans la Regexp utilisée par le validateur
pour repérer le Doctype, c'est faisable sans problème en effet.
Mais vu l'incohérence de HTML5 qui est parfois XML parfois non,
je ne vois pas très bien l'intérêt qu'il y aurait à le faire.
Mais je me trompe peut-être: ce nouveau raté du W3C me sort tellement par les yeux
que j'avoue ne pas vouloir regarder ce qu'on peut quand même en tirer.
Peut-être ai-je tort.
A mon avis HTML5, du moins dans sa définition actuelle,
n'aura pas plus de succès que XHTML2.
Ça c'est un peu du troll quand même.
S'il s'agit juste de rajouter des "?" dans la Regexp utilisée par le
validateur pour repérer le Doctype, c'est faisable sans problème en
effet. Mais vu l'incohérence de HTML5 qui est parfois XML parfois non,
je ne vois pas très bien l'intérêt qu'il y aurait à le faire.
D'une certaine manière, le problème n'est pas nouveau : les webmestres
ont toujours eu le choix d'écrire leurs pages soit en HTML laxiste,
soit en XML, ce qui me semble une bonne chose. La difficulté, dans notre
cas, réside dans le fait qu'on ne peut plus se baser sur le doctype pour
déterminer si un document est du XML ou pas.
D'un autre côté : est-ce que ça a déjà été un moyen
pérenne/normal/propre/générique/bla de déterminer ça ? Les normes
HTML4 / XHTML 1.0 se distinguent certes par ce critère, mais de manière
plus générale, détecter qu'un document est du XML dépend de critères
plus précis, notamment l'existence d'un attribut "xmlns" sur le tag de
niveau supérieur. On pourrait peut-être se dire qu'on utilise ça ?
Mais je me trompe peut-être: ce nouveau raté du W3C me sort tellement
par les yeux que j'avoue ne pas vouloir regarder ce qu'on peut quand
même en tirer. Peut-être ai-je tort.
Je ne sais pas. Quelque part les spec HTML ont toujours permis le choix
entre HTML laxiste et XHTML. Avec HTML5 ça reste le cas, d'une autre
manière certes (le content-type), mais pourquoi pas après tout.
Je suis surpris d'apprendre qu'il existe un plugin utilisant ce validateur. D'un côté je suis content d'apprendre qu'il soit repris, mais d'un autre ça me laisse perplexe: c'est un outil d'aide à la mise au point qui doit être invoqué manuellement.
Le faire tourne en std c'est effectivement, comme le dit Cédric, faire baisser considérablement les performances du site sans raison.
A ma connaissance, beaucoup le font tourner car c'est le meilleur moyen de "nettoyer" le code html généré par spip de toutes ses lignes blanches parasites et de l'indenter proprement...
Pour nettoyer les lignes blanches du html généré, il serait plus simple d'appliquer un filtre adhoc beaucoup plus rapide.
Pour indenter, il n'y a certes pas de meilleure solution.
La vrai question est à quel besoin cela répond ?
Depuis que firebug et autre plugin permettent de naviguer dans le DOM, je n'ouvre presque plus jamais la fenêtre du code source.
Le seul cas d'usage est quand je ne retrouve pas un élément dans le DOM, pour vérifier si il a été généré mais avec une erreur de syntaxe et est donc ignoré par le navigateur, ou si il manque à l'appel tout simplement. Et dans ce cas précis j'utilise la fonction 'chercher' du navigateur pour arriver directement au terme que je cherche.
Donc la question reste entière, pour quel besoin est-il judicieux d'avoir absolument un code html généré indenté et débarassé de ses lignes blanches ? Les deux besoins sont ils équivalents et de la même importance ?
Si ce besoin correspond à une utilisation en développement exclusivement quel est l'intérêt de laisser le validateur tourner sur le site en production ?
Ce qui est certain, c'est que si tu as ton validateur qui tourne sur ton site, la production de tes pages va aller juste 3 fois plus vite si tu le désactives.
a écrit : Je vois trois raisons (certes pas vitales, surtout maintenant que je sais à quel point le validateur grève les performances) : - réduire la taille des pages : surtout la suppression des lignes blanches et des espaces / tabulations qu’elles contiennent, mais une bonne indentation assure un nombre minimum de tabulations tout en gardant un source bien lisible - firebug n’affiche pas les commentaires html (enfin, chez moi) - SEO : dans la série des “on m’a dit” de cette discipline chamanique qu’est le “devine ce que google vient renifler ce soir”, le nombre de lignes blanches peut renvoyer le contenu plus bas dans la source, ce qui serait un facteur de mauvaise indexation… dans le doute… Bon, ça reste du fignolage, certes, je vais de ce pas désactiver le validateur. Par contre, si tu as une fonction non destructive pour du html qui supprime toutes les lignes vides automatiquement, je suis preneur ! A bientôt Simon
- réduire la taille des pages : surtout la suppression des lignes blanches et
des espaces / tabulations qu'elles contiennent, mais une bonne indentation
assure un nombre minimum de tabulations tout en gardant un source bien lisible
Pour ça, il suffit d'écrire des commentaires Spip : [(#REM)
]<BOUCLE_art(ARTICLES){id_rubrique}>[(#REM)
]#TITRE[(#REM)
]</BOUCLE_art>[(#REM)
]
- firebug n'affiche pas les commentaires html (enfin, chez moi)
C'est une option de Firebig... il faut l'activer.
- SEO : dans la série des "on m'a dit" de cette discipline chamanique qu'est le
"devine ce que google vient renifler ce soir", le nombre de lignes blanches peut
renvoyer le contenu plus bas dans la source, ce qui *serait* un facteur de
mauvaise indexation... dans le doute...
D'indexation, ce serait vraiment étonnant, en tout cas, un bon code
HTML ou XHTML améliore le référencement, vu que les informations
pertinantes sont mieux gérées par le webmestre (champs alt et title
sur les images, descriptions...)
Je viens aussi de commenter deux lignes dans mes_options.php et le
validateur est maintenant désactivé (pas activé en tout cas).
Je vois trois raisons (certes pas vitales, surtout maintenant que je sais à quel point le validateur grève les performances) :
- réduire la taille des pages : surtout la suppression des lignes blanches et des espaces / tabulations qu'elles contiennent, mais une bonne indentation assure un nombre minimum de tabulations tout en gardant un source bien lisible
Cà n'est pas le validateur, c'est l'indenteur (ils partagent beaucoup de code il est vrai). Dire que ça réduise la taille, ça n'est pas sûr: si l'original avait plus de lignes vides en trop que de tabulation en moins, le résultat sera plus gros.
Cela dit il est fondamentalement mauvais d'adopter la démarche "corriger au lieu de prévenir". Les squelettes ne devraient pas produire de mauvaise mise en page du source. Mais j'accorde que ça n'est pas facilité par la syntaxe des squelettes qui force une écriture alambiquée pour que le résultat HTML ne le soit pas.
Désolé de sembler radoter, c'est juste une autre raison qui me fait dire que cette syntaxe doit être abandonnée.
- firebug n'affiche pas les commentaires html (enfin, chez moi)
Cf réponse de Grégoire
- SEO : dans la série des "on m'a dit" de cette discipline chamanique qu'est le "devine ce que google vient renifler ce soir", le nombre de lignes blanches peut renvoyer le contenu plus bas dans la source, ce qui *serait* un facteur de mauvaise indexation
Si vraiment Google fait un truc aussi nul, c'est qu'il a entamé son déclin.
... a propos, quid novi Esj, sur ce gros chantier de redéfinition d'une grammaire spip ?
Si tu as avancé, ce serait bien de nous informer afin de préparer les esprits à une éventuelle transition,
et éviter les réticences comme pour la nouvelle balise de paramétrage (ex #REMPLIR).
A propos encore, je n'ai pas bien compris les difficultés que tu semblais trouver à la nommer.
Un simple #CONFIGURER me semble du meilleur aloi.
... a propos, quid novi Esj, sur ce gros chantier de redéfinition d'une grammaire spip ?
Si tu as avancé, ce serait bien de nous informer afin de préparer les esprits à une éventuelle transition,
Non, je ne reprendrais ce chantier que si je sens suffisamment de gens convaincus de l'intérêt de le mener à terme, et d'y contribuer d'une manière ou d'une autre car développer un bout de SPIP seul dans son coin est profondément contraire aux raisons qui me font y participer.
et éviter les réticences comme pour la nouvelle balise de paramétrage (ex #REMPLIR).
A propos encore, je n'ai pas bien compris les difficultés que tu semblais trouver à la nommer.
Un simple #CONFIGURER me semble du meilleur aloi.
Récemment j'ai proposé "#CONFIGURER_METAS" ce qui me semble mieux: on peut configurer beaucoup de choses, "#CONFIGURER" est trop ambigu. J'attendais les réactions.
