Retour De Ligne

Pour la détection des sauts de ligne

Plus intuitif
Important pour recopier des poèmes, une adresse, sans problème
L'emploi d'une balise de saut de ligne genre %%% est assez laid
On pourrait utiliser une balise d'encadrement pour ignorer les sauts de ligne

Contre

Gènant dans le cas d'un copier coller d'un texte formaté comme un mail
On peut utiliser le texte preformaté pour les texte les nécessitant comme les poème
C2, le wiki originel, les ignorait
Pour créer des retours de ligne, on pourrait utiliser une balise élégante comme le \ ou le -
Les puristes (x)HTML haissent les

La possiblité d'indiquer un retour de ligne est nécessaire. Le choix de la détection automatique d'un retour de ligne peut être séduisant et trés intuitif pour l'utilisateur (il fait un saut de ligne, ça genère un br). Mais cela peut poser des problèmes, lors de copier coller par exemple (en provenance d'un mail etc...), car cela va mettre des sauts de lignes là où on ne s'attend pas (si la largeur du conteneur est trop petite par rapport à l'original).

Forcer l'utilisateur à mettre une ligne vide, donc à créer un paragraphe, n'est pas une solution, car tout les textes ne sont pas composé de paragraphes même si il y a des retours à la ligne. Exemple : une adresse, un poème etc...

D'où l'utilité du br et donc d'avoir une balise wiki associée. -- Laurent Jouanneau

Je trouve les trois signes % assez laids et pas intuitifs du tout. Un délimiteur qu'on placerait en début et fin de texte me parait plus approprié, mais je n'ai pas vraiment d'idée pour la syntaxe exacte. Pourquoi ne pas simplement utiliser la syntaxe du texte préformaté qui fait déjà cette transcription des passages à la ligne? -- Michael Witrant

Le préformaté a d'autres fonctions. Pourquoi pas simplement une espace suivi d'un tiret et d'un retour ? -- François Granger

L'avantage d'un délimiteur de début et de fin est qu'on a pas à le répéter lorsqu'on copie/colle du texte. Ca evite aussi de surcharger un long texte de symboles spéciaux qui rendent sa modification et sa lecture à l'état brut fastidieuses.

Quelles sont les autres fonctions du préformaté? N'est-ce pas justement pour retranscrire un texte au maximum tel qu'il est écrit en brut? Pour les exemples ci-dessus, le préformaté semble bien convenir (adresse et poème). Ce sont des textes dont le formatage initial ne doit pas être modifié. C'est bien le rôle des balises <pre> il me semble.

C'est vrai qu'il peut etre intéressant de pouvoir ajouter spontanément un passage à la ligne, mais je ne vois pas de syntaxe intuitive (à l'écriture ou la lecture). Et comme on peut faire sans (avec des <pre> ou des ), je me demande si c'est bien nécessaire. -- Michael Witrant

Un gros probleme des <pre>, c'est qu'il n'y a plus de passage a la ligne lorsqu'on arrive a la fin d'une ligne justement (lorsque la ligne depasse la largeur de la boite/fenetre). En tous cas pas avec Internet Explorer. Du coup ca casse toute la mise en page et c'est tres laid. Ca marche pour du code, mais pas pour un dialogue avec des phrases entre guillemets par exemple. Et puis ca oblige a un changement de fonte du plus mauvais gout dans un roman. :) Ca n'a rien a voir avec la syntaxe wiki universelle remarquez. On peut envisager un delimiteur de debut et de fin qui n'est pas implemente avec un <pre> mais avec des -- Stephane Gigandet

Un dialogue avec des phrases entre guillemets? Je ne vois pas bien de quoi tu parles. Pour du code, les deux solutions sont aussi laides l'une que l'autre (faire passer une ligne trop longue sur la ligne suivante ou la laisser dépasser du browser). Donc je préfère laisser tel qu'il est écrit et eventuellement dépasser du browser si le programmeur fait de trop longues lignes (ce qui n'est absolument pas recommendé pour la lisibilité du code). Et effectivement, le wiki n'est pas vraiment fait pour écrire un roman :)

Avez-vous des exemples de cas où il faut des à chaque passage à la ligne lorsque ni le <pre>, ni les ne conviennent? Si non, je crois que dans un wiki il faut faire au plus simple: si on peut faire avec autre chose, il n'est pas nécessaire d'ajouter une syntaxe particulière.

-- Michael Witrant

Michael, voir plus haut : une adresse, un poème etc... necessite des sauts de ligne mais chaque ligne n'est pas un paragraphe, ni du texte préformaté -- Laurent Jouanneau

Si on devait quand même accepter une syntaxe, j'ai une proposition qui sera familière aux utilisateurs d'Unix mais qui a un sens opposé: Ajouter une anti-slash ("\", comment s'appelle-t-il en français?) juste avant le passage à la ligne ajouterai un . On peut imaginer la même chose pour les espaces: un anti-slash suivi d'un espace se transforme en   (espace forcé).

Le caractère anti-slash est souvent employé pour l'echappement de caractère spéciaux, pour changer le sens du caractère qui le suit.

-- Michael Witrant

Autre solution : par defaut, tous les retours a la ligne sont significatifs, meme s'il y en a qu'un. Reste le probleme du mail copie/colle, qui est a mon avis franchement rare, et qui pourrait etre resolu en mettant une balise de debut et de fin qui serait l'inverse de <pre>..</pre> : ignorer les retours a la ligne seuls entre ces balises.

-- Stephane Gigandet

Quelques points : d'une part le saut de ligne n'a pas de sens dans des paragraphes normaux : si on veut marquer une séparation forte, on change de paragraphe, sinon changer de phrase suffit. D'autre part les retours-chariot sont moins facilement identifiables visuellement que des lignes blanches. Quand on rédige une page, on peut avoir à déplacer des portions de texte ; si les retours simples sont ignorés ça facilite le travail (une phrase par ligne, il suffit d'accoler des blocs pour en faire un seul paragraphe...). Certains navigateurs doivent bien avoir des champs texte qui scrollent horizontalement : pratique de pouvoir garder une largeur de texte raisonnable au lieu de devoir mettre un paragraphe sur une seule longue ligne.

La poésie ou les dialogues sont des cas assez particuliers/rares pour qu'ils méritent d'être dans un bloc particulier. Mais comme d'habitude <pre> est formaté avec une police à chasse fixe qui conviendrait pour du code, de l'ascii-art ou un mail copié-collé, je vote pour un bloc distinct où les br sont tous pris en compte (<bron>, <broff> ?), mais où on a toujours le droit à la typographie :)

-- Damien Pollet

Moi aussi je pensais que le retour a la ligne simple ne servait presque a rien. C'etait avant que je mette un Editeur Visuel par defaut sur Joueb Point Com : l'editeur change de paragraphe a chaque fois que l'on appuie sur Entree. De nombreuses personnes ont alors desactive l'editeur visuel pour pouvoir revenir a la ligne quand elles le souhaitaient. J'ai alors indique tres clairement que Shift+Entree permettait de faire un retour a la ligne, et les personnes qui avaient desactive l'editeur l'ont a nouveau active. De tres nombreuses personnes reviennent a la ligne au milieu d'un paragraphe. A mon avis, le cas particulier, c'est plus le copier/coller de mail. Ca vous arrive souvent de copier/coller des mails dans Crao Wiki ? Moi jamais.

-- Stephane Gigandet

Dernière modification le vendredi 28 novembre 2003 12:26:17