idem
Migration BBcode
cela parait top, syntaxe efficace et assez intuitive.
1 Like
Pas mieux !
Simple d’utilisation et efficace dans le rendu.
Après je ne suis pas qualifier pour me rendre compte de ce que ça implique en arrière boutique.
Faufra faire une requête sur les sorties pour voir combien de sorties comportent déjà ves balises avec !!, afin d’évaluer les effets de bord.
Sinon la suyntace me convient.
A priori, les ancres se retrouvent dans Markdownextra.
https://michelf.ca/projects/php-markdown/extra/#spe-attr
Y’ a des trucs sympas pour nous là-dedans. Implémentable ?
@CharlesB : tu as supprimé des liens V5 dont on peut retrouver le lien V6 :
https://www.camptocamp.org/forums/viewtopic.php?id=260596
Ben oui, c’était un raccourci ppur alléger les url internes à l’édition.
Tu en as supprimé beaucoup ? Car souvent c’est un lien vers la source d’une info sur le forum.
Oui il y a une redirection par le serveur. Tu peux utiliser le modèle de lien pour faire une migration via le robot.
Je suis d’accord pour ne pas réimplémenter [toc 2] et [toc right]
Pour l’instant, il n’y a rien qui fonctionne : [toc N] n’est pas décodée.
L’option N est très utile quand il y a 4 niveaux de sous titres (niveau 2 à 5), avec donc des dizaines de sous titres de niveaux 4.
Le sommaire permet d’accéder rapidement à une section du document. Mais si le sommaire lui même fait 3 pages, ce n’est pas très ergonomique.
Le plus souvent, via le sommaire, on a besoin d’accéder aux premiers niveaux (2 ou 3).
Exemple d’article où il est utile de limiter le nb de niveaux affichés dans le sommaire : Camptocamp.org
Forcément que c’est peu utilisé, vu que l’option right ne fonctionne pas actuellement, et qu’on l’a enlevé dans les articles les plus utiles pour que le sommaire s’affiche !
Mais sur la V5, le toc était très majoritairement utilisé avec l’option « right ». C’était tellement utilisé (on mettait systématiquement l’option right quand on ajoutait la balise toc, et éventuelement ensuite on l’enlevait) qu’à un moment, j’ai même pensé à ce que le sommaire soit calé à droite par défaut, et qu’il faille mettre une option pour le mettre à gauche.
Ca tombe bien, les écrans larges (> 1600px) deviennent la norme sur desktop.
Et on peut très bien faire un CSS qui annule l’option right pour des écrans de largeur inférieure à XXX.
En fait, on pourrait même se passer de l’option right, et toujours caler le sommaire à droite pour les grands écrans, et à gauche pour les petits écrans.
Je confirme que le toc right était standard dans la V5.
Par défaut dans les articles c2c, il s’est avéré plus intéressant de mettre le sommaire à droite.
Je confirme également l’utilisation du Toc N pour les cas indiqués par Bubu.
Néanmoins, les articles encyclopédiques collaboratif n’ayant pas pris, l’impact de ces balises est mineur à comparer du topoguide.
Cela semble idéal ; à charge à l’UI quelle qu’elle soit d’en tirer le meilleur parti
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.
Dans un article ?
Ce n’est pas le cas sur c2c.
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).
Pour moi, un sommaire ne sert pas nécessairement à grand chose dans ce type de document/contexte.
1 Like
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
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
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.
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).