Problème d'emoji lors du rendu sur webkit - Problème avec la façon dont le HTML est rendu

[Crius]

Nous avons beaucoup d’utilisateurs qui utilisent des appareils Apple et/ou des navigateurs basés sur WebKit qui signalent des problèmes lors du défilement des sujets, au point que le forum devient inutilisable.

Un exemple, capturé en vidéo ici.

Après avoir pas mal creusé, il semble que la cause la plus probable soit la façon dont WebKit est… comment dire poliment… nul pour gérer le redimensionnement des images.

Cependant, cela a également permis de remarquer comment les emojis sont rendus dans le HTML “cuit” et j’aimerais des éclaircissements car peut-être que je manque une configuration que j’aurais pu faire et qui aurait empêché cela.

En vert, vous pouvez voir la taille originale de l’emoji.

En azur/cyan/peu importe, les attributs par défaut ajoutés par Discourse lors de la “cuisson” du contenu.

En rouge, le CSS ajouté par le plugin que j’ai écrit qui :

• importe les emojis (ils sont assez nombreux)
• ajoute du CSS personnalisé pour qu’ils s’affichent correctement car ils ne sont pas tous “20 par 20”

Maintenant, j’ai effectué un test simple. J’ai supprimé du champ cooked dans la base de données pour ce sujet, tous les width="20" height="20" et j’ai demandé aux utilisateurs de réessayer et de visualiser le sujet, de faire défiler, de répondre même si quelqu’un ajoute de nouveaux messages, mais sans utiliser d’emoji afin de ne pas réinjecter ces deux attributs dans le rendu HTML des emojis.

Apparemment, c’est ce qui causait les problèmes sur WebKit, car tous les rapports que j’ai confirment que maintenant que ces deux attributs sont supprimés, il n’y a plus de problème avec le défilement.

Alors, y a-t-il un moyen d’empêcher Discourse d’ajouter ces paramètres ? Pourquoi Discourse suppose-t-il que chaque emoji sera “20x20” et, en plus, l’impose-t-il via un attribut HTML au lieu d’utiliser du CSS ?

Merci.

[Canapin (Coin-coin le Canapin)]

@Crius

Nous avons beaucoup d’utilisateurs qui utilisent des appareils Apple et/ou des navigateurs basés sur WebKit signalent des problèmes lors du défilement des sujets, au point que le forum devient inutilisable.

J’ai pu le reproduire sur mon iPad mais pas sur Chrome sur ordinateur.

Je fais défiler vers le haut, et la chronologie revient au message précédent, ce qui rend difficile de la dépasser et d’aller plus loin dans la chronologie.

Mais j’ai du mal à le reproduire de manière cohérente. J’étais bloqué au message n°1955, mais après avoir pu remonter au-delà, si je redescendais et remontais à nouveau, cela ne me bloquait plus

[Crius]

La raison est que cela se produit chaque fois qu’un nouvel emoji est en cours de “chargement paresseux” et que les attributs de taille sont rendus.

Une fois qu’il est rendu, le problème ne se produit pas. Mais si vous parcourez un sujet avec de nombreuses réponses et dans lequel les emojis sont utilisés assez souvent, vous verrez constamment ce comportement se produire et cela rendra l’utilisation de Discourse impossible.

Nous avons réussi à le “corriger” dans notre thème personnalisé, mais je pense que cela devrait être abordé dans le thème par défaut également, ou mieux encore, dans la fonction qui traite les publications, car je ne vois aucune raison pour que ces attributs HTML liés à la taille soient appliqués au lieu d’utiliser du CSS simple.

J’ajouterai que tous les navigateurs pour iOS semblent utiliser webkit, donc ce sera un problème principalement pour les appareils Apple. Je ne suis pas un expert en la matière, alors prenez cela avec des pincettes. Des tests supplémentaires seraient nécessaires.

[awesomerobot (Kris)]

@Crius

Pourquoi discourse suppose-t-il que chaque emoji sera « 20x20 » ?

C’est parce que tous les emojis unicode standardisés sont conçus pour s’intégrer dans un carré, et nous supposons que les sites veulent que leurs emojis aient une taille cohérente, d’une manière qui fonctionne avec le texte et les autres emojis si cette théière faisait 50x50, cela créerait un énorme espace entre les lignes comme ceci :

@Crius

l’appliquer via un attribut HTML au lieu d’utiliser CSS ?

Il y a une bonne explication de la raison pour laquelle cela a été ajouté à l’origine :

Add lazy loading for emojis

Personally I think it is like a good manner to always add width and height attributes to img elements on point where the img-element is generated. That is the place where I might know for sure which exact image-file I’m putting in. CSS is far away from the actual image-file. On top the browsers use this extra info about the image size to calculate aspect-ratio before loading the image file - and before CSS parsing. For this case the emojis are used in many different places - and sometimes def…

Avec des détails supplémentaires de Multimedia: Images - Learn web development | MDN :

Lorsque les attributs width et height d’une image sont inclus dans un élément HTML <img>, le rapport d’aspect de l’image peut être calculé par le navigateur avant que l’image ne soit chargée. Ce rapport d’aspect est utilisé pour réserver l’espace nécessaire à l’affichage de l’image, réduisant ainsi, voire empêchant, un décalage de mise en page lorsque l’image est téléchargée et affichée à l’écran. La réduction des décalages de mise en page est un élément majeur d’une bonne expérience utilisateur et des performances web.

…

…

Bien que les meilleures pratiques de développement de la dernière décennie aient pu recommander d’omettre les attributs width et height d’une image sur un élément HTML <img>, en raison du mappage du rapport d’aspect, l’inclusion de ces deux attributs est considérée comme une meilleure pratique de développement.

Cela dit, vous avez un exemple raisonnable d’un cas où le dimensionnement par défaut ne fonctionnera pas pour tous les emojis… cet ancien emoji de « cheers » est 3 fois plus large, il ne s’intègre donc pas bien dans un carré. Il n’est pas inhabituel que d’autres applications limitent tous les emojis à des carrés, nous ne sommes donc pas si inhabituels dans notre comportement (Slack et Discord le font, par exemple)… mais nous pourrions alternativement envisager de permettre aux emojis personnalisés d’avoir éventuellement des dimensions définies.

[rrit (Ayke)]

@awesomerobot

[…] la taille par défaut ne fonctionnera pas pour tous les émojis… cet ancien émoji de célébration est 3 fois plus large, il ne rentre donc pas bien dans un carré.
[…] nous pourrions envisager d’autoriser les émojis personnalisés à avoir éventuellement des dimensions définies.

Du côté CSS, c’est facilement implémenté :

img.emoji {
  width: auto; /* remplace width: 20px; */
  height: 20px;
  vertical-align: text-bottom;
}

(Voir DEV: add native lazy loading for emojis by rr-it · Pull Request #15830 · discourse/discourse · GitHub pour l’explication.)

Le travail le plus difficile concerne la partie « émojis personnalisés » et le rendu des émojis :

• les émojis personnalisés ont besoin d’un attribut supplémentaire pour chaque émoji : aspect-ratio (ou alternativement height et width).
• le rendu des émojis doit utiliser le nouvel attribut aspect-ratio pour que les émojis personnalisés varient la width en conséquence – height reste à 20px.

---

Approche rapide et facile pour les émojis personnalisés :
Pour les émojis personnalisés, les balises img définissent uniquement height="20" et ne définissent pas du tout width – abandonnant ainsi l’avantage de définir l’aspect-ratio/la hauteur et la largeur.
CSS : img.emoji { width: auto; }