Je crois plutôt que ce sont les éditeurs qui ne sont pas totalement wysiwyg ?

Philippe.

Le plus gênant c'est le côté aléatoire des sauts de ligne générés !!!! Si l'anomalie était constante o s'y adapte, mais là... un coup il y a un saut de ligne, un coup il n'y a pas de saut de ligne, un coup il y a 2 sauts de lignes !!! Bref, impossible de prévoir le résultat final !

J'ai aussi remarqué une chose avec Tiny Editor:

Il supprime les attributs des balises et certains styles ! Par exemple, j'avais utilisé <p onclick="...."> avec koivi, ce qui fonctionne parfaitement. La même syntaxe avec Tiny et le onclick disparait ! De même avec des images cliquables utilisant <map>.tiny efface tout simplement la balise map et son contenu.

Mais encore une fois, c'est la gestion des retours à la ligne qui me fait chiier comme on dit dans le midi !

Avez-vous résolu le problème d'une manière ou d'une autre ?

Je pourrais utiliser dhtml qui fonctionne bien. Mais je voudrais utiliser un wysiwyg car les administrateurs du site ne seront pas des personnes imprégnées du feeling informatique, loin s'en faut !

Alors les subtilités du DHTML et autres attributs, autant leur parler du martien !

Tu pourrais détailler cette histoire de retour à la ligne, je ne suis pas sûr de bien saisir.

Philippe.

Regarde un peu plus haut dans cette discussion.

Disons que en principe quand tu fais (en fin de phrase) un retour à la ligne avec "Entrée" ça crée un nouveau paragraphe (html: P), et si tu fais un retour à la ligne avec "Maj+Entrée" ça crée un simple retour à la ligne (html: BR).

Dans le formulaire de saisie tout est apparemment OK, mais quand tu publies, le résultat est différent !

Parfois tu as un saut de ligne, parfois il n'y a pas de saut de ligne, parfois il y a 2 sauts de lignes !

Et si tu fais le même retour à la ligne sur
plusieurs lignes, certaines sont bien

interprétées et d'autres
non !

Impossible de trouver où est le problème... est-ce que quelqu'un pourrait m'indiquer précisément où est géré le retour à la ligne dans:
- xoops
- news
- koivi

Si tu édites le texte pour le corriger, la mise en page est bonne (comme lors de la saisie !

Peut-être y a t'il une gestion multiple du retour à la ligne qui se contrarie (entre mode saisie et mode publié, ou entre les divers éléments xoops-koivi-news) ?

Je viens de regarder d'un peu plus près comment est interprété le code généré par koivi, avec morphogenesis.

Un problème vient du fait que les retours à la ligne simples (BR) à l'intérieur d'un élément de liste (LI) sont doublés ...

Comment supprimer ce phénomène ?

D'autre part je confirme que le code n'est pas interprété de la même manière selon qu'on est en mode saisie ou en lecture une fois publié ! Pourquoi ?

Par exemple les puces de listes imbriquées sont différenciées en saisie mais pas en lecture ! L'alignement du texte aussi est différent ...

Ce que je sais, c'est que dans les listes à puces, pour moi ce sont les tags <ul> </ul> qui me posent problème et que ça va mieux quand je les supprime en mode code html (sous tinyeditor).
Mais c'est mal affiché sous Firefox.

Philippe.

Avec koivi, si tu cliques dans une ligne d'un paragraphe <p> pour la transformer en liste à puces <ul>, en fait c'est tout le paragraphe qui est transformé en élément <li> d'une liste <ul>

C'est à dire:

<p>paragraphe</p>

devient

<ul>
<li>paragraphe</li>
</ul>

Et les retours à la ligne dans li sont doublés ... comment supprimer ce doublement ?

Dans le html, enlève les balises </li> juste pour voir.

Mais, par ailleurs, on ne peut pas voir un exemple en ligne + le code html dans l'éditeur ?

OK, alors voici ...

Image du texte pendant la saisie:

























Le code HTML généré:

<p>Début de liste:</p>
<ul type=""><li type="" value="0">puce 01<br />
Hanc regionem praestitutis celebritati diebus invadere parans dux ante edictus per solitudines Aboraeque amnis herbidas ripas, suorum indicio proditus, qui admissi flagitii metu exagitati ad praesidia descivere Romana. absque ullo egressus effectu deinde tabescebat immobilis.</li>
<li type="" value="0">puce 02<br />
Hanc regionem praestitutis celebritati diebus invadere parans dux ante.<br />
Edictus per solitudines Aboraeque amnis herbidas ripas, suorum indicio proditus.<br />
Qui admissi flagitii metu exagitati ad praesidia descivere Romana. absque ullo egressus effectu deinde tabescebat immobilis.</li>
<li type="" value="0">puce 03<br />
Hanc regionem praestitutis celebritati diebus invadere parans dux ante edictus per solitudines Aboraeque amnis herbidas ripas, suorum indicio proditus, qui admissi flagitii metu exagitati ad praesidia descivere Romana. absque ullo egressus effectu deinde tabescebat immobilis.</li>
<li type="" value="0">puce 04</li>
</ul>


Et le rendu final dans news:




























Dans le texte généré j'ai mis en gras ce qui correspond à la zone entourée en rouge.

On peut voir que le code généré et la fenêtre de saisie sont cohérents, chaque <br> correspond à un retour de ligne simple.

Mais on voit aussi dans le rendu final que le 1er <br> est bien interprété, mais les suivants sont doublés !!

Si je fais le test dans un paragraphe, hors d'une liste, les <br> sont doublés de la même manière.

A qui revient la faute ? gestion de xoops, de Koivi ou de News, ou bien l'interaction des 3 ?

A quels endroits de ces trois composantes sont gérés les retours à la ligne ?