Migration BBcode

Hello,

Voici le recap des balises BBCode, et leurs équivalents. Le changement n’est pas très compliqué à faire, mais il faut se mettre d’accord, notamment pour la partie a supprimer. Vos avis ?

A remplacer par des equivalents markdown

  • :white_check_mark: [b] => **
  • :white_check_mark: [i] => *
  • :white_check_mark: [hr] => ----
  • :white_check_mark: [url] => http://google.com ou [google](http://google.com)
  • :white_check_mark: [url] avec une esperluette & : devront etre migré après la suppresion du parseur bbcode
  • :white_check_mark: [code] ou [c] => markdown . Notez que l’actuel parseur 3 couche pete les caractères <>&"' pour cette balise. Ca sera ok a terme.
  • :white_check_mark: [/*]commentaire[*/] : Bidouille [//]: # (commentaire)
  • :white_check_mark: [quote] => <blockquote> plutot > en début de ligne (cassé pour le moment.

A remplacer par des equivalents HTML (pas encore dispo)

  • :white_check_mark: [sub] => <sub>
  • :white_check_mark: [sup] => <sup>
  • :white_check_mark: [s] => <s>
  • :white_check_mark: [acr] => <abbr>
  • :white_check_mark: {# ancre} exemple.
  • :white_check_mark: [center] : Pas grande utilité typographique, et le parser markdown ne l’aime pas du tout => finalement autorisé avec <center>mais il va falloir discuter…

Recoder une extension

  • :white_check_mark: ### Titre # précision de titre
  • :white_check_mark: [picto] => extension sur le modèle :code_picto:
  • :white_check_mark: [warning] et [important] => extension sur le modèle !!! alerte
  • :white_check_mark: [p] => Rendu HTML : <div style="clear:both"></div>.

Balises cassées, à discuter plus tard si il faut recoder une extension au markdown

  • :white_check_mark: [toc2] et autres options de [toc] : suppression des paramètres (à voir plus tard pour la réintégration de left/right
  • :white_check_mark: [email]mail@patate.fr[email] => <mail@patate.fr> (code à re-migrer :exclamation:)
  • :white_check_mark: [email=mail@patate.fr]click here[email] => [click here](mailto:mail@patate.fr) a voir plus tard si on fait une extension plus sympa.

A Supprimer !

  • :white_check_mark: [abs] et [abstract] = Ca sert à quoi ? Selon cet article, ca serait le champ résumé => migration à la main de celles qui restent
  • :white_check_mark: [warn] => [warning]
  • :white_check_mark: [imp] => [important]
  • :white_check_mark: [list] => pas utilisé
  • :white_check_mark: [color] : non-sens typographique, c’est juste pour faire joli. Et le joli est le moche d’un autre.
  • :white_check_mark: [u] (souligné) : non sens typographique, c’est une emphase, mais non intuitive (sur le web, le souligné correspond aux liens cliquables).
  • :white_check_mark: ###c (titre en orange) : pas de sens, la mise en page doit être gérée via le CSS
  • :white_check_mark: [right] (placement du paragraphe à droite) : pas utilisé
  • :white_check_mark: [col] : Donne la charge du rendu au redacteur, ce qui est casse gueule avec la diversité d’écran d’aujourdhui, à supprimer?.

Note : [u] et [color] n’ont pas été modifiés sur les documents perso, car ca impliquerait un changement de rendu.

J’en ai oublié ?

Il existe aussi comme [center]
[left]
[right]
[inline]
Qui sont utilisés pour l’alignement des images dans les docs.

Ce n’est pas a l’interieur de la balise img ?

?

Oui tu as raison!
Donc j ai rien dit…

Center est utilisé pour centrer 3 images sur la même ligne.
Si vous arrivez à faire ça autrement, on peut supprimer, mais sinon…
La mise en page des articles est déjà bien pauvre, et vous voulez supprimer le peu qui a été mis en place dans la V5.
Enfin bref, j’en ai plus rien à faire, je ne perd plus de temps à maintenir les articles.

Merci pour ce retour constructif, dommage qu’il soit emprunt de dépit. Il faut donc reflechir a une solution pour ce cas de figure.

Vous faites bien ce que vous voulez.
Mais si cette balise a été utilisée, c’est que certains l’ont jugé utile. Je précise que ce n’est pas moi qui l’ai demandé.
Donc avant de supprimer une balise à l’aveugle par un robot, le minimum est d’aller voir les documents qui l’utilisent pour voir si elle est utile ou non.

J’utilisais souvent Center pour les photos effectivement.

Non non, on ne souhaite pas une galerie.
On veut que toutes les vignettes soient visibles, quel que soit la largeur de l’ecran, sur plusieurs ligne si nécessaire.
Et les images insérées sont visibles dans le diaporama en cliquant dessus.

Peut-être qu’au début oui. Mais aujourd’hui, on a clairement besoin d’annonces temporaires dans les docs. Avoir deux balises, serait peut-être bien pour différencier un warning permanent (ou quasi) et un warning temporaire. Ton robot pourrait nous sortie la fucking liste des temporaires tous les mois ?

Il y en a simplement un qui est plus important que l’autre (warning > important)
Comme la difference entre les panneaux attention et interdit.
On utilise warning pour les interdictions temporaires, mais c’est aussi utilisé pour les interdictions permanentes.

Pourtant « warning » avec un encart sur fond rose, flache quand même plus que « important » avec juste une bordure orange.
Sur la V5, il y avait un gros picto « STOP » pour warning, et un picto /!\ pour important.
Il faut surement revoir le design de ces blocs, mais l’idée est d’avoir 2 types d’encart pour des infos importantes et « anormales » par rapport aux infos habituelles.
Ces balises ne sont pas toujours utilisés correctement, ce n’est pas parfait.

On peut le faire pour la prochaine version :slight_smile:

Je suis d’accord, j’ai toujours pensé la même chose :slight_smile: mais ce n’est pas super important

2 Likes

Quid des ancres {# xxxx} ?
Voir par exemple Camptocamp.org

Rien à voir avec la migration BBCode, mais on pourrait pas augmenter la taille des titres #### et ##### ? Dans l’exemple ci-dessus, la police de ces titres est plus petite que le corps du texte. Du coup c’est assez illisible.

Warning donne l’impression d’un danger (to warn = mettre en garde), alors qu’ Important n’est pas aussi dramatique.

1 Like

color et souligné d’accord ce sont en effet des balises inutiles pour la mise en page.
center, actuellement pour ce que je connais et que je constate de son utilité dans la mise en page, pour les photos essentiellement, je pense que l’on peut s’en passer aussi sans trop de dégâts visuels.

Je pense qu’il ne faut pas toucher au cas 3. avant d’avoir une solution de mise en page equivalente (plusieurs photos sur une meme ligne).

Ok pour virer 2.

Pour le 2 et le 3 je n’ai pas encore réussi à trouver un exemple d’utilisation de cette balise. Donc je me dis simplement que si elle n’a pas été vraiment utilisée jusqu’à ce jour, doit elle être une cause de retard afin de la maintenir ?
Maintenant je me trompe peut être je n’ai peut être pas, tout simplement, découvert les bons documents me démontrant son utilisation.

Ce ne me gêne pas de supprimer le center, il n’est pas très courant.
De plus, sur mobile le centrage ne change rien par rapport à un calage à gauche car le texte ou l’image prend toute la largeur de l’écran la plupart du temps.
Mais quand on réfléchira à l’amélioration des possibilité de mise en forme, ce sera peut être utile de le remettre.
Mais on ne s’amusera pas à remettre les balises dans les articles qui l’utilisaient, ces articles doivent être refondu de toute façon, s’il ne sont pas caduques.

1 Like