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

Open
opened 4 months ago by maieul · 11 comments
maieul commented 4 months ago
Collaborator

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

image

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 ....

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 ![image](/attachments/35101fd3-e0ba-4787-9658-d0acb73adc02) 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 ....
maieul added the
bug
label 4 months ago

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

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

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

  1. En amont du passage au gabarit de mail
  2. 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

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 1. En amont du passage au gabarit de mail 2. 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.

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.
Poster
Collaborator

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

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

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.

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 correction 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 que ça régresse 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.

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 correction 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 que ça régresse 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.
Poster
Collaborator
  1. Oui c'est en lien avec https://git.spip.net/spip-contrib-extensions/saisies/pulls/103
  2. oui sur on devrait voir sans les styles, d'où notamment le passage en strong que je suggérais
  3. j'ai les plugs gros doutes quand à l'affichage correcte des legend/fieldset dans les n lecteurs mails qui existent
  4. 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)
  5. je suis d'accors qu'avoir des vues qui renvoient des resultats variables selon le cas c'est pas terrible.

Complément :

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

1. Oui c'est en lien avec https://git.spip.net/spip-contrib-extensions/saisies/pulls/103 2. oui sur on devrait voir sans les styles, d'où notamment le passage en strong que je suggérais 3. j'ai les plugs gros doutes quand à l'affichage correcte des legend/fieldset dans les n lecteurs mails qui existent 4. 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) 5. 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
Poster
Collaborator

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

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

image

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(’)'
		)
	);
et donc j'ai médit sur les lecteurs mails et les fieldset voilà ce que ca rend sur thunderbird, mais aussi evolution ![image](/attachments/277bb97b-5372-41bf-bead-c57c68280d4a) 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(’)' ) ); ```

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

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.

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 : https://git.spip.net/spip-contrib-extensions/saisies/pulls/103#issuecomment-6754 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.
Poster
Collaborator

oui, c'est ca.

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

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

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
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.