Hello,

Sur un autre thread, Fabe avait suggéré d'inclure les émoji unicode sur Lexpage. Pour ceux qui ne suivent pas trop, unicode (le machin qui sert à "encoder" les caractères) définit notamment des caractères qui ne sont typiquement pas sur vos claviers et qui, lorsqu'ils sont utilisés, correspondent à des smiley. On retrouve ça notamment sur Github, Facebook (je pense), WhatsApp, etc.

Parmi les avantages des émoji unicode, c'est qu'ils sont "copier-collables" facilement (contrairement aux images actuelles) et surtout, relativement universel dans leur représentation. Par exemple, le caractère 😀 devrait afficher chez vous un smiley qui sourit, peu importe l'application dans laquelle vous l'utiliserez et peu importe l'utilisateur qui va l'afficher (du moment que la police qu'il utilise supporte les smiley unicode). Le "hic", c'est que le rendu dépend de cette police. Par exemple, sur mon laptop, ce caractère 😀 s'affiche en noir et blanc, alors que sous mon Windows, c'est un smiley coloré qui s'affiche à la place (allez savoir pourquoi ! en fait, la raison est simple : sous Linux, ça utilise Open Sans, qui fait un rendu noir & blanc et est une police libre, ce qui ne court pas les rues pour les émojis). Pour éviter ces variantes, et pour éviter d'imposer une police pour "garantir" (on se comprend : ce n'est pas le cas) un rendu uniforme, la plupart des applications transforment automatiquement ces caractères en une image (comme on le fait actuellement sur Lexpage quand vous tapez "; - )" sans espace, sauf que si vous copiez-coller ça ailleurs, vous n'êtes pas garanti que ça va faire un émoji souriant !).

Pour vous donner une idée, voici une table des correspondances (code unicode et représentation dans différentes applications. La première colonne correspondant au rendu effectué par votre navigateur) :
unicode.org/emoji/charts…

Je suppose que l'idée de Fabe est de remplacer les "codes smiley" du Lexpage par les codes unicode. En pratique, cela ne change pas grand chose, sauf qu'au lieu d'avoir un ": smile :" quand vous cliquez sur dans la liste des smiley, vous aurez "😀" à la place. L'avantage, c'est que c'est "un peu plus portable", et que la liste des émoji supportés est nettement plus importante (a-t-on besoin de ça ? c'est une autre question ). Si on remplace ceux du Lexpage, ça veut dire qu'on perd nos "habituels" smiley spécifiques (le up, sex, z'êtes con, yaisse, etc.) pour des choses plus conventionnelles. On pourrait aussi ne pas les remplacer, mais simplement les compléter par les smiley unicodes.

Au niveau rendu, on peut assez facilement "uniformiser" en utilisant une des librairies qui remplace ces smiley unicode par de vraies images (qui seront donc identiques pour tout le monde). L'avantage est que c'est uniforme, l'inconvénient est qu'on ne travaille plus vraiment avec des caractères mais des images. L'autre option, c'est d'utiliser Emoji One, qui est une police libre spécifique pour les smiley, et d'enrober chaque "smiley unicode" dans cette police (exemple de rendu : www.emojicopy.com/). C'est uniforme, mais ça impose le chargement d'une police supplémentaire (je ne sais pas ce que ça change en pratique, je suppose que Tchou doit en savoir plus sur les avantages/inconvénients de cette méthode ?).

Bref, comme vous le voyez, y a du potentiel à discuter de la proposition de Fabe, notamment au regard des implications que ça peut avoir pour nos petites habitudes sur le forum. En premier lieu, peut-être Fabe pourrait-il détailler ce qui l'a poussé à suggérer ça initialement ?

J'oubliais : bien entendu, l'idée n'est pas non plus de vous forcer à devoir passer par la liste des smiley à chaque fois que vous voulez en faire apparaître un, ni de vous demander de retenir par coeur les codes unicode des smiley les plus courants. L'idée est d'avoir ce support sur le site (via la liste des smiley), et de l'étendre automatiquement en convertissant certains codes (comme ": smile :") en un machin correspondant. Pour ça, je compte utiliser la liste qui est proposée ici et qui semble relativement conventionnelle, à en juger par la liste des applications qui en font déjà usage.

www.webpagefx.com/tools/…

Et rien de tel qu'un bon petit article pour expliquer pourquoi il faut une approche de rendu unifié si on souhaite implémenter un tel support sur Lexpage

www.buzzfeed.com/nicolen…

Guybrushpeut-être Fabe pourrait-il détailler ce qui l'a poussé à suggérer ça initialement ?

Lancer un débat sur un sujet auquel personne ne pensait. C'est chose faite !

Bisous

Blague à part, c'est surtout pour le mobile, ou le smiley picker actuel est une tannée.

Les smileys standards fonctionnent déjà, mais seulement sur mobile il me semble ? En tous cas la dernière fois que j'ai essayé il apparaissait correctement sur mobile et pas sur desktop (ubuntu), mais je suppose qu'on peut ajuster ça en jouant sur la font.

Et puis unicode est un standard, et les standards c'est bon

Après, si vous voulez vraiment garder , libre à vous

FabeLancer un débat sur un sujet auquel personne ne pensait. C'est chose faite !

Si j'avais su...

FabeBlague à part, c'est surtout pour le mobile, ou le smiley picker actuel est une tannée.

Je suis 100% d'accord (et même davantage, si ça avait du sens ) que le sélecteur de smileys actuel est une plaie sur mobile (déjà que sur pc, il est pas terrible). En fait, c'est toute la toolbar qui est une plaie à utiliser sur appareil mobile, y a un ticket ouvert sur Github depuis le 13 août 2015 à ce sujet Il faudrait que je me concentre là-dessus... j'avoue que devoir taper des [ et ] manuellement n'est pas des plus simples sur un clavier virtuel

FabeLes smileys standards fonctionnent déjà, mais seulement sur mobile il me semble ? En tous cas la dernière fois que j'ai essayé il apparaissait correctement sur mobile et pas sur desktop (ubuntu), mais je suppose qu'on peut ajuster ça en jouant sur la font.

Les smiley unicode sont déjà supportés implicitement sur Lexpage (ce sont juste des caractères mis en forme par le device qui affiche la page, finalement). C'est un "standard" implicitement géré, mais on pourrait davantage gérer ce type de smileys en utilisant les "alias" (les noms entre ":blabla:") correspondant également (et ce, à la place ou en complément de ceux du Lexpage). Le "hic", c'est que même si c'est "standard", le rendu n'est pas uniforme (cf. le lien ci-dessus qui met en évidence quelques différences). Et même si ce n'est pas trop grave, le rendu sous Linux (via Open Sans) n'est vraiment pas des plus agréables La solution actuellement la plus répandue consiste à convertir ces smiley unicode en images (sic !) (utiliser et forcer une font qui "marche" et uniformise les smiley n'est pas forcément une idée, vu que ces fonts font souvent plusieurs Mo à télécharger).

👍✌🔝➕☑

Le rendu n'est pas uniforme suivant les fabricants, tu pense envoyer un mignon smiley tout doux qui ne fait aucun doute dans ton esprit, ça se transforme en mad max sadique qui veut bouffer ton foie (cf le "je pleure de rire") ... ou en "je suis malade j'ai le nez qui coule" (même ligne, et je suis pas allé bien loin, c'est ligne 3 : unicode.org/emoji/charts… ).

Le but des smileys, c'est de préciser les nuances de l'écrit. Tiens, un smiley, je te montre que je n'étais pas sérieux, ce n'est pas du premier degrés ce que je viens d'écrire. S'il faut écrire pour préciser le sens d'un smiley, quelle avancée !

Je comprends l'intérêt des unicode dans un sms, permettre de n'envoyer que quelques octets au lieu de plusieurs ko par smiley. Pour le reste, je trouve ça plus un problème qu'une solution.

Utiliser une typo smileys... alors déjà, l'exemple que tu nous donne (emojicopy) n'utilise pas des typos, il charge des images et tu choisis dans la grosse image png. Méga pertinent sur ce sujet, donc ! À ma connaissance, une typo te limite à une couleur par caractère, mais effectivement les emoji existent, juste mon cerveau oublie que quelqu'un a inventé cette m... ce truc, donc je ne suis pas le plus informé sur le sujet.

TchouÀ ma connaissance, une typo te limite à une couleur par caractère, mais effectivement les emoji existent, juste mon cerveau oublie que quelqu'un a inventé cette m... ce truc, donc je ne suis pas le plus informé sur le sujet.

Je te trouve sévère, UTF-8 permet justement ce genre de fantaisie.
Par rapport à la pratique précédente où chaque vendor avait son propre set de smileys complètement incompatibles (copier-coller d'un SMS vers une autre appli par exemple...), la présence d'un standard me semble justifiée.

D'autant plus que le concept est de tenir compte des interprétations possibles en fonction des différences de culture, ce que personne ne faisait avant.

Sur ce point-là, je suis d'accord, l'échange de contenu qui ne bouffe pas d'information au passage, c'est bien.

Par contre, le rendu graphique étant différent en fonction du terminal utilisé, ça ça bloque tout en ce qui me concerne. L'interprétation des images est 1000 fois plus subjectif que l'interprétation des mots, et quand tu vois que s'engueuler sur un malentendu (ou un mal-lu) est fréquent, alors si entre ce que j'envoie et ce qui est reçu les designer des images n'ont pas la même logique, c'est l'engueulade assurée.

Cf ligne 3 de unicode.org/emoji/charts… (en oubliant le "browser" qui m'est propre, et sur certaines lignes telle la ligne 2, j'ai un smiley "browser" plus menaçant qu'enjoué) : les premiers sont tous à peu près équivalent, celui de samsung il m'évoque la tristesse et les pleurs, celui windows c'est un punk qui sourit sadiquement.
Ligne 4, déjà j'ai pas de smiley browser, celui de "one" m'évoque plus la douleur que le rire, celui windows carrément le mec est à terre en train de chialer sa race.

Dans les 4 premières lignes, il y a au moins un soucis par ligne. Y'a que la ligne 1 qui est sans trop de différences d'interprétation.

Ok pour le standard. Par contre, vu qu'il s'agit d'image, chaque image ne raconte pas la même chose. Donc ça complexifie la discussion plutôt que l'aider, à mon sens.