Migration BBcode

#1

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é ?

  • …
Mise à jour du 18 janvier
C2C interpellé par les équipeurs
#2

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

#3

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

?

#4

Oui tu as raison!
Donc j ai rien dit…

#5

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.

#6

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.

#7

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.

#8

J’utilisais souvent Center pour les photos effectivement.

#10

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.

#12

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 ?

#13

Dans ce cas, je verrai une seule balise, avec un paramètre optionnel :

<warning> Warning permanent </warning>

Et

<warning stop="2017-10-02"> Warning temporaire </warning>

Et un batch peut sortir facilement la liste des temporaires.

Du coup, re question : quelqu’un voit une différence entre important et warning?

#14

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.

#16

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.

#17

On peut le faire pour la prochaine version :slight_smile:

#19

C’est le nom que je ne trouve pas clair : pour moi, la comme ca, je ne sais pas si le mot warning est plus oui moins « important » que important.

Danger et Warning me semblent plus clairs.

#20

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

2 Likes
#21

Ok, je met ca dans un coin de ma tete et je ferai faire la migration par le robot un de ces jours

#22

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.

#24

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

1 Like
#26

Bonjour à tous,

J’ai besoin de vos avis sur le passage suivant :

A supprimer ?

Le souci des trois balises ci dessous, c’est qu’elles sont d’une part très limitées, et d’autre part trop facile d’accès au rédacteur occasionnel qui fait alors sans le savoir des erreurs typographiques. Dans le futur, il n’est pas impossible de réintroduire une syntaxe permettent tous les raffinements de mise en forme. Mais afin d’en limiter l’usage, et permettre plus de chose, cela devrait etre via une syntaxe plus puissante, plus robuste, et plus pérenne.

  • [center]
    • Pas grande utilité typographique, et le parser markdown ne l’aime pas du tout
  • [color]
    • non-sens typographique, c’est juste pour faire joli. Et le joli est le moche d’un autre.
  • [u] (souligné)
    • non sens typographique, c’est une emphase, mais non intuitive (sur le web, le souligné correspond aux liens cliquables).

Point important à garder en tête : devoir les recoder maintenant en l’état va retarder d’autant le rétablissement du parseur de code.