Les articles publiés sur le site

  • Anomalie #4736 : nouveau date picker et la modalbox ou les crayons dans le public

    18 avril 2021, par b b

    Et donc si un form d'un objet à un champ pour choisir une date, que ce soit de la dist ou editer_evenement d'Agenda ou autre, ça doit marcher qu'on soit dans l'admin ou qu'on l'utilise ailleurs.

    Je ne voudrais pas parler à la place de Cedric, mais si je ne me trompe pas, c'est exactement ce qu'il décrit par :

    4/ en pratique inclure le inc-dateur dans un formulaire marche également dans le site public, que le formulaire soit chargé dans la page principale ou dans un formulaire chargé dans une brique ajax, et cet usage s'est répandu, notamment via saisies et formidable
    5/ c'est la seule et unique méthode officielle supportée, toute autre relève du hack

    Le dateur fonctionne si le formulaire qui l'utilise fait l'inclure qui va bien, ici tofulm tente d'inclure ce js dans le head de toutes les pages de son site, ce qui me semble un tout autre usage.

  • Anomalie #4721 (Fermé) : cadre trop petit au moment d’une nouvelle installation, installation impo...

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

    18 avril 2021

    Bon stop (ou pas) !

    Il semble que les blocs fieldset ne peuvent pas parfaitement se styler seuls. Manifestement c'est assez récent que les navigateurs acceptent un display:flex; dessus par exemple.

    J'ai fait quelques tests en partant du formulaire de préférences des menus (tiens d'ailleurs ce formulaire a des div.editer sans div.editer-groupe parent (à corriger !)
    Il contient un fieldset + .editer-groupe.deux_colonnes (columns: 2)

    Ce que j'ai testé (sous macOS avec FF, Safari, Chrome & Opéra) : la formule suivante (enlever le .editer-groupe interne et le monter sur le fieldset)

    fieldset.editer-groupe
        legend
        div.editer
        div.editer
        ...
    

    1) Si on applique un columns: 2 sur ce fieldset,
    - Firefox & Safari : conservent le legend, passent le reste en 2 colonnes
    - Chrome & Opéra : ignorent et conservent donc un affichage 1 colonne.

    2) Si on applique un display: flex; flex-wrap: wrap sur ce fieldset
    - Tous : le legend est conservé comme tel
    - le reste passe effectivement en flex (permettant donc de mettre plusieurs .editer sur la même ligne)

    Déjà je suis étonné que Flex semble fonctionner, contrairement à ce que dit https://caniuse.com/mdn-html_elements_fieldset pour tous les Gecko. Et Edge aussi est indiqué en non fonctionnel.

    Donc du coup… je me dis que le .editer-groupe dans le fieldset à encore du sens stylistique.
    Ce qui pour le coup ne nous arrange pas forcément, mais ça évite aussi de casser un truc de plus dans cette structure html en le laissant.

    Donc du coup, on en reviendrait peut être à "fieldset.editer-section" ou "fieldset.editer-fieldset" ou "fieldset.fieldset" ou "fieldset" (sans rien)…
    J'utilise .editer-section ensuite (mais peut importe)

    A) fieldset.editer-section > div.editer-groupe

    (le plus proche de l'actuel je pense)

      div.editer-groupe
          div.editer
          ...
      fieldset.editer-section
        legend
        div.editer-groupe
            div.editer
            ...
    

    B) fieldset.editer-groupe > div.editer-section

    L'autre possibilité si ça facilite vraiment le css, c'est d'inverser les classes (avec l'ennui principal de du coup devoir reprendre l'existant)

      div.editer-groupe
          div.editer
          ...
      fieldset.editer-groupe
        legend
        div.editer-fieldset
            div.editer
            ...
    

    B) fieldset.editer-groupe.editer-section > div.editer-groupe

    Ou du doubler d'une autre classe

      div.editer-groupe
          div.editer
          ...
      fieldset.editer-groupe.editer-section
        legend
        div.editer-groupe
            div.editer
            ...
    

    Mais dans ce cas là je trouve cela redondant (fieldset.editer-section me parait suffisant, si on doit effectivement mettre un classe css dessus)
    Le plus ennuyant est peut être de devoir annuler des styles CSS du .editer-groupe dans .editer-section > .editer-groupe ;

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

    18 avril 2021

    on peut mettre .editer_beatles parce que c'est un groupe de légende.
    /me => []

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

    18 avril 2021

    Dans quelle mesure Tcharles il y a besoin du .editer-groupe dans le fieldset.editer-surgroupe ?

    Et bien écoute, maintenant que tu le dis, je ne sais pas :)
    La sémantique de la balise fieldset et de la classe .editer-groupe est finalement la même oui, ton exemple semble plus logique.
    Des fois même si c'est pas bien, on n'a pas d'autre choix que de rajouter un conteneur pour faciliter ou permettre des choix stylistiques, mais là ça semble pas nécessaire.

    Je serais incliné à ajouter une classe complémentaire sur les fieldset.editer-groupe quand même, pour distinguer les « groupes avec légende » des « groupes lambdas ». Dans les CSS on peut certes se reposer sur la balise, mais ça simplifierait et serait un peu plus propre. Une déclinaison de .editer-groupe plus sémantique pour dire que c'est une variante ? Je mets « editer-groupe-xxx » dans l'exemple pour l'instant. Sinon la bonne vieille classe .fieldset.

    form
      div.editer-groupe
        div.editer
        div.editer
        ...
    
      fieldset.editer-groupe.editer-groupe-xxx
        legend
        div.editer
        div.editer
    
      div.editer-groupe
        div.editer
        fieldset.editer
          .choix 
        fieldset.editer-groupe.editer-groupe-xxx
           legend
           div.editer
           div.editer