Recherche avancée

Sur d’autres sites (7047)

• Anomalie #4623 : Styles des fieldset dans l’espace privé

  19 avril 2021

  Je pense qu’il faut garder la règle un fieldset == un div.editer en plus gros.

  Oui, ça se tient aussi. Je crois avoir vu cette structure utilisée sur un form de la dist d’ailleurs.
  Pour les fieldsets on pourrait employer un nom qui rappelle que ça fait partie d’un .editer-groupe non ? Genre .editer-fieldset par exemple, au lieu de .fieldset tout court ?

  Je signale pour pas oublier et ne pas exclure cette possibilité que certains formulaires ont besoin de plusieurs .editer-groupe à la racine, avec des choses entre. Par exemple pour le multi il y a des .boutons au milieu du formulaire :

  form
    .editer-groupe
    .boutons
    .editer-groupe
    .boutons
  

  On peut imaginer aussi un formulaire qui aurait besoin en cours de route d’un groupe de saisies en 2 colonnes, donc de plusieurs .editer-groupe consécutifs :

  form
    .editer-groupe
    .editer-groupe.deux_colonnes
    .editer-groupe
  

  Et aussi entre le legend et le .editer-groupe d’un fieldset, la charte permet d’insérer des explications (et autres ?).

• Anomalie #4623 : Styles des fieldset dans l’espace privé

  17 avril 2021, par RastaPopoulos ♥

  Alors c’est justement ce que je ne voulais pas générer au moins pour les groupes racines : là on se retrouve pour les fieldsets racines avec 2 bordures collées, ce qui fait super lourd visuellement il me semble : bordure du form et direct collé bordure du groupe.

  Je détaille l’argument du foncé qui était volontaire : quand il y a des décorations claires, certaines personnes (et suivant la qualité des écrans) ne les voient pas ou peu, mais ce n’est pas grave si ce n’est que de la déco. Alors qu’un élément foncé va être vu par un pourcentage bien plus grand de personnes. Comme là il s’agit d’une indication visuelle utile, et non pas juste de décoration, je trouvais donc important que ce soit foncé pour que le max de gens les voit.

  Pour les barres horizontales, là aussi c’était voulu de les enlever, afin d’alléger visuellement : là on se retrouve de nouveau avec des "cadres enfermants" de partout et donc visuellement (quand on a des yeux qui voient toutes les lignes) on a dès le premier coup d’œil cette impression de "cadres dans des cadres dans des cadres". Alors que le but des simplifications de Tcharlss était justement de minimiser le plus possible cette impression, et du coup mon but était de trouver une solution pour les fieldsets qui n’en rajoute pas dans ce domaine.

  Pour la bordure sur la droite b_b, je vais faire un essai, mais le premier truc qui me vient c’est que justement on lit à gauche, et que seulement une indentation sans bordure à gauche c’est beauuuucoup plus faible pour voir du premier coup quels champs sont regroupés avec quels autres. Ça va faire qu’on va voir le regroupement que dans un deuxième temps au lieu de le voir au début de chaque ligne.

• Evolution #4366 : Ajouter systématiquement un attribut id sur les intertitres

  11 mars 2021, par Maïeul Rouquette

  Je ne sais pas lequel des deux est activé sur contrib, mais il y a une différence notable : les liens font remonter au sommaire, au lieu d’envoyer vers les intertitres eux-mêmes.

  c’était le plugin sommaire alors. Depuis une version récente on peut configurer (mais ca pose des questions si jamais 2 sommaire sur la même page, etc, voir les logs de commit

  Pour revenir au fond du sujet, moi je suis aussi pour les id sur les intertitres, mais cela pose tout de même une question concernant leur perennité. Car soit on se base sur l’ordre des intertitres, soit sur le texte, mais dans tous les cas si la personne les change (correction de coquille, amélioration de la structuration), on l’a dans l’os.