Y a-t'il un CMS qui produit HTML propre

Le 24/02/2011 09:06, Olivier Masson a écrit :

Le 23/02/2011 15:50, Sergio a écrit :

En fait, la plupart des "bons" CMS modernes produisent du code valide,
pour peu qu'on lui fournisse des squelettes et plugins valide.

J'utilise SPIP, donc je plussoie, mais je pense que d'autres CMS sont
dans la norme...

Y compris, en effet, CMSMS, Wordpress, Contao, Pluxml...
Les plugins sont un autre problème.
Concernant Wordpress, tu peux très bien changer l'éditeur par défaut.
Mais tous les éditeurs WYSIWYG ont leurs défauts.

Toujours sur WP, tu as également des thèmes HTML5 dont le HTML5
boilerplate de Paul Irish.

Le problème des CMS est désormais, avant tout, la performance.

Re-bonjour et merci à vous tous pour les quelques suggestions.

Avec Wordpress j'ai réglé la performance avec W3 Total Cache qui fait
très bien son travail.

Concernant l'éditeur WYSIWYG c'est justement le problème principal. Pour
le moment les auteurs n'arrivent pas à utiliser titre pour titre et non
gras+souligné+(ah zut c'est petit, donc j'ajoute titre)

Le positionnement des images, ah les images..

"3200x2000 ça doit être bien comme taille non ?"
"Ah mais c'est long à charger"
"Mais pourquoi ça affiche pas l'image en grand quant je clique sur
l'image et que ça renvoie vers l'article ?"

Les images ancrées au texte, oui, mais les utilisateurs ne comprennent
pas le flottement du texte pas plus que le positionnement des images, et
pas la peine de parler des titre, légende et texte alternatif.

La notion de image et média dans l'éditeur est totalement incomprise.
"clique sur la première icône qui propose d'insérer un fichier"

Les retours à la ligne et coupures de séquences sont mal gérées avec
l'éditeur WYSIWYG, les insertions/suppressions ont tendance à casser les
séquences, même moi qui heureusement sait utiliser l'éditeur HTML, je
passe en mode HTML pour corriger des listes coupées en deux ou créer des
imbrications.

Les tableaux ? Une vaste blague, aucun éditeur convenable ne crée des
tableaux gérant les thead, tbody, th tr col colgroup, caption et encore
moins le regroupement des cellules et encore moins les CSS qui doivent
remplacer les colspan et autres extensions.

Et alors les copiés collés depuis Word ou même Libre Office laissent
plein de saloperies et inconsistances. Polices et autres joyeusetés.

HTML5, oui j'ai récupéré le thème HTML5 Toolbox et adapté pour en faire
un thème sur mesure. Le véritable problème ensuite ce sont les
extensions. Certaines feraient blanchir les cheveux tellement elles sont
écrites avec les pieds.

Bref, c'est pas seulement histoire de râler sur le travail des autres.
Après tout c'est du logiciel libre, distribué gratuitement. On fait avec
les moyens qu'on a et pour ce que ça coûte, c'est déjà très bien.

Mais ça fait quand même s'interroger sur la viabilité/faisabilité de
proposer des systèmes d'édition et CMS pour le web qui soient
accessibles à des utilisateurs sans compétence technique tout en
fournissant les garde-fous aptes à préserver l'extraordinaire rigueur du
HTML.

Un vrai problème avec le HTML, c'est justement la technicité de la
sémantique, de la structure et la syntaxe qui vient entraver le
processus d'édition candide, même avec les aides d'éditeurs WYSIWYG qui
ne font que mal-contourner le problème.

Il y a un conflit d'intérêts et de besoins entre :
- Ouvrir l'édition sur le web à un public aussi large que possible
et
- La compétence technique d'éditeur de contenu.

Avant le web, l'édition et l'impression étaient des métiers peu
accessibles et surtout très techniques, avec des règles précises et rigides.

--
Lea Gris

Le 24/02/2011 11:27, Lea Gris a écrit :

Avec Wordpress j'ai réglé la performance avec W3 Total Cache qui fait
très bien son travail.

En fait c'est surtout au niveau des requêtes SQL redondantes et les 36
scripts JS appelés un à un que ça me gonfle.

Concernant l'éditeur WYSIWYG c'est justement le problème principal. Pour
le moment les auteurs n'arrivent pas à utiliser titre pour titre et non
gras+souligné+(ah zut c'est petit, donc j'ajoute titre)
[...]

Je ne rencontre pas trop ce genre de problème. Ce qui est très gênant,
ce sont les balises qui ne sont pas supprimées alors qu'il n'y a plus de
contenu.
Sur un texte moult fois remanié, on se retrouve avec une soupe immonde
de <p>, <hn> et style en ligne. Faudrait donc que les éditeurs WYSIWYG

Les tableaux ? Une vaste blague, aucun éditeur convenable ne crée des
tableaux gérant les thead, tbody, th tr col colgroup, caption et encore
moins le regroupement des cellules et encore moins les CSS qui doivent
remplacer les colspan et autres extensions.

Ben non, ce sont des logiciels à part entière qui font tout ça (et le
reste), pas 50k de JS...

Et alors les copiés collés depuis Word ou même Libre Office laissent
plein de saloperies et inconsistances. Polices et autres joyeusetés.

Jamais essayé, mais la fonction de nettoyage du code importé depuis Word
ne fonctionne pas ?

HTML5, oui j'ai récupéré le thème HTML5 Toolbox et adapté pour en faire
un thème sur mesure. Le véritable problème ensuite ce sont les
extensions. Certaines feraient blanchir les cheveux tellement elles sont
écrites avec les pieds.

Certes, mais tout le monde (on pourrait être tenté de le regretter) peut
sortir son extension pour un CMS. Et tout le monde = beaucoup de mauvais
développeur.
C'est pourquoi je regrette qu'il n'y ait pas (ceci dit, je crois que ça
se fait sur Drupal et d'autres) des extensions certifiées et même
maintenues par les "core team".

Bref, c'est pas seulement histoire de râler sur le travail des autres.
Après tout c'est du logiciel libre, distribué gratuitement. On fait avec
les moyens qu'on a et pour ce que ça coûte, c'est déjà très bien.

Il y a bien pire, je t'assure, en produit commercial.

Mais ça fait quand même s'interroger sur la viabilité/faisabilité de
proposer des systèmes d'édition et CMS pour le web qui soient
accessibles à des utilisateurs sans compétence technique tout en
fournissant les garde-fous aptes à préserver l'extraordinaire rigueur du
HTML.

C'est pourquoi, entre autres, je ne propose que rarement des CMS. Et
d'ailleurs ce sont surtout les boites qui veulent faire un max de profit
qui proposent systématiquement un CMS à leurs clients : aucun dev à
faire, installé en 5 minutes, ajout de plugins qu'on va faire payer.
Mieux encore lorsqu'il s'agit de comiques inscrits à la MDA, qui
facturent du développement pour l'installation de CMS. Pitoyable et
illégal. Vivement que ce statut saute qu'ils comprennent un peu la vie.
Quant au client, il est ensuite ravi d'apprendre qu'il faut mettre à
jour son CMS... et ses plugins pas toujours compatibles.
Et sans parler de vitesse.

Avant le web, l'édition et l'impression étaient des métiers peu
accessibles et surtout très techniques, avec des règles précises et
rigides.

C'est pareil avec le web mais, comme maintenant en imprimerie numérique,
tout le monde s'en fout des contraintes.
Mais l'essentiel n'est-il pas quand même que tout le monde puisse
facilement créer du contenu sur le net ?

Le 24/02/11 11:27, Lea Gris a écrit :

Concernant l'éditeur WYSIWYG c'est justement le problème principal.

(...)

Les retours à la ligne et coupures de séquences sont mal gérées avec
l'éditeur WYSIWYG, les insertions/suppressions ont tendance à casser les
séquences, même moi qui heureusement sait utiliser l'éditeur HTML, je
passe en mode HTML pour corriger des listes coupées en deux ou créer des
imbrications.

Si on doit parfois le faire avec de *vraies* applications (comme
DreamWeaver pour n'en citer aucune) il ne faut quand même pas s'attendre
à ce qu'un éditeur de html fonctionnant en JavaScript soit à l'abri de
coquilles et scories laissées lors de "bricolages" rédactionnels
répétitifs et contradictoires, non ?

Les tableaux ? Une vaste blague, aucun éditeur convenable ne crée des
tableaux gérant les thead, tbody, th tr col colgroup, caption et encore
moins le regroupement des cellules et encore moins les CSS qui doivent
remplacer les colspan et autres extensions.

M'enfin !
quel néophyte sait comment est codé un tableau ?
quel néophyte a seulement l'idée de s'en inquiéter ?
quelle secrétaire s'inquiète du code définitif de son *.doc où elle a
sué sang et eau pour y insérer et mettre en forme un tableau repris 15
fois avant qu'il ne plaise au signataire ?
Tout le monde râle contre la chianterie de l'exercice !

Breffle, si tu veux des sites au code "propre" (ou pas trop pourri)
pourquoi confies-tu un CMS et son actualisation à du personnel pas formé ?

Lodel (http://www.lodel.org/) semble ne pas fonctionner avec un éditeur
web mais avec un *vrai* Traitement de Textes (Open Office)
<http://www.lodel.org/index376.html#heading2>
ce qui pour de l'édition électronique représente un plus vers la
simplicité et le respect d'une sémantique, me semble t-il.
Mébon ... pas essayé moi-même ...


--
Stéphane Moriaux avec/with iMac-intel

Le 24/02/2011 20:11, SAM a écrit :

Lodel (http://www.lodel.org/) semble ne pas fonctionner avec un éditeur
web mais avec un *vrai* Traitement de Textes (Open Office)
<http://www.lodel.org/index376.html#heading2>
ce qui pour de l'édition électronique représente un plus vers la
simplicité et le respect d'une sémantique, me semble t-il.
Mébon ... pas essayé moi-même ...

Connais pas, mais ton "respect d'une sémantique" m'a fait bondir !
Pour que le balisage soit correct en HTML, encore faut-il qu'il le soit
également dans le document OOo.
Or, personne (j'élimine les 0.5 ou 1%) n'utilise les styles dans OOo,
c'est exactement comme dans un éditeur HTML WYSIWYG : j'ajoute du gras
sur chacun de mes titres, je décale avec des espaces, j'aère avec des
saut de lignes, je fais même parfois des sauts de page de cette manière,
etc.
Même chez les secrétaire, donc c'est vaguement censé être le métier,
c'est une utilisation de néophyte.

Par contre, sur OOo, il y avait une extension (mais ça fait bien 3 ans
que je ne l'ai pas utilisée) qui permettait de nettoyer tous les styles
"en ligne" (elle supprimait tous ce qui avait été ajouté en plus des
styles de bases). Mais on sort peu à peu du sujet...

Le 25/02/11 10:58, Olivier Masson a écrit :

Le 24/02/2011 20:11, SAM a écrit :

Lodel (http://www.lodel.org/) semble ne pas fonctionner avec un éditeur
web mais avec un *vrai* Traitement de Textes (Open Office)
<http://www.lodel.org/index376.html#heading2>
ce qui pour de l'édition électronique représente un plus vers la
simplicité et le respect d'une sémantique, me semble t-il.
Mébon ... pas essayé moi-même ...

Connais pas, mais ton "respect d'une sémantique" m'a fait bondir !
Pour que le balisage soit correct en HTML, encore faut-il qu'il le soit
également dans le document OOo.
Or, personne (j'élimine les 0.5 ou 1%) n'utilise les styles dans OOo,
c'est exactement comme dans un éditeur HTML WYSIWYG : j'ajoute du gras
sur chacun de mes titres, je décale avec des espaces, j'aère avec des
saut de lignes, je fais même parfois des sauts de page de cette manière,
etc.
Même chez les secrétaire, donc c'est vaguement censé être le métier,
c'est une utilisation de néophyte.

Oui, oui, j'en avais bien parlé.
(combien utilisent la touche Tab ? ne serait-ce que ça :-( )
(ou même la règle pour le retrait de début de §, hein ? qui ?)

Par contre, sur OOo, il y avait une extension

Lodel semble en avoir eu faite une aussi ...

qui permettait de nettoyer tous les styles "en ligne"
(elle supprimait tous ce qui avait été ajouté en plus des
styles de bases).
Mais on sort peu à peu du sujet...

+/-
en effet, Lodel proposant un outil PHP de nettoyage des fichiers OOo, il
ne reste plus qu'à le tester ;-)

Mais ... on peut craindre le pire :
[cite]
C’est donc sur ce support (OOo) qu’il faut effectuer la première partie
du travail, celle qui consiste à identifier les différents éléments d’un
document : titre, intertitre, corps de texte, illustrations, légendes.
[/cite]

Ha! un billet du 18/01/2011 : <http://blog.lodel.org/164>

--
Stéphane Moriaux avec/with iMac-intel

Le 25/02/2011 13:10, SAM a écrit :

Le 25/02/11 10:58, Olivier Masson a écrit :

Le 24/02/2011 20:11, SAM a écrit :

Lodel (http://www.lodel.org/) semble ne pas fonctionner avec un éditeur
web mais avec un *vrai* Traitement de Textes (Open Office)
<http://www.lodel.org/index376.html#heading2>
ce qui pour de l'édition électronique représente un plus vers la
simplicité et le respect d'une sémantique, me semble t-il.
Mébon ... pas essayé moi-même ...

Connais pas, mais ton "respect d'une sémantique" m'a fait bondir !
Pour que le balisage soit correct en HTML, encore faut-il qu'il le soit
également dans le document OOo.
Or, personne (j'élimine les 0.5 ou 1%) n'utilise les styles dans OOo,
c'est exactement comme dans un éditeur HTML WYSIWYG : j'ajoute du gras
sur chacun de mes titres, je décale avec des espaces, j'aère avec des
saut de lignes, je fais même parfois des sauts de page de cette manière,
etc.
Même chez les secrétaire, donc c'est vaguement censé être le métier,
c'est une utilisation de néophyte.

Oui, oui, j'en avais bien parlé.
(combien utilisent la touche Tab ? ne serait-ce que ça :-( )
(ou même la règle pour le retrait de début de §, hein ? qui ?)

Par contre, sur OOo, il y avait une extension

Lodel semble en avoir eu faite une aussi ...

qui permettait de nettoyer tous les styles "en ligne"
(elle supprimait tous ce qui avait été ajouté en plus des
styles de bases).

> Mais on sort peu à peu du sujet...

+/-
en effet, Lodel proposant un outil PHP de nettoyage des fichiers OOo, il
ne reste plus qu'à le tester ;-)

Mais ... on peut craindre le pire :
[cite]
C’est donc sur ce support (OOo) qu’il faut effectuer la première partie
du travail, celle qui consiste à identifier les différents éléments d’un
document : titre, intertitre, corps de texte, illustrations, légendes.
[/cite]

Et enregistrer en SXW ...

Ha! un billet du 18/01/2011 : <http://blog.lodel.org/164>

Intéressant, le blog.lodel.org est édité en WordPress, ça donne une idée
de cd dont n'est pas capable Lodel.

Quant au site principal :

-- Lodel respecte les normes d'édition sur le Web (Dublin Core, RSS,
OAI) et produit des documents XML. --

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">

<http://validator.w3.org/check?uri=http%3A%2F%2Fwww.lodel.org>
Result: 13 Errors, 3 warning(s)

Ah ben non, zut, ça parlait que de XML, pas de XHTML ni de XML validé
par un quelconque schéma.

Et pour ce qui est des normes de publications scientifiques, si ce
n'était pas seulement pompeux, j'aurais pensé que les "normes"
étaientLaTeX voir DocBook ou des combinaisons de ces standards et les
nombreuses moulinettes pour traiter ces formats.

--
Lea Gris

Le 25/02/2011 13:10, SAM a écrit :

+/-
en effet, Lodel proposant un outil PHP de nettoyage des fichiers OOo, il
ne reste plus qu'à le tester ;-)

Si j'ai bien lu, .doc mais pas .docx et .sxw (OOo 1) et pas .odt.

Mais ... on peut craindre le pire :
[cite]
C’est donc sur ce support (OOo) qu’il faut effectuer la première partie
du travail, celle qui consiste à identifier les différents éléments d’un
document : titre, intertitre, corps de texte, illustrations, légendes.
[/cite]

Ce qui revient un peu au même que former à l'utilisation d'un éditeur
WYSIWYG online. Avec l'avantage d'apprendre à se servir d'un outil plus
générique.

Mais je me souviens que lors d'une formation que je faisais jadis, je
montrais comme exemple un copier-coller de OOo vers un éditeur HTML ;
toutes les balises étaient conservées, d'où l'intérêt de créer des
documents bien conçus.

Je viens de tester à nouveau en faisant un copier-coller d'un de mes
document OOo (donc bien fait ;p) dans l'éditeur par défaut de WP et ça
fonctionne parfaitement ! Tous les titres sont conservés et les
surcharges de style aussi, sans avoir fait quoique ce soit d'autre qu'un
"cmd/ctrl+v".
Même mes notes de bas de page se retrouvent en fin de document avec le
lien placés comme il convient.
Donc en fait, toutes ces discussions pour rien :) *Faites vos docs sous
OOo convenablement puis copiez-collez sous l'éditeur WYSIWYG*
Bon, ça ne fonctionne pas avec les images, mais là c'est normal pour des
tas de raisons, dont les contraintes en CSS.

Ha! un billet du 18/01/2011 : <http://blog.lodel.org/164>

Ah tiens, ça parle de OOo 3.2...

Olivier Masson a écrit :

Mais tous les éditeurs WYSIWYG ont leurs défauts.

Y a t-il une explication à ça ?

--
siger

Le 26/02/11 11:31, siger a écrit :

Olivier Masson a écrit :

Mais tous les éditeurs WYSIWYG ont leurs défauts.

Y a t-il une explication à ça ?

Complexité du clicodrome ? (tellement + simple directement dans le code)
La diversité des utilisateurs, des utilisations ?
La diversité de solutions pour une même mise en forme
(ou apparemment "même" à un instant t en un lieu L).

En remettant le contexte « Concernant Wordpress » :
- hétérogénéité des systèmes ?
- hétérogénéité des navigateurs ?

Gestion des balises html lors de modifs du "brouillon" ?
Comment va réagir l'éditeur suite à des actions un peu désordonnées ?
Pour faire simple :
<big><big>grand<small> moins grand</small></big></big>
ou
<big><big>grand</big></big> <big>moins grand</big>
ou
<big><big>grand</big> moins grand</big>
hein ?
Et, ça, sans s'occuper de positionnement, justification, couleur, éjenpasse.



<span style="font-size: 18pt;">
grand
<span style="font-size: 14pt;">moins grand</span>
</span>
<span style="">
normal (le wisiwig va supprimer ces balises devenues inutiles ?)
</span>

--
Stéphane Moriaux avec/with iMac-intel

SAM a écrit :

Le 26/02/11 11:31, siger a écrit :

Mais tous les éditeurs WYSIWYG ont leurs défauts.

Y a t-il une explication à ça ?

Complexité du clicodrome ? (tellement + simple directement dans le
code) La diversité des utilisateurs, des utilisations ?
La diversité de solutions pour une même mise en forme
(ou apparemment "même" à un instant t en un lieu L).

En remettant le contexte « Concernant Wordpress » :
- hétérogénéité des systèmes ?
- hétérogénéité des navigateurs ?

Gestion des balises html lors de modifs du "brouillon" ?
Comment va réagir l'éditeur suite à des actions un peu
désordonnées ? (...)

Quand on voit le code HTML d'une page simple, c'est quelque chose de
très basique, comment est-il possible qu'un éditeur WYSIWYG se trompe,
et aussi comment est-il possible que 2 navigateurs n'affichent pas la
même chose ?

On arrive à faire lire des DOC et XLS à OpenOffice, et on n'arriverait
pas à faire lire correctement du HTML à un navigateur ?

Simple guéguerre commerciale ?


--
siger