Migration BBcode

#127

Ben ça dépend. Des fois on limitait à 1 niveau, d’autres à 2 niveaux, ou 3 niveaux.
Mais si on limite à 3 niveaux par défaut, c’est mieux qu’actuellement.

En effet, sur petit écran on aurait l’image à droite et le sommaire à gauche, tout ratatiné en largeur.
Pour éviter ça, il suffit de mettre un min-width de 400 ou 500px sur le bloc du sommaire quand il est à gauche et sur petit écran, pour qu’il s’affiche en dessous de l’image, en pleine largeur.
D’ailleurs il faudra aussi mettre un min-width de 500px pour les tableaux ltag, pour éviter qu’ils se fassent ratatiner par une image à droite sur petit écran (des fois à 15px près il passerait en dessous de l’image : autant forcer le décalage par un min-width).

Quand on cale le sommaire à droite, il faut aussi mettre un max-width de 500px, pour éviter qu’il ratatine le texte à gauche lorsque des titres sont longs.

#128

Dans un article ?
Ce n’est pas le cas sur c2c.

#129

Je pense plus au points de passages bien décrits : Camptocamp.org

#130

J’ai mis l’image à droite du sommaire pour voir ce que ça donne.
Une amélioration du sommaire à ne pas oublier : ne pas afficher dans le sommaire le texte additionnel des sous titres (texte après le # après le sous-titre), car ça encombre pour rien (la preuve ici avec des sous-titres à rallonge dnas le sommaire, mais à cause de l’affichage du texte additionnel).

#131

Pour moi, un sommaire ne sert pas nécessairement à grand chose dans ce type de document/contexte.

1 Like
#133

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

#135

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

#137

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.

#138

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 …

#139

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).

#141

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 ?

#142

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
#143

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

#144

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

#145

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).

#146

4 > 1 > 3 > 2

#147

Pas d’avis, faites pour le mieux.

#148

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 :

#150

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

#151

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: