Migration BBcode

#179

Est ce qu’il est prévu de traiter les [col] Camptocamp.org

1 Like
#181

La balise [col] ne sert pas à faire du vrai colonage, avec texte qui coule d’une colonne à l’autre. Mais simplement à mieux utiliser l’espace sur grand écran.
Sur la V5, c’était de simples div avec un width fixé en % et des marges en % aussi, qui s’empilaient sur la largeur.
Sur tablette et mobile, on mettait un width à 100% et des marges à 0, et on n’y voyait que du feu (même rendu que sans [col]).
Je suis d’accord qu’il faudrait s’en passer. Mais il est utile d’avoir des syntaxes pour mieux utiliser l’espace.
Sur la V5, ça servait aussi à mettre un encart de texte à droite, autour duquel le texte normal s’écoule. Le défaut est que sur mobile cet encart se retrouvait en début de texte, alors qu’il a sa place à la fin. Mais avec le flex on peut faire ce genre de déplacement de bloc entre desktop et mobile. Mais bon on n’a quasi pas utilisé cette possibilité.

#182

ok pour ne pas recoder cette balise.

#183

Compte tenu de nos difficultés importantes à remettre les balises, et donc un topoguide dans un état perfectible pendant plus d’un an, je suis partisan de la solution la plus pérenne.

La stratégie V5, consistant à développer des balises, au cas par cas, sans se poser la question globalement, notamment en terme de maintenance sur le long terme, était manifestement une erreur.

Les contributeurs voulant améliorer significativement la mise en page/forme de ces pages, apprendront, ou non, à utiliser la syntaxe HTML. La syntaxe HTML n’est probablement pas beaucoup plus compliqué à apprendre que les balises [col] Camptocamp.
Avant tout, il faut prendre en compte la pérennité du système. On ne peut/doit pas avoir le topoguide en vrac pendant plus d’un ans tous les 10 ans, parce qu’on s’est fait plaisir avec une balise spécifique.

#184

Je voudrais revenir sur les L#.
Qu’est ce qui cloche dans Camptocamp.org ?

Compte tenu de ce qui va être fait, est ce que le topo est censé redevenir lisible (et utilisable) ? Si je n’ai rien raté, il y a du L#~, du L#’ et du L#_
Avec le « recul », je suis vraiment d’avis de simplifier ces topos (ou du moins d’utiliser à minima les balises L exotiques).

#186

J’ai remplacé la longueur ’ par une longueur normale. Il n’y a qu’une longueur concernée (c’est différent de certaines voies où il y a une longueur de liaison après chaque longueur grimpante).
Comme le schéma ne numérote pas les relais pour cette voie, ça ne pose pas de problème.
Et en plus, ça fait que le n° des relais communs avec la Face E est le même (3 derniers relais).

J’en ai profité pour remettre aux normes la voie de Face E : y avait du boulot ! Il manque quand même une colonne avec le nb de pitons en place dans chaque longueur. Mais il n’y a pas assez d’infos précise (juste « peu » ou « nombreux »), et c’est peut être inutile si le nb de pitons change à chaque répétition.
Par contre pour les 2 voies, il est indiqué qu’il y a des spits : ce sont des goujons ou des chevilles autoforeuses ?

#188

Bon, et sinon, [col]? D’autres avis?

Pour info, il a une cinquantaine de doc qui la contienne.

#189

Faire au plus simple à réaliser.

#190

Je suis en train de corriger des balises dans mes sorties (italique, gras, soulignement et quelques liens) puisque cela ne s’est pas fait automatiquement !
y’ a pas moyen que ces sorties n’ apparaissent pas de nouveau en page d’accueil ? (il m’en reste 150 à vérifier)

#191

Inutile de t’embêter à corriger à la main !
C’est juste que certains champs n’ont pas été corrigés. Il faut que le robot les corrige.
Il s’agit au moins des champs texte « Conditions » et « Commentaire sur l’accès », mais il y en a peut être d’autres.

Pour l’affichage sur la home, il s’agit d’un bug. Apparemment, la première fois qu’on modifie le texte d’une sortie créée sur la V4 ou la V5, ça entraine un affichage sur la home.
Un exemple de modif : Camptocamp.org

#192

Ok, merci.
Je vais arrêter là. Vu la météo, ça occupait bien.

#193

Hello @stephfb,

En effet, je n’ai pas encore passé sur les docs persos (pour une raison technique). Je les ferais en tout dernier.

#194

Dans l’aide sur la mise en forme du texte, j’ai déplacé la section concernant les sous-titres en tête de l’article.
En effet, s’il y a 1 chose à savoir, c’est l’utilisation des sous-titres.
Il ne faut pas utiliser la mise en forme des caractères (gras, souligné, etc) pour faire un sous-titre, mais utiliser uniquement la balise de sous-titre. Normalement, on n’a rarement besoin de mettre en forme des caractères. Par contre on a toujours besoin des sous-titres, dès que le document contient un peu d’info, pour le structurer.
La balise de sous-titre permet de générer du html comportant des indications que c’est un sous-titre. Ces indications de structure du texte, outre la possibilité de changer le style des sous-titres via une modif de design, permettent d’améliorer le rendu dans certains cas, par exemple avec les navigateurs conçus pour les handicapés.

#196

Ce serait bien de sauvegarder la liste des articles qui contienne des col.

J’ai essayé d’utiliser un <div>. Ca fonctionne, mais si le <div> contient du L#, ça ne décode pas le L# et ça met tout au km.

#197

Oui, le code contenu dans la plupart des balises HTML n’est pas interprété. Il faut vraiment éviter pour le moment de les utiliser, tant qu’on a des inconnus la dessus.

#198

Bon, j’ai une petite nouvelle :

Ce bug est hyper pénible à fixer, ca demande d’aller bidouiller loin dans le parser, sans garantie que ca soit vraiment stable et rigoureux. C’est du coup bien plus simple et stable de recoder une extension.

En pratique :

  • La balise <span id="ancre-fixe>` pourrait être autorisée ailleurs que dans un titre. Mais je recommande très vivement de l’interdire si nous n’en avons pas l’usage. Il y a des effets de bord pénibles à trop permettre l’utilisateur de choisir des id, cf le bug de la page qui ne s’affiche plus.

  • La syntaxes suivantes pour les titres seront valides :

    Titre simple

    Titre avec # emphase

    Titre avec un id fixe {#id-fixe}

    Titre avec # emphase et avec un id fixe {#id-fixe}

  • @rabot se chargera de retransformer dans l’autre sens les balises <span id="id-fixe"></span> vers {#id-fixe}

Ok pour tout le monde (extension, et interdiction du span) ?

Désolé pour l’aller-retour :confused:

#199

Ok pour moi.
On préfixe quand même l’ID ?

#200

(Pour les autres, c’est une discussion technico-technique qu’on a sur la ML de dev.)

Le sujet est annexe mais oui, il va falloir faire quelque chose pour ce problème, on ne peut pas se permettre de péter les pages avec un markdown qui semble totalement anodin. D’ailleurs, tu n’as pas donné ton avis sur la ML :wink:

#201

PI, pas d’opposition, bye bye balise [col]!

…

Elle n’est plus.

#202

amen!