Espaces fines

Cinq personnes (en comptant l’autre discussion) se sont prononcées en faveur d’NBSP, il serait temps d’en prendre acte et de passer à autre chose.

Au cas où, +1 aussi. Vigneron a bien résumé mon opinion.

Idem (je n'ai rien contre les espaces fines, mais une espace insécable est largement préférable à pas d'espace du tout).

Mai il y a bien une espace ! Bel et bien pris en charge par MacOS depuis une douzaine d'années (pratiquement depuis son introduction dans Unicode 4.0). Et utilisé sur MacOS depuis bien longtemps (avant même le web) par tous les pros de la typographie et de la PAO (qui travaillent depuis bien plus longtemps sur Mac que sur PC) avant même le développement du web, ils ont été nombreux à demander cette prise en charge qui est arrivée au même moment que son unification (à tord) aussi avec le séparateur en mongol. et MacOS prend en charge aussi le mongol (pour l'instant encore avec NNBSP mais cela va changer en mars prochain avec un nouveau caractère et Apple a aussi déjà fait une mise à jour bêta pour ça de ses OS (il ne supprimera pas NBNBSP en mongol mais l'utilisera en mode de compatibilité sans rien retirer de la fine insécable, qui reste encore standard comme séparateur de groupes de chiffres dans les nombres en format français et ISO, où l'espace insécable NBSP est totalement indésirable) et figure aussi dans les bibliothèques CLDR et les formateurs de nombres en français de MacOS et de Java (inclus aussi dans MacOS et iOS).

Pour ce qui concerne macOS, on parle ici de Safari qui n'affiche clairement pas d'espace (prouvé plusieurs fois dans la discussion précédente), pas des autres applications ou navigateurs.

Merci de ne pas changer de sujet.

Console Javascript:

console.log(new Intl.NumberFormat('fr-FR', { maximumSignificantDigits: 3 }).format(123456));

Affiche "123 456" et non "123456".

console.log(new Intl.NumberFormat('fr-FR', { maximumSignificantDigits: 3 }).format(123456).codePointAt(3).toString(16));

Affiche "202f" (code hexadécimal du 4e point de code), et non pas "a0" ni "34".

Intl.Numberformat() est complètement supporté depuis Safari 10, Chrome 24, Edge 12, Firefox 29, IE 1, Opera 15.

Comment font alors le Mac or l'iPhone?

Voici le résultat sur Safari 13.0.3 (macOS), si j'en crois le résultat pour la même commande sur Firefox, Safari semble ignorer complément l'espace fine insécable qui est censée être entre 120 et 000.

Non Safari ne l'ignore pas puisqu'il affiche bien "202f" comme 4e caractère, il choisit seulement de l'afficher comme un glyphe vide (choix de design d'Apple dans la police que tu utilises). Ce qui confirme ce que je dis: c'est son design et conforme à ce qu'Apple fait depuis longtemps aussi dans la présentation des nombres. Le caractère est bien présent, mais il n'y a pas d'anomalie d'affichage, aucun "tofu".

Note bien que dans ta console Freifox, les résultats sont affichés dans une police de type "monospace" (à chasse fixe) qui figure le NNBSP sous forme d'une espace simple et non d'une espace vide (les deux sont possibles, bien qu'à mon avis la fine est plus adaptée à ce cas). Si tu passes la console en police proportionnelle tu peux voir une différence suivant les préférences du navigateur pour les deux styles génériques "serif" ou "sans-serif", selon les polices choisies (si tu prends une police système Apple, en sans-serif, le NNBSP disparaît et c'est normal et cohérent avec les glyphes des ponctuations). Dans tous les cas c'est une question de préférence: si tu aimes les polices UI d'Apple, ne rien voir est normal car tu ne vois rien non plus dans l'UI d'Apple pour les grands nombres et il n'uy a non plus aucune espace ajoutée autour des ponctuation déjà "élargies" de ces polices, donc aucune anomalie là non plus, mais tu ne fais pas de la APO ou de la typographie. Tu as le choix dans ton navigateur (dans Safari, comme Firefox ,ou Chrome, ou Edge qui va aussi arriver, ou Opera) !

Et dans d'autres polices comme Times New Roman, Segoe UI et plein d'autres, le caractère est bien distingué.

Critique l'UI d'Apple si tu veux, mais c'est ce qu'Apple recommande. De même il a mappé NNBSP (pas seulement NBSP) sur le clavier français tout en sachant que ce peut ne pas être utilisé pour les UIO d'applis MacOS/iOS, mais que c'est bien utilisé dans les contenus en ligne et la PAO. Hors de Javascript tu peux aussi voir ce que retourne les API d'internationalisation des nombres de MacOS: là aussi il y a bien NNBSP et non NBSP (Apple ne dévie donc pas des normes de codage, son choix est purement typographique dans ses polices système).

Apple a du faire ça pour "compacter" les nombres sur les mobiles (on peut noter qu'il choisit des chiffres plus larges, en supposant qu'il n'y a jamais besoin de les compter, il a fait le même choix avec les ponctuations qui incluent un "gap" qu'Apple juge suffisant pour qu'avec la même police la fine puisse être annulée. On peut critiquer le choix d'Apple mais c'est un choix propriétaire pour ses polices UI (qui ne sont pas destinées au rendu web où il y a plein d'autres choix que la police "système". Et c'est aussi cohérent avec son choix d'interface pour la présentation des formulaires de ses applications.

Ces polices système ne sont pas destinées au web, à la typographie fine, à la PAO. Dans le Finder de fichiers, MacOS choisit de ne pas afficher les grands nombres mais il les arrondit pour ne pas avoir à afficher les groupements de 3 chiffres. La PAO, et les logiciels tiers comme MS Office ou Libre Office utilisent des polices qui font clairement la différence et les polices "système" (pas adaptées à toutes les langues mais à des orthographes simplifiées, y compris en Arabe ou hébreu) ne sont pas utilisées sauf si on les demande.

Note: les polices web par défaut sont normalement avec "Serif" dans le texte d'un navigateur. Pour l'UI le design original d'Apple et cohérent avec son interface est de ne pas afficher les NNBSP (ce qui est une erreur fondamentale pour l'écriture mongole, ce qu'Apple a fini par reconnaître). Attends le printemps prochain, Apple va changer ça dans ses mises à jour de MacOS et iOS et rétablir ce qu'il faisait au début quand NNBSP a été encodé, mais pour il mettra un "flag" de compatibilité pour les applis spécialement dédiées à MacOS, pas pour le web (à moins d'utiliser un "feature" OpenType spécifique activable en Javascript pour émuler le comportement des versions récentes boguées de MacOS et iOS avec ses polices système).

As-tu une source concernant cette mise à jour de mars ?