C’est simplement le champ matos qui n’est pas affiché à la prévisualisation.
Il y a un ticket il me semble.
Migration BBcode
je prends le lot 1
3 Likes
Lot 2 fait.
peux pas modifier le CR d’accident de Rozenn faut être modo sans doute
Oui. Tu ne peux modifier que les documents collaboratifs (itinéraires, sommets, parking, article …)
Je m’occupe du lot 4 (en cours)
bah du coup le lot 3 c’est uniquement en fr …
Pas de souci, je ferais des repasses.
Lot 4 fait.
( j’ai l’impression que parfois certaines « citations » sont plutôt de la mise en forme. Bon…, j’ai simplement appliqué le principe > au lieu de /quote/ )
A+
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 ?
Bon, et sinon, [col]? D’autres avis?
Pour info, il a une cinquantaine de doc qui la contienne.
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)