[spip-dev] sauts de ligne (pour tests et discussion)

Dev
1

Coucou,

j’ai commité dans textwheel une gestion propre des sauts de ligne dans le texte.

Donc désormais, un saut de ligne dans un paragraphe de texte est pris en compte et provoque un BR.

Plus précisément, ça provoque “
\n”.

Cela permet d’adresser ce saut de ligne en CSS :

  • pour le neutraliser :
    .autobr br { content: “” }
  • pour afficher un joli symbole
    .autobr:before{content:"\0B6";color:orange;}

Je propose que, dans l’espace privé, on affiche ce symbole.

PS: Je sais que certains ne les aiment pas, pour de bonnes raisons ; pour revenir au fonctionnement classique, il suffira d’indiquer dans mes_options :

define(’_AUTOBR’, ‘’);

PPS: bien sûr le raccourci "_ " continue à fonctionner.

PPPS: on peut donc certainement démonter le filtrage ad hoc ajouté dans les forums…

– Fil

2

Plus précisément, ça provoque "<span class='autobr'><br /></span>\n".

Sur la forme, un <br class="auto" /> serait un poil plus élégant, si ça ne pose pas de problème technique.

Sur le fond: chouette !

3

Plus précisément, ça provoque « 
\n ».

Sur la forme, un
serait un poil plus élégant, si ça ne pose pas de problème technique.

bien sûr ce serait mieux, mais comme je n’arrive à le styler avec un :before, je suis passé par ce truc. Mais s’il y a moyen je prends

– Fil

4

Pas mieux, br étant un simple saut de ligne traité différemment dans chaque navigateur! On attendra donc que les codes évolus! grrr

Sinon, pour annuler le br , ça marche pas sous firefox avec
.autobr br { content: "" }

par contre ça marche avec
.autobr br{display:none}

marquer l'espace qui peut manquer?
.autobr:before{content:" "}

5

Coucou,

j'ai commité dans textwheel une gestion propre des sauts de ligne dans le texte.
Donc désormais, un saut de ligne dans un paragraphe de texte est pris en compte et provoque un BR.

Si je comprend bien, ce petit commit retire l'un des piliers de la culture du rédacteur spip
et mettra sur le carreau la présentation de tous les sites en SPIP 2.1 et antérieurs,
lorsqu'ils migreront en SPIP 3.

Quel est donc le nouveau paradigme qui motive cela ?

PS: Je sais que certains ne les aiment pas, pour de bonnes raisons ; pour revenir au fonctionnement classique, il
suffira d'indiquer dans mes_options :
    define('_AUTOBR', '');

Comme le relève toutati '' n'ira pas, ' ' limiterait mieux la casse, ou mieux en plus complexe.

Vu l'ampleur du changement induit, est-ce que ça ne devrait pas plutôt être une option
proposée lors de la phase d'installation de SPIP3 ou dans un onglet de la config en partie privée ?

JLuc

6

Hello,

ma première réaction c'est
"bon voilà, c'était inévitable : a force d'attendre pour rien, quelqu'un à une bonne idée, et on ré-ouvre un chantier qui va encore nous repousser de X mois et de fil en aiguille on ne fera que repousser, démontrant un peu plus notre incapacité à sortir une release".
Le pire scénario donc...

Maintenant pour être positif : c'est super, ça correspond à ce que plein de monde demande/attend/...
Compte tenu de la rupture je ne pense pas qu'on puisse se contenter d'un define pour choisir entre le mode compatible ancien et le nouveau mode.

Donc OK allons y, gardons ça dans la release mais :
- Intégrons une configuration dans l'interface pour permettre aux utilisateurs de changer facilement de mode
- les sites upgradés sont mis par défaut dans la config off (pas de <br /> sur les retour ligne)
- les nouvelles installation sont mises par défaut dans la config on

Et au pire si on se plante et qu'il reste un gros bug, ça permettra aux utilisateurs de revenir dans le mode compatible.
Mais, please, sortons cette release....

Cédric

PS : D'un point de vue technique :
- Noublions pas que :before, :content et :after nécessitent tous IE8 mini. Mais peut-être on peut arriver au même résultat avec padding et image background ?
- Et pour être (un peu) moins verbeux que dirais-tu d'un
<b class='br'><br /></b>

7

Donc OK allons y, gardons ça dans la release mais :

  • Intégrons une configuration dans l’interface pour permettre aux utilisateurs de changer facilement de mode

Non. Tu ne veux pas changer de « mode » comme ça, tu veux vraiment switcher sans retour (comme le passage en utf8). Sans quoi tu auras toujours un risque de perdre tes sauts de ligne auto de l’article 14 si tu veux revenir en arrière à cause de l’article 13. Donc ça va forcément être un peu brutal.

  • les sites upgradés sont mis par défaut dans la config off (pas de
    sur les retour ligne)
  • les nouvelles installation sont mises par défaut dans la config on

Pas d’accord non plus, car il faut de toute façon unifier l’expérience utilisateur. Je suis en train de faire un tableau de bord qui liste tous les articles du site pour lesquels ça change qq chose. Comme ça, dans chaque site, on verra mieux quoi faire : on verra de façon synthétique les articles à repriser. Il faut que j’essaie de faire une moulinette qui virerait (à la demande) les sauts de ligne devenant foireux, afin que ça permette de le faire relativement vite même sur un gros site.

Et au pire si on se plante et qu’il reste un gros bug, ça permettra aux utilisateurs de revenir dans le mode compatible.

Avec le define c’est suffisant : on imagine « le pire » (c’est-à-dire un gros site avec beaucoup d’articles « réellement plantés »), et alors il suffira d’un define dans mes_options le temps de voir.

Mais, please, sortons cette release…

A mon avis on n’est pas obligé de se précipiter : ni pour SPIP3, ni pour intégrer ce dev dans la SPIP3 finale.

Quoi qu’il en soit, la question de AUTOBR ne change rien à la possibilité de sortir SPIP3 aujourd’hui. Si cet AUTOBR n’est intégré en standard que dans SPIP4, ça me va aussi. J’aurai d’ailleurs d’autres trucs importants dans le domaine des traitements des raccourcis à y intégrer (ce qui d’ailleurs peut plaider pour les intégrer tous en même temps, et donc plus tard).

(Sinon j’ai dit ce qui me chiffonne dans ce SPIP3, et à mon goût ce n’est pas « rien ».)

PS : D’un point de vue technique :

  • Noublions pas que :before, :content et :after nécessitent tous IE8 mini. Mais peut-être on peut arriver au même résultat avec padding et image background ?
  • Et pour être (un peu) moins verbeux que dirais-tu d’un

A vrai dire j’aimerais vraiment trouver comment gérer
sans l’intégrer dans un élément. Ca serait beaucoup mieux à tous points de vue. Et je me rends compte que :
— Pour l’ajout des symboles dans l’espace privé, il suffit tout simplement d’ajouter un filtre ad hoc avant d’envoyer le flux.
— Pour l’effacement dans l’espace public, j’avais connement oublié d’essayer display:none… :slight_smile:

– Fil

8

* Fil tapuscrivait, le 26/02/2012 15:58:

Coucou,

j'ai commité dans textwheel une gestion propre des sauts de ligne dans le
texte.

Donc désormais, un saut de ligne dans un paragraphe de texte est pris en
compte et provoque un BR.

Quand je pense que j'apprends à tous ceux que je forme à SPIP que SPIP est l'outil qui leur manquait pour récupérer facilement par copier/coller des textes qui sont dans un PDF sans avoir à enlever à la main tous les retours à la ligne que le PDF transmet...

:wink:

AMHA, il vaudrait mieux :
- apprendre à utiliser Maj-Entrée qui, avec le PortePlume, fait un _
- et apprendre aux gens qu'un paragraphe, ce n'est pas la même chose qu'un retour à la ligne.

Du coup, quitte à changer le moteur typo de SPIP, autant faire que :
- Simple retour à la ligne => Paragraphe <p> (et ça réglerait la source du problème)
- et garder _ pour le <br />

9

Du coup, quitte à changer le moteur typo de SPIP, autant faire que :

  • Simple retour à la ligne => Paragraphe

    (et ça réglerait la source du problème)

pour cela il te suffira d’utiliser http://www.spip-contrib.net/Interdire-les-retours-chariot

  • et garder _ pour le

Non. La meilleure preuve qu’il est « intuitif » de faire un saut de ligne en tapant un saut de ligne, c’est que c’est ce que font les gens (non spipeurs en général) dans les forums.

– Fil

10

* Fil tapuscrivait, le 27/02/2012 12:29:

Du coup, quitte à changer le moteur typo de SPIP, autant faire que :
- Simple retour à la ligne => Paragraphe<p> (et ça réglerait la source du
problème)

pour cela il te suffira d'utiliser
Interdire les retours-chariot - SPIP-Contrib

- et garder _ pour le<br />

Non. La meilleure preuve qu'il est "intuitif" de faire un saut de ligne en
tapant un saut de ligne, c'est que c'est ce que font les gens (non spipeurs
en général) dans les forums.

Sauf que lorsqu'ils sont dans un traitement de texte, [Entrée] fait non pas un saut de ligne, mais un changement de paragraphe.
Et [Maj-Entrée] fait un saut de ligne (<br>)

Et que la plupart des gens n'ont aucune idée de la différence conceptuelle entre un simple retour à la ligne, et un changement de paragraphe.
Pourtant, cette différence est essentielle sur le web pour la bonne compréhension du texte (et éviter de zapper une idée).

11

Non, on n'attend pas pour « rien », mais parce que ce n'est pas prêt. Il manque la dernière étape : rendre *utilisable* cette version (pas pour nous, mais pour ceux qui vont suivre, qui vont la découvrir à sa sortie et se l'approprier).

Concrètement, pour compléter ce que pointait dernièrement Fil ici :
http://comments.gmane.org/gmane.comp.web.spip.devel/62102
il me semble rester un travail d'homogénéisation des nomenclatures, de choix de structure, d'organisation des répertoires, bref, tout ce qui va permettre de rendre le machin compréhensible et permettre de l'expliquer (et écrire la doc). En l'état, je suis, par exemple, incapable d'écrire une phrase qui ne prête pas au quiproquo sur les « plugins » et « extensions », pas pour troller, mais juste parce que nous employons ces mots dans un sens, puis un autre…

Voici quelques tickets en rapport :
http://core.spip.org/issues/2520
http://core.spip.org/issues/2381
http://core.spip.org/issues/2501
http://core.spip.org/issues/2281
http://core.spip.org/issues/2319
http://core.spip.org/issues/2318
http://core.spip.org/issues/2176
etc.

Et aussi le problème de la dist, qui est éclatée dans plusieurs sous-répertoires à n'y plus s'y retrouver. Il n'y pas (encore) de ticket correspondant, mais il me semble nécessaire de conserver un squelette minimum prêt à l'emploi dans le répertoire habituel du core « squelettes-dist ».

Je note juste ici pour mémo
http://core.spip.org/issues/2502
voir aussi ces commentaires :
http://romy.tetue.net/691#comments

Quand à la structure HTML de référence :
- j'ai travaillé la dist de SPIP3 pour être à mi-chemin entre SPIP2 et SPIP3+Z, pour familiariser les webmestres avec cette nouvelle structure
- mais il vaudrait mieux éviter la diversité actuelle : SPIP2 ≠ SPIP2+Z ≠ SPIP3 ≠ SPIP3+Z et merger un minimum, en adoptant une structure commune en SPIP3, avec ou sans Z.

Voir aussi :
http://romy.tetue.net/structure-html-de-base
http://blog.smellup.net/spip.php?article47
http://thread.gmane.org/gmane.comp.web.spip.zone.cvs/40513/focus=26065

Oui, avant. C'est à la sortie d'une version majeure que s'initient de nouvelles habitudes. Pas en loucedé après coup.

-- Romy

12

Oui moi aussi j'ai plein de trucs encore que je voudrais faire mieux/plus/... qu'ils ne sont actuellement sur cette version.
Il y a plein de raisons objectives de ne pas la sortir et d'encore améliorer.
Mais il y en aura toujours, on le sait très bien. Les choses ne seront jamais comme on le voudrait, parfaites.

Alors on peut continuer à alimenter la listes des choses qu'on voudrait corriger avant de sortir. Oui.
Et compte tenu qu'en face on (et je me mets dedans) avance 10 fois moins vite que ce que la liste augmente,
alors on peut conclure assez facilement qu'on ne sortira plus jamais aucune version stable...

Il n'y a rien de rédhibitoire dans la version actuelle, on a releasé des versions bien moins abouties.
A contrario, la plupart des utilisateurs qui testent la version sont plutôt enthousiastes.

Je pense qu'on se rendrait vraiment service en publiant une version stable, et ça n'empêche pas de dire ce qu'il y a dedans qui nous plait pas et qu'on voudrait améliorer.
Si on a l'énergie pour corriger vite ces questions en attente depuis des mois (années pour certaines), alors il sera très facile de faire des releases correspondantes. Si ces problèmes doivent encore attendre des mois (années) alors il est assez contreproductif de continuer à attendre.

En attendant on prive les utilisateurs des améliorations existantes, et même pire que ça, on en vient à re-coder ces améliorations sur la branche 2.1 dite 'stable', comme si on avait de l'énergie à revendre pour faire plusieurs fois la même chose....

Mais le plus grave, à mon avis, c'est qu'on se décourage tous, à l'idée de n'arriver à rien. Et qu'on décourage aussi les utilisateurs d'attendre du nouveau du côté de SPIP.

Je dis ça je dis rien, as usual, plus découragé qu'espérant quoi que ce soit...

Cédric

13

C'est le truc qui m'inquiète un rien: sur un site, j'ai au moins 200 articles issus de pdf et 200 issus de word.

Mais si l'up apporte une moulinette... Je testerai :slight_smile:

14

Justement, je ne parle pas de faire « mieux » mais d'aboutir. Rendre utilisable. Ne pas laisser la cuisine dans cet état, qu'on est les seuls à comprendre, avec des bouts de trucs partout (garde-t-on ce /squelettes-dist quasi vide et éparpillé ? et autant de structures différentes : SPIP2 ≠ SPIP2+Z ≠ SPIP3 ≠ SPIP3+Z ?), mais passer un coup d'éponge, ranger un peu pour les autres, et rédiger la recette pour qu'ils puissent s'amuser aussi. Bref, préparer la sortie :slight_smile:

-- Romy

15

Bonjour,

Cette discussion m'intéresse d'autant plus que j'ai rencontré beaucoup de difficultés il y a un certain temps pour essayer de partir de squelettes Zpip pré-installés pour modifier certains sites.
Au final j'ai repris comme avant les squelettes à partir de zéro en enlevant zpip, qui rajoutait une couche qui compliquait tout.
Donc, je suis assez d'accord avec ce que dit Romy quant à la nécessité de clarifier les objectifs des différentes parties intégrées ou non à spip.
D'après ce que j'ai pu comprendre Zpip servirait surtout à permettre l'installation de thèmes...il ne m'a jamais paru pratiquable de le maintenir pour personnaliser complètement un portail.

Et puis je découvre SPIP 3 actuellement et j'ai deux chantiers en route l'un où je l'ai adopté et un autre qui s'annonce plus complexe, pour lequel j'hésite encore un peu.
C'est vrai que je suis déjà très déconcerté par la complication des fichiers et répertoires mis dans /extensions/dist par rapport au squelettes-dist de la 2.1

Comme je fréquente aussi des débutants en squelettes cette nouvelle répartition me parait déjà très complexe à appréhender pour celles et ceux qui sont en phase d'apprentissage, quand il va leur falloir passer de la 2.1 à la 3. Celà me fait me demander si ce ne serait effectivement nécessaire de faire des choix avant la distribution. Je ne suis pas assez callé techniquement pour savoir si il serait possible de se débarasser du reliquat de squelettes-dist suffisamment rapidement mais effectivement ce serait bien. Parce que comme simple intégrateur en l'état SPIP 3 me fout un peu la trouille ; j'ai déjà passé quelques heures à m'y repérer.

D'un simple point de vue utilisateur, je dirais être très beaucoup d'accord avec ce que suggère Romy de trouver moyen de simplifier tout ça pour le rendre utilisable indépendamment de Zpip, aux personnes qui apprécient de pouvoir fabriquer des spip en s'inspirant souvent de ce qu'ils trouvent dans l'interface visiteurs proposée par défaut dans l'application.
Et quoiqu'étant une flemmase qui ne ferait peut-être pas la 3 beta2 vu la complexification du truc m'a déjà plus d'une fois réveillé l'idée d'aller regarder sous les jupes d'autres CMS, pour voir...

Bonne continuation et surtout ne vous découragez pas. Il est souvent préférable de bien prendre le temps d'échanger sur les choix, même si c'est toujours fatiguant et energivore. Dans le cas présent, ce sera peut-être plus la direction vers où irait spip 4 qui serait peut-être plus éclairante que la référence à la 2.1...

Merci pour spip à toutes et tous

Philippe

16

Il y a 10 ans, les résolutions d'écran allaient du simple au double.
Aujourd'hui, ça varie quasiment dans un rapport de 1 à 10,
et là SPIP se mettrait à prendre en compte ces fins de lignes
issues d'une saisie ou d'un copié collé dans une largeur donnée
et valables seulement dans des conditions identiques ?

JLuc

17

Bonjour,

J'ai un peu de mal à vous suivre, là. Le plus rationnel serait de concevoir le comportement comme suit :
- un retour chariot : saut de ligne
- deux retours chariot : changement de paragraphe

...et "les gens" sont pas si bêtes que ça, même si ils ne lisent pas toujours l'aide en ligne de spip...pourtant si instructive :slight_smile:

@+

Philippe

18

C'est bien le comportement de la modification de Fil.
Et c'est ce qui était déjà à peu près en place dans les forums je crois.

19

D'après ce que tu décris, ton problème est donc lié uniquement au copier-coller.

Ce n'est pas forcément le cas d'utilisation le plus courant même si c'est forcément un truc qui existe et qu'il faut prendre en compte (reporté par RealET aussi).

Pour le cas basique où l'on écrit son article dans le champ de texte, la modification de Fil me semble plus logique.

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 ?

20

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

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

d’un autre côté actuellement on leur interdit de taper une adresse

M. Jacques
25, boulevard de l’Ouest
75978 Drabeille

et on les force à avoir un illisible M. Jacques 25, boulevard de l’Ouest 75978 Drabeille

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

Si tu parles de l’usage nouveau en rédaction du saut de ligne, c’est ce qui est voulu :slight_smile:

Si tu parles du stock d’articles existants « écrits façon email », je suis justement en train de faire un truc qui les repère et permet de les corriger automagiquement.

– Fil