ARNO*

Rhaaa, c’est une bêtise de @fil qui, en plus, savait très bien qu’il était en train de faire une bêtise :
▻http://comments.gmane.org/gmane.comp.web.spip.devel/62121

L’argument pourri :

oui c’est le souci, on n’est plus sur le dos des gens pour leur interdire de faire des bêtises

@rastapopoulos :

Le seul point embêtant que je vois c’est que ça facilite l’utilisation de <br/> qui est rarement une bonne pratique dans un texte HTML.

Alors est-ce que cette modification va aboutir à une explosion des <br/> dans les sites SPIP ? Il faudra voir à l’usage. Ça te fait pas peur ce point, Fil ?

Et retour de l’argument pourri :

ben est-ce que c’est notre rôle de fliquer les usages ?

Ben si, c’est la nature même de SPIP de promouvoir les bons usages et de rendre les mauvais usages plus difficiles. C’est sa spécificité.

Je ne vois pas bien la logique qui ferait de seenthis un site spécifique de ce point de vue. L’usage, partout, est de respecter les sauts de ligne, et la meilleure preuve que c’est chiant de ne pas le faire, c’est que dès que tu as fait un site ouvert à tous, tu t’es empressé de basculer sur cette norme.

Si, Seenthis est spécifique par rapport à SPIP, pour plusieurs raisons :

– le système est explicitement destiné à ce qu’une grosse partie du contenu soit des copiés-collés directs de documents externes ; et là, si je ne respecte pas les retours à la ligne, dans la moitié des cas je perds carrément les paragraphes ; c’est pour la même raison que le style des paragraphes, sur une page de flux (plusieurs billets successifs), réduit à 60% l’espace entre les paragraphes (il s’agit de limiter les trop grandes différences visuelles entre les extraits avec paragraphes et les extraits avec retour chariot) ;

– Seenthis exclue totalement l’utilisation des raccourcis typographiques ; et au départ, il n’y avait même pas de gras et d’italique (pas certain qu’on y ait gagné d’ailleurs) ; et dans cette logique de construire les textes en mode texte (à la façon d’un mail en mode texte), le retour chariot est assez fréquent comme outil de mise en forme (par exemple : dans un pavé Seenthis on colle l’URL sans possibilité de l’intégrer au texte ; le retour chariot est alors bienvenu) ;

– SPIP avait déjà un raccourci pour faire des retour à la ligne (underscore en début de ligne) ; dans SPIP ça se justifie, au côté des autres raccourcis non Wysiwyg ; dans Seenthis, non (puisque pas de système de raccourcis).

Mais l’argument principal, à mon avis, c’est bien ton inquiétude et ta réponse à Rastapopoulos : est-ce qu’on ne risque pas de provoquer la multiplication des usages illégitimes du <br> avec ce changement ? Tu ne réponds pas sur le fait qu’il n’y a pas un tel risque, ou qu’il serait contrebalancé par un gain ailleurs, mais simplement qu’on n’a pas à cliquer les usages. C’est un changement de paradigme de ce pour quoi SPIP est conçu, et je suspecte que ce renoncement est très présent dans nombre d’évolutions de SPIP 3.

Là je ne vois pas ce qu’on a au niveau fonctionnel (le retour chariot était déjà possible), mais en revanche on a fait disparaître sciemment un garde-fou qui faisait que SPIP avait, au niveau typographie, une vertu pédagogique (les gens demandaient comment on fait, on répondait à la fois techniquement et en prévenant que c’était rarement une bonne idée).

Bah oui, mais le underscore en début de ligne, ça marchait tellement pas qu’on avait déjà depuis longtemps forcé le saut de ligne dans les forums — là où les gens ne se relisent pas, et envoient des pâtés infâmes sans aucune respiration.

A tout prendre, le <br> est meilleur que l’espace, dès lors que l’intention du rédacteur/commentateur est de sauter une ligne ! Pour ce qui est de la soi-disant pédagogie, elle peut se faire autrement (les boutons de la barre de rédaction, etc.)

Ce qui reste in fine, c’est l’usage. Ce que je constate en à peine quelques sites, c’est la multiplication des <br class="autobr"> partout. Et tu as beau expliquer qu’il faut sauter des lignes, il en reste toujours : oublis parce que pas aussi visibles qu’avant, et/ou les gens ne trouvent pas ça si choquant.

Et, non, je ne constatais évidemment pas ça avec SPIP 2.

En parlant d’usage, avant de bouger le petit doigt j’avais notamment regardé un par un tous les forums du blog.mondediplo. Et il y avait beaucoup de sauts de ligne, à 99% exprimant une intention de passer à la ligne.

Pour moi, donc, l’usage est clair : « les gens » veulent passer à la ligne, ils tapent une ligne. Et si ça ne marche pas, par exemple lors de la prévisualisation (durant laquelle ils regardent, si tout va bien, s’il n’y a pas des fautes d’orthographe… mais certainement pas la disposition du texte), ils ne cherchent en général pas plus loin — et SPIP fait un gros pâté.

Ce qui est valable pour les forums devrait être aussi valable pour les articles.

Pour les rédacteurs qui mitonnent leurs textes dans l’espace privé, on a bossé pour rendre bien visibles les BR. Mais c’est l’espace privé… mais ça me donne une idée pour l’espace public : dans la css des crayons (ou des boutons d’admin), on pourrait ajouter le truc qui rend visibles les BR, ainsi ils seraient visibles aussi dans le public, et là vraiment personne ne pourrait les rater.

Mais les forums et les articles ne sont pas la même chose, et ne demandent pas du tout le même rapport au site (niveau d’engagement).

Je ne suis pas choqué qu’on ait des différences entre les deux. Et même, l’idée d’interdire totalement les enrichissements typographiques dans les forums ne me choquerait pas non plus.

Une piste : et pourquoi les forums ne passeraient pas, purement et simplement, dans la syntaxe de Seenthis : cette syntaxe est à la fois quasiment inexistante (surtout si tu supprimes les gras, italique et hashtags), et conçue justement pour gérer et maquetter du « texte brut » de manière quasiment transparente (donc pour des forums).

Dans les forums de spip-contrib, on échange souvent du code précis… la syntaxe de seenthis ne le permettrait pas. La syntaxe SPIP a ce grand mérite d’être à la fois simple et d’autoriser un maximum de possibilités « expressives ». Le seul bug, à l’usage, était cette histoire de sauts de ligne jamais pris en compte, bien que « saisis » (ou plutôt « tapés ») par les utilisateurs basiques.

Ton problème doit à mon avis se régler autrement, soit par l’imposition technique d’une suppression des .autobr (par le define, par un hack css, ou par ton plugin NoBR), soit par la pédagogie (en ajoutant éventuellement un signalement dans l’espace public, via la css des boutons d’admin/des crayons).

On peut en discuter encore longtemps, vu qu’on n’est pas d’accord, mais je crois que j’ai fait le tour des arguments que je pourrai développer :)

Pour former régulièrement des utilisateurs à SPIP je confirme que la non prise en compte des retours à la ligne suscite la perplexité, ainsi que le raccourci _ Pour ma part je ne rétabli les comportements antérieurs que pour des sites où le contenu est issu de copier/coller plein de retours à la ligne intempestifs. Et les rédacteurs créent quand même des paragraphes.