3.26 Règles-Front

3.26.1 - Angular

Toutes les bonnes pratiques poussées par Angular doivent être respectées. C’est pour cette raison que, régulièrement, un projet Angular est créé de zéro avec Angular-cli. Ainsi toutes les règles (notamment tslint) sont réintégrées au projet front.

En plus de ces bonnes pratiques, des choix ont été faits sur le projet :

  • aucun fichier source ne doit être vide (notamment les fichiers SCSS bien souvent vides)
  • les CSS de chaque composant ne sont pas encapsulées (cf. documentation Angular associée).
    • Pour ce faire, tout composant Angular doit avoir l’attribut encapsulation: ViewEncapsulation.None
    • Tout sélecteur CSS présent dans un fichier SCSS doit être unique
  • tout composant Angular doit être standalone. Autrement dit, il est un module à lui tout seul (cf. documentation Angular dédiée). Attention donc aux dépendances cycliques (d’où la séparation entre les contenus simples et riches car contenu->contenuIdentite->contenu).

3.26.2 - DSFR

Tous les développements doivent respecter la charte graphique DSFR et RGAA :

  • en premier lieu, aucune CSS de la DSFR ne doit être surchargée.
  • la structure HTML des composants DSFR (cf. documentation officielle et toute note, remarque et changement doivent être indiqués dans ce chapitre.
  • concernant le RGAA et les règles Aria :
    • tout input/select/textarea contient un attribut aria-describedby dont la valeur est l’ID d’une balise data-fmk-messagesvalidation
    • toute balise label contient un attribut for contenant l’ID du champ de saisie associé
  • tout texte doit être présent dans une balise P , SPAN, Hx, A, LABEL => A TRAITER : upload.cadreGlisseDeposer
  • un formulaire ne doit jamais contenir deux boutons fr-btn (donc primaire par défaut) sans que l’un d’eux soit fr-btn–secondary, voire fr-btn–tertiary (cf. documentation officielle).
  • la classe fr-container ne doit pas être utilisées plusieurs fois les unes dans les autres au risque de cumuler une marge de chaque côté de l’écran. Les seuls usages autorisés sont : l’entête, la modale du menu, le conteneur de page, le pied de page haut et le pied de page bas.
  • les messages d’erreur sous chaque INPUT doivent respecter les règles suivantes :
    • chaque composant data-fmk-messagesvalidation doit être appelé sur un P pour s’approcher de la charte DSFR et aussi obtenir une marge stable sous le champ de saisie
    • l’attribut aria-live=“assertive” est obligatoire car il permet d’indiquer au lecteur d’écran que cette zone doit être lue si elle change

Bugs connus :

  • 30/04/2024 - connexionbrouillon : la case à cocher permettant d’afficher le mot de passe devrait être une icône d’oeuil selon la documentation mais ce n’est pas le cas.
  • 30/04/2024 - contenuradio : la marge sous le composant est plus grande que pour les autres composants. Ceci vient de la balise FIELDSET qui doit être utilisée pour regrouper les champs associés aux valeurs possibles. Les autres types de contenu n’ont pas de Fieldset donc pas cette marge supplémentaire.
  • 02/05/2024 - entete : la liste des liens présents dans l’entête ne sont pas bien recopiés par le JS DSFR dans la modale au passage en mobile. Il est nécessaire de recopier explicitement les liens dans la modale.
  • 02/05/2024 - entete : si les éléments de l’entête sont copiés dans la modale (cf. point précédent), le sélecteur de langue ne fonctionne pas car la liste des options ne s’affiche pas dans la modale.

3.26.3 - Material versus DSFR

En théorie, seule la librairie DSFR devrait être utilisée pour construire les écrans des démarches et des applications d’administration.

Mais la DSFR manque de plusieurs composants : une barre de progression (utilisée dans les uploads de composant) et une autocompletion (utilisée partout).

Donc Material (historiquement utilisé avant la DSFR) a été conservé pour ses usages exclusivement.