Bug d'affichage sur les titres de fieldset dans les notif mail #70

Hop,

depuis les changements (dument justifiés) introduits par @nicod_ dans le markup des vue de fieldset, on obtient un petit bug d'affichage dans les notifs mails.

ca peut être parfois genant.

Cf la capture d'écran

Vie quotidienne est le legend du fieldset, mais comme il n'est plus en h3, bah il ne parait plus marqué physiquement dans la notif mail, et on a l'impression que c'est la suite du texte d'au dessus.

Hum, du coup je ne sais pas ....

image.png

38 KiB

Il faudrait peut être lui mettre du style inline, uniquement pour le mail ?
Genre style="font-size: 1.2em; font-weight: bold;" ?

Oui, peut être. Ce qui m'embete c'est que cela rajoute de la complexité pour la generation des vues (qui pour l'heure n'ont pas de d'endroit où l'on peut facilement se brancher).

Je ne sais pas non plus trop comme cela si on doit gérer cela

En amont du passage au gabarit de mail
Dans le gabarit de mail

Si 1. on fait profiter toutes les surcharges.

Et puis il y a un truc qui m'interroge aussi sur la semantique.

Pourquoi les labels sont en <strong> dans les vues SAUF pour le label/legend des fieldset

J'ai bien conscience que c'est pas simple.

Pour le strong effectivement, il faudrait l'ajouter dans la vue fieldset, y'a pas de raison, sémantiquement c'est un label aussi.

bon, partons sur cette piste, et je ferais des essais ce week-end.

une solution simple soit que les vues puisse recevoir #ENV{pour_envoi_mail}, et comme cela on peut, vu par vue, choisir d'inserer le inline.

Ca restera donc aux vues de définir le style, si elle sait qu'elle est destinée à être envoyée par email.

C'est rapport au ticket où on réfléchissait à quel markup pour les vues des groupes etc ?

Il y a peut-être encore de l'amélioration à trouver car en théorie un markup sémantique doit alors se lire correctement sans aucun style, avec les styles par défaut du navigateur. Et les styles ajoutés sont pour décorer mieux suivant son site.

Là si sans style ajouté, la lecture de base (donc pour un paquet de gens) n'est justement plus sémantique, alors c'est que notre code n'est… pas assez sémantique : il ne l'est plus que pour les personnes en moindre nombre qui naviguent en lecteur d'écran. Du coup c'est un peu dommage d'avoir amélioré pour ces personnes mais en régressant pour la majorité.

Je ne retrouve plus le ticket (tu peux mettre son lien si t'as ?), mais de mémoire yavait deux grands choix :

des div (ou autre) avec des role aria "group" etc
utiliser fieldset/legend aussi, car c'est accepté même en dehors des forms

Le premier a été choisi car plus facile à styler que les fieldsets qui sont effectivement un peu particulier. Mais du coup pour ce choix CSS, on perd en sémantique par défaut (c'est plus que du div de base pour la majorité des lecteurices).
Peut-être qu'il faut finalement utiliser fieldset : ça va bien faire un affichage connu de tout le monde par défaut sans aucun style, et dans l'admin on peut peaufiner ?

En tout cas je ne suis carrément pas chaud pour que les vues aient des infos d'exception en environnement, et que ça fasse ci ou ça selon. Les vues ne devraient pas avoir de rapport avec l'utilisation, ça génère un bon markup sémantique, et les styles c'est à part.

Oui c'est en lien avec spip-contrib-extensions/saisies#103
oui sur on devrait voir sans les styles, d'où notamment le passage en strong que je suggérais
j'ai les plugs gros doutes quand à l'affichage correcte des legend/fieldset dans les n lecteurs mails qui existent
Sans compte qu'en plus je crois que facteur est capable de gerer correctement le passage de strong à ** lorsqu'il genere un fichier texte, pas certain qu'il le fasse pour les legendes/fieldset (mais on pourrait à la rigueur gerer cela, vu que c'est un problème SPIP)
je suis d'accors qu'avoir des vues qui renvoient des resultats variables selon le cas c'est pas terrible.

Complément :

si j'en crois https://www.campaignmonitor.com/css/style-element/style-in-head/ et https://www.campaignmonitor.com/css/text-fonts/font-size/ la plupart des lecteurs lisent correctement font-size dans un style en tete.

Du coup proposition
a. Les legend passent en bold lors de la vue
b. On style en css pour les emails, et même si on n'a pas le css, ca passerait quand même, juste on aurait pas de font-size variable

et donc j'ai médit sur les lecteurs mails et les fieldset

voilà ce que ca rend sur thunderbird, mais aussi evolution

a tester avec d'autres clients mails ?

Ci dessous le code pour generer le mail


<?php

$envoyer_mail = charger_fonction('envoyer_mail', 'inc');
$envoyer_mail('toto@truc.com', 'un sujet',
	array(
		'text' => 'Le corps de message',
		'html' => '<strong>cest important</strong>, <fieldset><legend>c\'est une legende</legend> et ca c\'est le corps du fieldset</fieldset>',
		'from' => 'toto@truc.com',
		'nom_envoyeur' => 'Un envoyeur avec une apostrophe U+2019(’)'
		)
	);

image.png

38 KiB

Mmmh en fait je pense qu'il manque même un truc dans la premère solution choisie. Le choix étant 👍 :

soit un vrai fieldset même hors form, qui vaut de base comme un "groupe logique" pour les technologies d'assitance
soit un div avec un role=group et un labbelledby pour lier le titre comme expliqué ici avec le lien doc : spip-contrib-extensions/saisies#103

Alors que là ya que la liaison du titre au final.

Donc soit faudrait finalement repasser à un vrai fieldset hors form (qui est autorisé), et on se débrouillera pour styler, mais au moins même sans aucun CSS, tous les clients web + mail vont l'afficher comme il faut.
Mais à minima avec la version actuelle faut ajouter le role="group" sur chaque div représentant un fieldset.

oui, c'est ca.

C'est quoi concrètement la difficutà à styler les fieddset?

le legend et le fieldset se comportent particulièrement, c'est pas comme deux blocs parent-enfant classiques (div div, ou div p, etc)

mais pour les usages courants c'est 95% pour la lecture des réponses en admin, les vues des champs extras en admin aussi, les récaps des multi étapes désormais et les emails, donc je sais pas si c'est super grave, c'est rarement dans un truc où on veut faire avec un design de ouf

Bon pour l'instant après relecture, je suis encore sur le même avis :

améliorer l'accessibilité ça doit être pour tout le monde, pas juste pour la minorité qui lit en lecture d'écran
du coup avoir des attributs aria MAIS un code NON sémantique (div div div) qui sans CSS va s'afficher n'importe comment chez les gens, ce n'est pas la bonne option, il faut revenir dessus
le code devrait être sémantique de base, et donc s'afficher compréhensiblement sans aucun style CSS, et s'il faut en plus on ajoute des attributs aria

En conséquence, ça veut dire utiliser des fieldsets même hors form quand on doit grouper des infos ensemble avec un titre (sans que ce soit pour autant des intertitres HX car insérés à n'importe quel niveau). Et après on se débrouille pour afficher ça le moins moche possible dans l'admin (si possible ça devrait appliquer directement les styles des fieldsets imbriqués des formulaires, à priori).