Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

1 view
Skip to first unread message

Lea Gris

unread,
Feb 20, 2011, 10:52:32 AM2/20/11
to
Mis-à-part Symphony-CMS qui traite de bout en bout du XML avec XSLT mais
qui est un poil compliqué pour moi et surtout les utilisateurs,
existe-t'il un CMS tournant dans PMA (histoire d'avoir le choix de
l'hébergement) qui soit en mesure de produire 100% du temps du code HTML
à syntaxe stricte ?

Par-ce que là, je me suis tournée vers Wordpress.org par-ce que la
gestion du contenu est simple pour les utilisateurs visés (enseignants
et TOS), mais le code produit par l'éditeur d'articles est une vaste
blague, sans même parler de ce que produisent les différentes
extensions. C'est à en perdre les cheveux…

À tout hasard est-ce que Joumla fait mieux ou ça sera le même topo avec
l'éditeur en ligne ?

Comment arrivez-vous à concilier la facilité de rédaction du contenu par
des utilisateurs inconscients et ignorants de toute notion de structure
sémantique (titres, paragraphes, listes, tableaux) qui cliquent sur les
icônes de mise-en forme au lieu de désigner des titres, et qui tapent
plusieurs fois sur <entrée> jusqu'à ce que le texte et les illustrations
se placent là où il veulent ?

Former les utilisateurs, c'est une utopie, merci, ça marche pas. Trop de
résistance et je les comprends, c'est pas leur métier, ils changent
souvent et ils en ont rien à faire…

Il faudrait une moulinette à documents DOC ou autre, capable de
décrypter les intentions structurelles à travers les différentes mises
en formes et autres bricolages à base d'espaces et retours-à-la-ligne.

Je rêve un peu : est-ce qu'il y a des solutions techniques à la paresse
et l'ignorance chronique et grégaire ?

--
Léa Gris

grenault

unread,
Feb 20, 2011, 10:53:00 AM2/20/11
to

docanski

unread,
Feb 20, 2011, 12:47:00 PM2/20/11
to
Alors que les eleveurs et agriculteurs empoisonnent toujours la
Bretagne, grenault ecrit ce qui suit en ce 20/02/2011 16:53 :

> Textpad ;-)

http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html !!!
Aurais-tu décidé de pourrir ce groupe de discussions ?
--
docanski

Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/

grenault

unread,
Feb 20, 2011, 1:57:08 PM2/20/11
to
Le 20/02/2011 18:47, docanski a écrit :
> Alors que les eleveurs et agriculteurs empoisonnent toujours la
> Bretagne, grenault ecrit ce qui suit en ce 20/02/2011 16:53 :
>
>> Textpad ;-)
>
> http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html !!!
> Aurais-tu décidé de pourrir ce groupe de discussions ?

Oh là ! Qu'est-ce qui se passe, mal dormi ou tu as oublié tes gouttes ?

A l'armée il y avait un bidasse comme moi vraiment très sympa (je parle
de lui) ; il aurait tout fait pour nous. On l'aimait bien et puis un
jour il a été nommé caporal. Du jour au lendemain, il est devenu un vrai
c.. ! Comme quoi le pouvoir peut détraquer des cerveaux fragiles...

Et tout ça parce que je me suis trompé de forum et que j'ai osé
plaisanter ici ?

Où va-ton ?

Guy

Olivier B

unread,
Feb 20, 2011, 2:45:18 PM2/20/11
to
Le 20/02/2011 19:57, grenault a écrit :
> Le 20/02/2011 18:47, docanski a écrit :
>> Alors que les eleveurs et agriculteurs empoisonnent toujours la
>> Bretagne, grenault ecrit ce qui suit en ce 20/02/2011 16:53 :
>>
>>> Textpad ;-)
>>
>> http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html !!!
[...]

>
> Et tout ça parce que je me suis trompé de forum et que j'ai osé
> plaisanter ici ?

Lis au moins le point 3a : tu verras que tes hypothèses n'ont pas un
rapport direct avec la remarque de docanski (ceci dit, t'as pas trop
de chance en ce moment).

--
Olivier B

<http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html>

grenault

unread,
Feb 20, 2011, 2:54:46 PM2/20/11
to
Le 20/02/2011 20:45, Olivier B a écrit :
> Le 20/02/2011 19:57, grenault a écrit :
>> Le 20/02/2011 18:47, docanski a écrit :
>>> Alors que les eleveurs et agriculteurs empoisonnent toujours la
>>> Bretagne, grenault ecrit ce qui suit en ce 20/02/2011 16:53 :
>>>
>>>> Textpad ;-)
>>>
>>> http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html !!!
> [...]
>>
>> Et tout ça parce que je me suis trompé de forum et que j'ai osé
>> plaisanter ici ?
>
> Lis au moins le point 3a : tu verras que tes hypothèses n'ont pas un
> rapport direct avec la remarque de docanski (ceci dit, t'as pas trop
> de chance en ce moment).
>

OK pour le 3a, c'est une mauvaise habitude que j'ai prise avec les
listes de discussion (les miennes) où on fait le contraire. Mais bon,
cela ne mérite pas une réaction aussi agressive...

Merci pour ton aide.

Pascal Poncet

unread,
Feb 21, 2011, 11:52:31 AM2/21/11
to
Le 20/02/2011 16:52, Lea Gris a écrit :
> Comment arrivez-vous à concilier la facilité de rédaction du contenu par
> des utilisateurs inconscients et ignorants de toute notion de structure
> sémantique (titres, paragraphes, listes, tableaux) qui cliquent sur les
> icônes de mise-en forme au lieu de désigner des titres, et qui tapent
> plusieurs fois sur <entrée> jusqu'à ce que le texte et les illustrations
> se placent là où il veulent ?

Bonjour,

J'ai fait un peu de recherches sur le sujet, car il m'intéresse
également (limité aux CMS dits "XML-based").

On trouve pas mal de CMS basés sur XML mais, curieusement, très peu
agissent réellement sur la sémantique du contenu à publier.
En résumé, la plupart ont simplement remplacé le stockage en base de
données, par un système de fichiers XML.
Les données sont souvent interrogées par une implémentation XQuery et
présentées en passant par des templates XSLT personnalisables.

Je préfèrerais pourtant utiliser XML pour qualifier le contenu éditable,
quitte à stocker le résultat dans un traditionnel SGBDR.
Ainsi, l'interface d'édition présenterait une liste de tags XML
personnalisés, que l'on pourrait par exemple sélectionner, puis placer
dans le contenu en cours avec les données correspondantes.
Par exemple, un tag "Paragraphe" permettrait d'insérer l'équivalent du
<P> du HTML avec son contenu textuel.

Pour l'instant, le plus proche de cette vision que j'ai pu trouver en
PHP est WebJaxe [http://media4.obspm.fr/outils/webjaxe/].
Malheureusement, il demande l'installation d'une appliquette Java dans
le navigateur, pour l'interface d'administration.
Autre inconvénient, à mon sens, l'instance XML est figée au travers d'un
langage baptisé XPAGES, ce qui doit également restreindre la
personnalisation de la template de présentation du contenu.
Je n'ai pas encore testé ni installé ce système, à suivre donc...

> Former les utilisateurs, c'est une utopie, merci, ça marche pas. Trop de
> résistance et je les comprends, c'est pas leur métier, ils changent
> souvent et ils en ont rien à faire…

Avec ce type de solution, il faudra quand même qu'ils comprennent le
sens de chacun des tags disponibles, puisqu'ils ne manipuleront plus
directement de balises HTML.
A noter qu'on trouvait déjà un système assez proche avec le BBCode !
Voir [http://fr.wikipedia.org/wiki/BBCode]
Ce que je crains, c'est que ces systèmes soient ressentis comme une
restriction en terme de liberté de mise en forme des contenus (et ça
l'est, d'une certaine manière).

> Il faudrait une moulinette à documents DOC ou autre, capable de
> décrypter les intentions structurelles à travers les différentes mises
> en formes et autres bricolages à base d'espaces et retours-à-la-ligne.

Pas sûr que ce soit possible, sauf à créer une usine à gaz.
Aujourd'hui les documents produits par les applications de bureautique
sont nativement en XML, et cela n'empêche pas les travers, à commencer
par le défaut de ne pas utiliser les styles de mise en forme globale.

--
Cordialement,
Pascal

Message has been deleted

Stéphane Santon

unread,
Feb 23, 2011, 9:13:24 AM2/23/11
to
Bonjour,

J'utilise SPIP car :
- C'est moi qui écrit le squelette de HTML produit, donc il est aussi
propre que je le souhaite
- il est très orienté sémantique à tel point qu'on lui reproche son
austérité d'interface privé (eh oui, pas possible de mettre des
couleurs, des soulignés, ...)
- il tourne sur des plateformes très standard avec des bases aussi
variées que MySQL, Postgre, sqlLite
- Il est utilisé par de nombreux sites de presse, de commerce,
d'institutions.

Côté Dev, on peut créer de nouveaux éditoriaux
Il doit avoir quelques moulinettes DOC

Demander sur cette liste très active :
http://listes.rezo.net/mailman/listinfo/spip


Lea Gris a écrit :


> Mis-à-part Symphony-CMS qui traite de bout en bout du XML avec XSLT mais qui
> est un poil compliqué pour moi et surtout les utilisateurs, existe-t'il un
> CMS tournant dans PMA (histoire d'avoir le choix de l'hébergement) qui soit
> en mesure de produire 100% du temps du code HTML à syntaxe stricte ?
>
> Par-ce que là, je me suis tournée vers Wordpress.org par-ce que la gestion du
> contenu est simple pour les utilisateurs visés (enseignants et TOS), mais le
> code produit par l'éditeur d'articles est une vaste blague, sans même parler
> de ce que produisent les différentes extensions. C'est à en perdre les
> cheveux…
>
> À tout hasard est-ce que Joumla fait mieux ou ça sera le même topo avec
> l'éditeur en ligne ?
>
> Comment arrivez-vous à concilier la facilité de rédaction du contenu par des
> utilisateurs inconscients et ignorants de toute notion de structure
> sémantique (titres, paragraphes, listes, tableaux) qui cliquent sur les
> icônes de mise-en forme au lieu de désigner des titres, et qui tapent
> plusieurs fois sur <entrée> jusqu'à ce que le texte et les illustrations se
> placent là où il veulent ?

--
Stéphane

Jeune Chambre Economique de Saintes *** http://www.jce-saintes.org
Agitateurs d'idées... accélérateurs de talents !

BTS Electrotechnique *** http://enselec.santonum.eu


Sergio

unread,
Feb 23, 2011, 9:50:08 AM2/23/11
to
Le 23/02/2011 15:13, Stéphane Santon a écrit :
> Bonjour,
>
> J'utilise SPIP car :
> - C'est moi qui écrit le squelette de HTML produit, donc il est aussi propre que je le souhaite
> - il est très orienté sémantique à tel point qu'on lui reproche son austérité d'interface privé (eh oui, pas possible de mettre des
> couleurs, des soulignés, ...)
> - il tourne sur des plateformes très standard avec des bases aussi variées que MySQL, Postgre, sqlLite
> - Il est utilisé par de nombreux sites de presse, de commerce, d'institutions.

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...

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Olivier Masson

unread,
Feb 24, 2011, 3:06:53 AM2/24/11
to
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.

Lea Gris

unread,
Feb 24, 2011, 5:27:20 AM2/24/11
to

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

Olivier Masson

unread,
Feb 24, 2011, 10:58:37 AM2/24/11
to
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 ?

SAM

unread,
Feb 24, 2011, 2:11:46 PM2/24/11
to
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

Olivier Masson

unread,
Feb 25, 2011, 4:58:56 AM2/25/11
to
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...


SAM

unread,
Feb 25, 2011, 7:10:41 AM2/25/11
to
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>

Lea Gris

unread,
Feb 25, 2011, 7:45:27 AM2/25/11
to

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

Olivier Masson

unread,
Feb 25, 2011, 8:00:09 AM2/25/11
to
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...

siger

unread,
Feb 26, 2011, 5:31:15 AM2/26/11
to
Olivier Masson a écrit :

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

Y a t-il une explication à ça ?

--
siger

SAM

unread,
Feb 26, 2011, 6:55:07 AM2/26/11
to
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>

siger

unread,
Feb 26, 2011, 7:01:34 AM2/26/11
to
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

Stéphane Santon

unread,
Feb 26, 2011, 10:51:18 AM2/26/11
to
Bonjour,

siger a écrit :


>> Mais tous les éditeurs WYSIWYG ont leurs défauts.
> Y a t-il une explication à ça ?

Envie exagérée de développement commercial.

OpenOffice 1.x avait fait un énorme progrès face à Word pour faciliter
l'accès à la sémantique avec des boutons et des fonctionnalités bien
pensées.

Rien que dans la gestion des tableaux, il y avait 3 boutons qui
définissaient le mode d'ajustement automatique des largeurs de colonnes
de tableau. Lors des formations à OpenOffice que j'ai données dans ma
boite (prétexte basculement de Word à OOo mais en fait c'est une vrai
formation générique au traitement de texte qu'il fallait faire), ils
ont découvert des fonctionnalités "épatantes" !
OpenOffice 2 : Et CRAC ! Ils ont voulu ressembler à Microsoft pour
prendre du marché, et OOo a perdu une grande part de son intérêt.

Il faudrait créer un traitement de texte bien plus léger, mais
intelligent (pour l'utilisateur), qui supprimerait tout accès à une
mise en forme manuelle.
Si ça mettait naturellement en évidence l'intérêt des styles, beaucoup
s'y mettraient.

Un projet libre pour 2017 ??

Mickaël Wolff

unread,
Feb 26, 2011, 9:24:30 PM2/26/11
to
On 26/02/11 12:01, siger wrote:
> 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,

Ce n'est pas une question de se tromper. Ceci dit, si c'est si
simple, je t'encourage à écrire l'outil magique :)


> et aussi comment est-il possible que 2 navigateurs n'affichent pas la
> même chose ?

Parce que la norme ne défini pas tout les comportements, et que
certains points peuvent être interprétés. Il faut aussi noter que, même
si l'ensemble des navigateurs affichent grossièrement de la même
manière, il est possible d'avoir un autre traitement de l'information.

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

Merci, j'ai bien rit. Mes voisins ne te remercient pas ;)
OpenOffice.org et consorts tentent de rendre au mieux un document dont
les spécifications sont tenues secrète. Et c'est loin d'être parfait. De
plus, il ne faut pas oublier qu'effectuer le rendu d'un document, c'est
quelque chose de complexe car il est impossible d'obtenir un rendu
identique d'un ordinateur à l'autre, sans connaître ces caractéristiques
matérielles et logicielles.

Olivier Masson

unread,
Feb 28, 2011, 4:00:11 AM2/28/11
to
Le 26/02/2011 13:01, siger a écrit :

>
> 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,

Ah ? C'est si basique ? Pourquoi alors la plupart des pages sont mal
écrites ?
Avec un éditeur WYSIWYG, on doit créer de l'HTML et des CSS. Va lire les
spec CSS3 et HTML4. Lire vraiment. Puis suis une petite formation sur la
sémantique web, puis sur l'accessibilité. Et tu reviens nous dire que
tout cela est simplissime et que tu vas vite nous pondre une éditeur
digne de ce nom (donc doté d'IA à mon avis.)

> et aussi comment est-il possible que 2 navigateurs n'affichent pas la
> même chose ?

Alors que c'est pourtant si simple :)

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

Heureusement que les navigateurs lisent mieux l'HTML que OOo ne lit les
doc et xls un tant soit peu complexes.

>
> Simple guéguerre commerciale ?
>
>

Heu non, difficultés techniques. Microsoft avaient des années de retard,
ils ont réalisé un travail énorme, avec un paquet d'ingé derrière, juste
pour mettre IE9 presque à niveau.
Il sera tout de même à la ramasse, mais il deviendra enfin un navigateur
dit moderne.
Comme HTML5 final est prévu pour 2014, ils ne sont finalement pas si en
retard. Mais les concurrents sont très en avance, ce qui donne forcément
envie...
Mais tu peux toujours leur donner un coup de main, puisque c'est si
trivial ;)

Pierre Goiffon

unread,
Feb 28, 2011, 9:27:39 AM2/28/11
to
On 24/02/2011 11:27, Lea Gris wrote:
> 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)

Bonjour,

Je crois que les éditeurs texte riche sont un problème pour tout le monde :)

Vous ne précisez pas vraiment dans quel contexte (volume des
rédactionnels, besoins de mise en forme, ...) vous les utilisez ?

De mon côté, j'ai été soumis à 2 utilisations lors de mon précédent
poste et l'actuel : la première pour un site de contenu, et aujourd'hui
pour un produit de création de questionnaire (pour aller vite). Les deux
cas sont assez aux antipodes : relativement long contenu qui doit
s'insérer avec harmonie dans une charte graphique bien définie, mais qui
peut nécessiter l'ajout de média / notes / infobulles / liens / ...,
contre contenus plutôt courts mais devant pouvoir se plier à toutes les
fantaisies de mise en forme. La leçon que j'en tire est qu'il faut
limiter au minimum la casse :) En gros, quand on sait que l'on doit
respecter un cadre certain de mise en forme, ne proposer que ce qui est
défini par le site, et éventuellement un peu de gras. Au besoin on
complète avec des classes css mais qui seront définies par les
développeur en accord avec le journaliste / rédacteur / ... Et bien
considérer la nécessité de mise en forme particulière : rendre un
éditeur texte riche optionnel (cad un simple textarea par défaut, qui
convient dans la plupart des cas).
C'est facile à dire, moins à mettre en place... et il y a une infinité
de contextes différents !

En tout cas on peut se féliciter de la souplesse des RTE principaux
(Tiny MCE, CK Editor) qui s'est grandement améliorée. Pour les prb de
fonctionnement évidemment, il y a du chemin avant de pouvoir être
comparer avec des solutions plus lourdes (de "vrais" éditeurs html que
l'on installe sur son poste je veux dire) mais quand même, ça n'est pas
rien de pouvoir proposer une interface d'édition avec mise en forme
directement dans le navigateur !

siger

unread,
Feb 28, 2011, 6:23:15 PM2/28/11
to
Olivier Masson a écrit :

Mickaël ayant fait une réponse similaire, ma réponse va aux 2 :-)

> Le 26/02/2011 13:01, siger a écrit :

>> 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,

> Ah ? C'est si basique ? Pourquoi alors la plupart des pages sont
> mal écrites ?

C'est ma question.

> Avec un éditeur WYSIWYG, on doit créer de l'HTML et des CSS. Va
> lire les spec CSS3 et HTML4. Lire vraiment. Puis suis une petite
> formation sur la sémantique web, puis sur l'accessibilité. Et tu
> reviens nous dire que tout cela est simplissime et que tu vas vite
> nous pondre une éditeur digne de ce nom (donc doté d'IA à mon
> avis.)

J'ai parlé d'une page simple. Beaucoup ont fait ça avec un éditeur de
texte. J'ai souvenir de texte dans un tableau dont la largeur est
proportionnele à la page, fait avec Nvu, et bien il fallait aller dans
le code pour mettre un truc compatible avec IE, un truc tout simple.

Je me souviens de Word et de OOo : une page, que du texte et un peu de
gras et choix de police, passé en HTML puis au validateur : des tas
d'erreurs.

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

> Heureusement que les navigateurs lisent mieux l'HTML que OOo ne
> lit les doc et xls un tant soit peu complexes.

À niveau de complexité égal ? (s'il est possible de comparer)

Dans le même genre de question, je me demande pourquoi on reçoit des
courriels avec des hiéroglyphes et pourquoi un simple TXT n'est pas
compatible entre Mac et Windows ou de Windows à Windows, ou le même
Windows, avec la puissance qu'on a dans nos ordinateurs, confirmé par
ce que sont capables de faire certains logiciels !

C'est comme les webmails qui marchent souvent mal, les courriels qui
n'arrivent pas à cause de blacklistages de FAI ou d'hébergeurs ou
d'autres raisons.

Le point commun de tout ça ? C'est que j'ai plutôt l'impression que
l'efficacité de la communication n'est pas le soucis premier de
nombreux développeurs (ou de leur hiérarchie) qui semblent préférer le
joli à l'efficace et qui avancent toujours plus loin dans la
complexité, les fonctions supplémentaires, sans faire marcher
correctement ce qu'ils ont fait avant.


--
siger

Paul Gaborit

unread,
Mar 1, 2011, 3:01:43 AM3/1/11
to

À (at) 28 Feb 2011 23:23:15 GMT,
siger <guin...@hic.invalid> écrivait (wrote):
[...]

> Dans le même genre de question, je me demande pourquoi on reçoit des
> courriels avec des hiéroglyphes et pourquoi un simple TXT n'est pas
> compatible entre Mac et Windows ou de Windows à Windows, ou le même
> Windows, avec la puissance qu'on a dans nos ordinateurs, confirmé par
> ce que sont capables de faire certains logiciels !

Rajoutez Linux, BSD et autres Unixeries dans votre liste et le tableau
sera complet.

En 1961, lors de l'invention de l'ASCII, certains avaient osé proposer
un codage intégrant tous les caractères mondiaux. Ils n'ont pas été
écoutés ! Croyez-vous que c'était pour économiser la mémoire ? Non !
C'était tout simplement prévu pour justifier la guégerre ASCII/EBCDIC et
surtout celle qui allait suivre. La preuve ? Un peu plus tard, il y a
eu des réunions secrètes entre AT&T, Apple, Microsoft, IBM (et d'autres
sans doute) pour réussir à se mettre en désaccord sur les codages :
MacRoman, CP12xx, ISO-8859-x, etc.

Plus récemment encore, quelques-uns ont osé proposer l'UTF-8 dans l'idée
de tout unifier. Heureusement, d'autres ont réagi rapidement et ont créé
UTF-16(BE/LE) et UTF-32(BE/LE) afin de brouiller les pistes.

> C'est comme les webmails qui marchent souvent mal, les courriels qui
> n'arrivent pas à cause de blacklistages de FAI ou d'hébergeurs ou
> d'autres raisons.

C'est vrai ça : j'envoie régulièrement un mail à des millions de
personnes et ils sont nombreux à ne pas le recevoir, entre autres, à
cause des blacklists. Pourtant, je suis sûr que ma petite pilule bleue
pourrait les intéresser... tout comme les propositions financières de
mon ami qui cherche toujours quelqu'un pour récupérer son héritage.

> Le point commun de tout ça ? C'est que j'ai plutôt l'impression que
> l'efficacité de la communication n'est pas le soucis premier de
> nombreux développeurs (ou de leur hiérarchie) qui semblent préférer le
> joli à l'efficace et qui avancent toujours plus loin dans la
> complexité, les fonctions supplémentaires, sans faire marcher
> correctement ce qu'ils ont fait avant.

Joli ? C'est vite dite ça ! Il y a quand même de nombreux softs qui sont
très moches (si les développeurs avaient des qualités de graphistes, ils
ne gâcheraient leur vie à manipuler des bits). Quant à l'efficacité,
c'est bien connu : ce sont les informaticiens qui rendent volontairement
tout compliqué et qui introduisent les bugs afin de justifier leur
salaire et le prix des formations que leurs patrons "offrent" à leurs
clients.

J'oubliais : ;-)

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Mickaël Wolff

unread,
Mar 1, 2011, 4:24:05 AM3/1/11
to
On 01/03/11 08:01, Paul Gaborit wrote:

> En 1961, lors de l'invention de l'ASCII, certains avaient osé proposer
> un codage intégrant tous les caractères mondiaux.

Tu sais qu'il y en a beaucoup qui ne vont pas comprendre ton ironie
parce que ton smiley est perdu tout en bas ?

yamo'

unread,
Mar 1, 2011, 4:34:03 AM3/1/11
to
Salut,

Paul Gaborit a tapoté, le 01/03/2011 09:01:


> Joli ? C'est vite dite ça ! Il y a quand même de nombreux softs qui sont
> très moches (si les développeurs avaient des qualités de graphistes, ils
> ne gâcheraient leur vie à manipuler des bits). Quant à l'efficacité,
> c'est bien connu : ce sont les informaticiens qui rendent volontairement
> tout compliqué et qui introduisent les bugs afin de justifier leur
> salaire et le prix des formations que leurs patrons "offrent" à leurs
> clients.


Quand tu vois certains tuto qui trainent sur internet depuis des années
avec une petite erreur bien planquée qui te fait perdre des cheveux que
tout le monde a corrigé avant toi mais personne ne l'as dit tu as des
fois des idées de conspirations :)
Mais au moins c'est formateur :P


Pour revenir au sujet, c'est pas un CMS mais quelqu'un ici a déjà
utilisé scenari et qu'en pense t'il?
<http://www.framasoft.net/article4477.html>
<http://scenari-platform.org/projects/scenari/fr/demo/co/>

--
Stéphane

<http://pasdenom.info/fortune/>

Olivier Masson

unread,
Mar 1, 2011, 6:18:18 AM3/1/11
to
Le 01/03/2011 00:23, siger a écrit :

> Le point commun de tout ça ? C'est que j'ai plutôt l'impression que
> l'efficacité de la communication n'est pas le soucis premier de
> nombreux développeurs (ou de leur hiérarchie) qui semblent préférer le
> joli à l'efficace et qui avancent toujours plus loin dans la
> complexité, les fonctions supplémentaires, sans faire marcher
> correctement ce qu'ils ont fait avant.
>
>

Je pourrais répondre longuement à chaque point évoqué, mais je n'en ai
pas le temps.
Disons que sous une apparente simplicité, que tu crois voir partout, sa
cache une réelle complexité qui, assez souvent, est justifiée.

Tonton Th

unread,
Mar 1, 2011, 7:34:50 AM3/1/11
to
On 03/01/2011 12:23 AM, siger wrote:

> J'ai parlé d'une page simple. Beaucoup ont fait ça avec un éditeur de
> texte. J'ai souvenir de texte dans un tableau dont la largeur est
> proportionnele à la page, fait avec Nvu, et bien il fallait aller dans
> le code pour mettre un truc compatible avec IE, un truc tout simple.

En général, dans ce genre de cas, ce n'est pas la faute de l'éditeur.

--
Ma coiffeuse est formidable - http://sonia.buvette.org/


siger

unread,
Mar 1, 2011, 5:18:22 PM3/1/11
to
Paul Gaborit a écrit :


> siger <guin...@hic.invalid> écrivait (wrote):
> [...]
>> Dans le même genre de question, je me demande pourquoi on reçoit
>> des courriels avec des hiéroglyphes et pourquoi un simple TXT
>> n'est pas compatible entre Mac et Windows ou de Windows à
>> Windows, ou le même Windows, avec la puissance qu'on a dans nos
>> ordinateurs, confirmé par ce que sont capables de faire certains
>> logiciels !

> Rajoutez Linux, BSD et autres Unixeries dans votre liste et le
> tableau sera complet.
>

> En 1961, (...)

Ce que je voulais dire est que quand on ouvre un TXT avec un éditeur de
texte je m'attend à ce qu'il reconnaisse le jeu de caractères.

Ne pas pouvoir communiquer entre 2 ordinateurs, et même sur le même
ordinateur avec de simples fichiers TXT me semble une abération dans le
principe. On voit qu'en HTML c'est pas mieux, il reste le PDF, et
encore c'est pas du 100%, c'est pauvre quand on voit les possibilités
des ordinateurs et des logiciels.

>> C'est comme les webmails qui marchent souvent mal, les courriels
>> qui n'arrivent pas à cause de blacklistages de FAI ou
>> d'hébergeurs ou d'autres raisons.

> C'est vrai ça : j'envoie régulièrement un mail à des millions de
> personnes et ils sont nombreux à ne pas le recevoir, entre autres,
> à cause des blacklists. Pourtant, je suis sûr que ma petite pilule
> bleue pourrait les intéresser...

Je me suis mal exprimé : je voulais parler de blacklistage entre FAI et
FAI ou hébergeurs.


--
siger

SAM

unread,
Mar 1, 2011, 8:52:33 PM3/1/11
to
Le 01/03/11 23:18, siger a écrit :

>
> Ce que je voulais dire est que quand on ouvre un TXT avec un éditeur de
> texte je m'attend à ce qu'il reconnaisse le jeu de caractères.

Ça s'est quand même bien amélioré depuis les années 80 ou même 90.
(je ne rencontre plus guère de problèmes d'accents que lorsque je fais
du copié-collé depuis un document PDF)

> Je me suis mal exprimé : je voulais parler de blacklistage entre FAI et
> FAI ou hébergeurs.

D'où crois-tu que sortent ces listes noires ?
si ce n'est des FAIs
et pour répondre à des spam ou phising inacceptables venus des autres.

Bon ... on peut regretter leurs méthodes un peu ... exagérées !?

0 new messages