Migration BBcode

C’est typiquement le genre de sommaire qui doit être limité à 2 niveaux.
C’était d’ailleurs le cas sur la V5, et ça a été supprimé dès le début de la V6 pour que le sommaire s’affiche : Camptocamp.org

Yep, j’ai bien ca en tete.

Il y avait un sommaire mais Krystof l’a supprimé !
Et en plus il a pourri le doc avec des lignes vides.
C’était mieux sur cette version : Camptocamp.org

En fait, il y a un proto-sommaire dans le résumé :

Oui, j’avais essayé de remettre au propre le document tellement il me faisait mal au cœur depuis 1 ans. Mais, j’ai renoncé car ce n’était pas possible de faire quelque chose de propre. Je peux essayer une 2ème tentative. Mais sans un colonage et quelque chose comme le [P], ça me semble difficile.
Ne pas pouvoir sauter de ligne avait été la totale.

Bref, si je récapitule le consensus, pour ce qu’il en est pour le moment :

  1. On n’affiche pas l’emphase derrière le #
  • On n’affiche que les titres de niveaux 1, 2 et 3, cas le plus courant
    • à voir plus tard si on veut une option qui force l’affichage des titres 4, 5 …
  • On déplace le titre à droite par défaut
    • à voir plus tard si on veut une option qui le force à gauche.

Et l’option forcer à gauche est plus prioritaire que l’option forcer l’affichage des titres de niveau 4, 5 …

Il ne faut pas avoir à sauter de ligne !
C’est fini depuis longtemps la mise en page style machine à écrire où on met des espace/lignes vides à la main pour faire la mise en page !
Une mise en page doit être structurelle : l’humain donne des instructions générales (ceci est un titre de niveau 1, ceci est un paragraphe, etc), et la machine fait la mise en page détaillée.
En l’occurence, dans ton cas, ce que tu as voulu faire, c’est ajouter un espace avant le sous titre. Mais c’est simplement un défaut de l’affichage du sous-titre, qui est un défaut pour tous les documents, et pas seulement pour celui-ci. L’affichage de sous titres (via le CSS) doit être complètement revu, c’est tout bancal actuellement (pas de marge suffisante, niveau 3 plus gros que niveau 2, niveau 4 ou 5 plus petit que le texte normal, etc).

Je suis d’accord avec Bubu : les sauts de lignes auraient fait que ton article ne soit pas trop horrible sur ton écran, mais infect sur tous les autres.

Il faut que je trouve une solution élégante pour pouvoir faire une rupture de ligne, ce qui était possible avec [p] avant.

1 Like

Bubu, arrête ton char.
J’avais surtout essayé de remettre un peu au propre, avec les moyens du bord, une page massacrée par le passage à la V6. C’est le même problème pour toutes les pages où des contributeurs ont touché au L#, et à d’autres balises, parce qu’ils en avaient marre de voir l’état pitoyable de ces pages depuis 1 ans ! Je ne te refais pas l’historique pour les balises L#. Est ce OK ?

Oui.
La balise [p] insérait un div avec un clear:both dessus, permettant de passer la suite du texte en dessous de tous les blocs définis au-dessus.
Mais il va falloir une balise pour ça, que ce soit [p] ou autre chose. Ce n’est pas possible de savoir automatiquement si on souhaite qu’une image à droite soit à côté de 2 paragraphes, ou du 1er seulement.

Résultat, c’est tout aussi moche. Mais quand les possibilités de mises en pages auront été améliorées, il faudra de nouveau corriger cet article pour enlever les lignes vides avec un point…

1 Like

Toutafait. Comme pour toutes les pages modifiées par des contributeurs pour les même raisons.

Bon, c’est un autre sujet.

Le consensus ci dessus va à tout le monde?

Autre question, vous pouvez me donner votre choix sur la priorité entre ces 4 choses :

  1. Le [toc] (tout ce qu’on vient de dire ci dessus)
  2. les balises [picto]
  3. les balises [important] et [warning] sur le nouveau modèle sans bug
  4. la balise [p]

Personnellement, du plus prio au moins prio : 1 > 3 > 4 > 2

Perso : 4 > 1 > 3 > 2
En effet, la balise [p] concerne (actuellement ou potentiellement) bien plus de docs que le sommaire (qui lui fonctionne déjà un peu).

4 > 1 > 3 > 2

Pas d’avis, faites pour le mieux.

Oui

Prio :
1 > 4 > 3 > 2 (mais j’ai pas trop compris l’intérêt de la balise [p] : edit : compris, et choix modifié).

Y a qqun qui a prévu de s’en occuper ? Parce que moi, ça c’est en top prio (avant le 1 ci-dessus). Y a pas mal d’articles (dont des articles d’aide) qui sont illisibles à cause de ça. Ce qui donne moyennement envie de les mettre à jour (ou pire incite à faire des bidouilles à la Christophe pour tenter de les rendre lisibles).
On n’est pas obligé de tout revoir d’un coup, mais déjà corriger ça :

Imagine que tu as un paragraphe relativement court, avec sur sa droite des illustrations qui prennent plus de place verticale que ton paragraphe.

Tu souhaites que le paragraphe suivant, qui n’est pas concerné par tes illustrations, commence après le bas de ta dernière illustration. Ce n’est actuellement pas possible, car il commencera après le bas de ton paragraphe précédent.

La balise [p], placé avant ton second paragraphe, le forcera à commencer à l’endroit voulu.

Pour l’affichage, j’ai toujours pas de setup qui me permette de travailler sur le design, et j’ai bien le nez dans le parser, ce qui est un sujet assez complexe. Je botte en touche, meme si je suis d’accord que ces points de design sont archi prio.

OK merci pour les explications. Du coup je modifie mon choix ci-dessus en remontant le [p] d’un cran dans les prio.

Au passage, je suis en train de faire une petite modification sur le parser. Elle est assez minime, et sa raison est très technique, et je ne pense pas pouvoir vulgariser suffisament. Si les jargons HTML ne vous rebuent pas, c’est ici : Do not include <figure> inside a <p> tag by cbeauchesne · Pull Request #1940 · c2corg/v6_ui · GitHub

Par contre, elle aura une conséquence : la balise [img] devra se trouver sur une seule ligne. J’ai migré la base avec @rabot.

Je sais qu’auparavant, elle pouvait servir à rajouter des images dans le corps du paragraphe. C’est actuellement cassé, et avec cette modif, ca sera encore moins possible. Je réfléchis à une solution pour ce besoin.

Pour ce coup la, je n’ai pas trop demandé d’avis, car la cohérence globale du parseur est en jeu, désolé :frowning:

Il faudrait donc modifier le parser pour éviter que l’insertion d’une image ajoute une ligne (a priori il suffit de manger les espaces + retour ligne qui suit). Il faut aussi que le parser soit tolérant à des espaces en fin de ligne (certains navigateurs ajoutent un espace en fin de ligne quand on ajoute un retour ligne).
Des images calées à droite ont été mises sur la même ligne que le texte ou le sous titre, car sinon ça ajoute une ligne vide au-dessus actuellement.
Autre exemple : quand on veut mettre une image à gauche et une à droite.
Avec ta modif, les images sont décalées : Camptocamp.org
Alors qu’auparavant elles étaient bien alignées : Camptocamp.org

Mais je suis d’accord pour obliger à mettre le code d’une image tout seul sur une ligne.
Sur la V5, il n’y avait pas de différence si on mettait une image par ligne ou plusieurs par ligne : le parser supprimait l’espace ou retour ligne qui suit chaque code d’image.