Est ce qu’il est prévu de traiter les [col] Camptocamp.org
Migration BBcode
1 Like
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é.
ok pour ne pas recoder cette balise.
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.
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).
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 ?
Faire au plus simple à réaliser.
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)
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
Ok, merci.
Je vais arrêter là. Vu la météo, ça occupait bien.
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.
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.
Ok pour moi.
On préfixe quand même l’ID ?
amen!
Par contre, il va falloir nous indiquer comment faire le job en html.
je ne connaissais pas l’existence de [hr] auparavant, en tous les cas le même job était fait par [—], et je ne crois pas que cette balise ait été migrée. Est-ce possible de l’ajouter à la liste ?
ben non, pas de doc, et elle ne figurait pas dans une dernière version de l’article d’aide bbcode. Mais je peux t’assurer qu’elle existait et fonctionnait.
Cette balise n’existait que sur le forum de la V5. Utilie principalement pour séparer un commentaire de la modération du reste du post.
Je ne l’avais pas mis dans le topoguide, car dans un doc c’est la plupart du temps inutile. Quand on a besoin de séparer un doc en plusieurs parties, c’est souvent qu’une organisation via des sous-titres est nécessaire. Et donc il faut utiliser les sous-titres, c’est plus clair pour le lecteur, et plus pratique (sommaire et ancre possible).
Sur le web en général, la balise hr est souvent utilisée pour avoir le même comportement que la balise [p] : autant utiliser la balise [p].
1 Like