Astuce/Question : Font-Size px to em facile ?

Hello tout le monde,

Je suis tombé sur cette astuce qui permet apparement de faire la relation entre les px et les em assez facilement..

L'idée est de définir la taille de la police du body avec 62.5%, se qui fait qu'après on peut simplement diviser le nombre de pixel par 10 pour connaitre la valeur en em ?

C'est vraiment aussi simple que ça ??

C'est une vieille astuce déjà

Personnellement, je ne fais aucune relation entre les pixel et les em, ça n'a rien à voir et pas grand intérêt.

Effectivement 2004 c'est pas tout jeune .

Sinon l'intéret que j'y vois est purement politique .

Par exemple dans ma boite j'ai une personne qui est très a cheval sur le design et qui souhaite que chaque éléments soient positionnés au pixel près... Et vu qu'utiliser le pixel pour une font-size n'est pas top niveau accessibilité, avec cette astuce je peux rendre content le monde content .

Merci en tout cas pour ton feedback.

Mikerob a écrit :

Par exemple dans ma boite j'ai une personne qui est très a cheval sur le design et qui souhaite que chaque éléments soient positionnés au pixel près... Et vu qu'utiliser le pixel pour une font-size n'est pas top niveau accessibilité, avec cette astuce je peux rendre content le monde content .

Tes polices de caractères n'auront jamais le même rendu entre ton logiciel de dessin et ton navigateur. Par conséquent, ça n'a aucune sens de vouloir appliquer exactement la même taille de caractères sur la version navigateur sous prétexte de pixel perfect.

Moi je l'utilise cette technique et ça me facilite effectivement la vie. Loin de moi l'idée d'avoir une police identique à 100% entre Photoshop et mon navigateur, mais ça donne quand-même des proportions aux textes qui sont cohérentes par rapport aux maquettes. Et de toute façon on ne peut pas faire mieux, alors pourquoi cracher dans la soupe ?

Bonjour,

je n'utilise que cette technique
Florent V. en parlait il y a 4 ans sur un site qui cause de CSS : Nouveau tutoriel sur la taille de police "em"

Jordi a écrit :
Et de toute façon on ne peut pas faire mieux, alors pourquoi cracher dans la soupe ?

Si tu applique cette technique d'un bout à l'autre de ton design, tu n'utilises jamais l'héritage. Alors on peut sûrement faire mieux et plus intelligent.

Je trouve que l'héritage au niveau des tailles de police relatives c'est casse-gueule pour intégrer une maquette ... Si tes blocs se mettent à hériter en cascade de tailles relatives, tu passes ton temps à mettre des rustines pour recoller avec les bonnes tailles de police.
Personnellement, je définis ma taille sur le body puis sur mes éléments structurants et j'essaie de ne plus rien toucher Le fait de savoir qu'un em = 10 px je trouve ça ultra pratique et si tu connais une solution encore plus intelligente je suis preneur

Jordi a écrit :
Je trouve que l'héritage au niveau des tailles de police relatives c'est casse-gueule pour intégrer une maquette ... Si tes blocs se mettent à hériter en cascade de tailles relatives, tu passes ton temps à mettre des rustines pour recoller avec les bonnes tailles de police.

Tu ne sais pas faire car tu es dans une démarche de reproduction uniquement. C'est différent.
Modifié par bzh (28 Oct 2010 - 14:40)

Bonjour,

Ma recommandation 2010:
1. Ne pas chercher à faire d'équivalence entre px et em, comme le dit bzh plus haut (ça, je le dis plus ou moins depuis 2006).
2. Si on veut obtenir une taille de texte précise en pixels, utiliser l'unité px, qui est très propre sur elle.

Pour ce qui est du texte en px et de l'accessibilité:
- Le texte en px est parfaitement redimensionnable. Aucune spec ne dit qu'il ne doit pas pouvoir être redimensionné par l'utilisateur. C'est le choix d'un User Agent (Internet Explorer) de procéder ainsi, et pour ma part je considère ça comme un bug.
- Tous les navigateurs actuels utilisent en premier lieu un zoom homothétique (zoom page complète) plus ou moins sophistiqué, le premier et le plus sophistiqué étant celui d'Opera. Ça diminue largement l'importance du redimensionnement du texte seul.
- Si on prend comme référence RGAA 2.2, on a un critère 1.4.4 Redimensionnement du texte de niveau AA. Les explications déconseillent l'unité relative px à cause du bug d'IE déjà mentionné. Cependant, le test associé n'invalide l'utilisation de px que pour la taille du texte des éléments de formulaire: input, textarea, se­lect, button.
- AccessiWeb 2.1 n'a pas de critère sur l'utilisation de px, qui est donc libre. (Accessiweb et RGAA, dans leurs dernières versions, partagent un critère/test sur la lisibilité des contenus en cas d'agrandissement du texte à 200% de la taille «par défaut».)

Mon raccourci qui n'engage que moi: non, le texte en pixels ce n'est pas un problème d'accessibilité.
Libre à chacun ensuite de tenter de compenser l'implémentation contestable d'IE en bannissant l'unité px pour les tailles de texte.

Florent V. a écrit :
AccessiWeb 2.1 n'a pas de critère sur l'utilisation de px, qui est donc libre. (Accessiweb et RGAA, dans leurs dernières versions, partagent un critère/test sur la lisibilité des contenus en cas d'agrandissement du texte à 200% de la taille «par défaut».)

Accessiweb proscrit l'usage du pixel.

Mikerob a écrit :
L'idée est de définir la taille de la police du body avec 62.5%, se qui fait qu'après on peut simplement diviser le nombre de pixel par 10 pour connaitre la valeur en em ?

C'est vraiment aussi simple que ça ??

je n'ai pas essayé leur technique, mais je doute fortement que ça soit aussi simple :
il y a quelques années des gars de Yahoo! s'étaient cassé les yeux pour obtenir la même taille de police au pixel près sur plusieurs OS différents

ça passe par une feuille de reset, puis une définition en % des tailles de police, regarde le tableau en milieu de page :
http://developer.yahoo.com/yui/fonts/
il n'y a pas de formule mathématique pour passer d'une taille à l'autre, juste une tendance générale, le tableau est fait main.
Après la question est plus de savoir si tu as vraiment besoin de tout maîtriser au pixel près sachant que le premier resize venu va tout péter sur un couple navigateur/OS donné ou un autre

Florent j'aime bien ta façon de voir les choses !

Je ne rentrerai pas dans le débat des pixel ou pas, mais Il me semble que ce n'est évidemment pas aux développeurs front de palier aux bugs des navigateurs.

Ca fait du bien de trouver du monde qui pense comme moi sur ce sujet

Victor BRITO a écrit :
Accessiweb proscrit l'usage du pixel.

Dans son glossaire mais pas dans les critères et dans les tests?
Ça ressemble à un bug d'AccessiWeb 2.1.

Pour être précis, les seuls tests qui interdisent des unités pour la taille du texte semblent être:

AccessiWeb 2.1 a écrit :
Test 10.4.1 : Dans les feuilles de styles du site Web, les unités non relatives (pt, pc, mm, cm, in) ne doivent pas être utilisées pour les types de média screen, tv, handheld, projection. Cette règle est-elle respectée ?
Test 10.4.2 : Dans les feuilles de styles du site Web, les tailles de polices utilisent-elles uniquement des unités relatives ?

- 10.4.1 interdit les unités absolues en dehors du média print.
- 10.4.2 impose les unités relatives pour le texte (ce qui interdit au passage l'unit pt pour le texte pour le média print, je sais pas si c'est volontaire).
Aucun de ces deux tests n'interdit l'utilisation de l'unité px, qui est une unité relative.

Si quelqu'un est sur la liste AccessiWeb, il y a sans doute un erratum à faire:
- Est-ce normal de lister des unités autorisées ou non pour la taille du texte dans le glossaire plutôt que dans les critères et tests associés?
- Si oui, il faut soit indiquer que px est autorisée, soit modifier le test 10.4.2 pour interdire l'unité px.
- Ma recommandation est de ne pas proscrire l'unité px. Je ne vois pas ce qui le justifierait dans WCAG2, ni dans les implémentations HTML et CSS actuelles des navigateurs.

PS: Rappel qui va bien, px est une unité relative:
http://www.w3.org/TR/CSS2/syndata.html#length-units
http://www.w3.org/TR/css3-values/#relative0

jpvincent a écrit :
il y a quelques années des gars de Yahoo! s'étaient cassé les yeux pour obtenir la même taille de police au pixel près sur plusieurs OS différents

Ils étaient partis sur une mauvaise base, ou du moins sur quelque chose de difficile. Une taille de texte de base à 13px, ça fait des multiples vite très bizarres ensuite. Alors qu'avec une base de 10px, le tableau de correspondance devient très simple et très fiable dans tous les navigateurs.

La base de 10px est vachement plus simple pour obtenir des valeurs calculées justes, mais par contre le risque c'est que tu as une taille de texte de base de 10px, donc tout ce que tu ne redéfinis pas explicitement est illisible. La solution de YUI2 est prise de tête pour les valeurs calculées justes, mais si tu ne définis pas la taille de texte d'un élément tu obtiens du 13px donc tout va bien.

Dans les deux cas c'est vachement plus prise de tête que de définir les tailles de texte en pixels directement, pour un bénéfice quasi inexistant.

jpvincent a écrit :
il n'y a pas de formule mathématique pour passer d'une taille à l'autre, juste une tendance générale, le tableau est fait main.

Si si, ça se calcule. Mais comme ils voulaient utiliser des entiers plutôt que des nombres décimaux (108% plutôt que 1.076923%), ils ont arrondi eux-même, ce qui fait qu'au final ils avaient le choix entre demander du 107%=13.91px, ou du 108%=14.04px, ils ont dû tester dans tous les navigateurs pour voir comment les arrondis étaient faits en pratique et qu'est-ce qui permettait d'obtenir du 14px: 107% ou 108%?

jpvincent a écrit :
Après la question est plus de savoir si tu as vraiment besoin de tout maîtriser au pixel près sachant que le premier resize venu va tout péter sur un couple navigateur/OS donné ou un autre

C'est clair...
Cependant, pour le corps de texte et une lisibilité «optimale», le fait de se retrouver sur du 12px à la place d'un 13px prévu (suite aux arrondis des navigateurs, même si certains comme Firefox ne font pas d'arrondis aussi francs), ben ça peut être gênant.
Bien sûr la notion de taille de texte optimale pour un design donnée c'est très casse-gueule.

Je précise juste pour être clair: je ne recommande pas l'utilisation de px pour le texte dans l'absolu. Mais, si pour une raison ou une autre vous voulez vraiment aboutir (par défaut) à une taille de texte précise en pixels, tout en évitant les risques d'arrondis différents dans les navigateurs... utilisez l'unité px.

Florent V. a écrit :

Je précise juste pour être clair: je ne recommande pas l'utilisation de px pour le texte dans l'absolu. Mais, si pour une raison ou une autre vous voulez vraiment aboutir (par défaut) à une taille de texte précise en pixels, tout en évitant les risques d'arrondis différents dans les navigateurs... utilisez l'unité px.

En effet.

Je n'étais pas sûr de la meilleure accessibilité des tailles de textes en em face au px, hormis pour le cas d'internet explorer.

bzh a écrit :
Si tu applique cette technique d'un bout à l'autre de ton design, tu n'utilises jamais l'héritage.

C'est pas bien grave.
Les tailles de texte, c'est souvent sur p, hN, ... et pas souvent sur les div. Je me passe sans problème d'héritage dans le cas du texte.
Reste le cas des span, strong et em mais il n'y a que 3 éléments différents, on ne les utilise pas systématiquement (de loin pas) et donc c'est très très peu de boulot supplémentaire.

Le bénéfice pour l'accessibilité compense largement les "défauts" constatés ou fantasmés.

martinsupiot a écrit :
Je ne rentrerai pas dans le débat des pixel ou pas, mais Il me semble que ce n'est évidemment pas aux développeurs front de palier aux bugs des navigateurs.

On ne fait que ça la moitié de la journée, pallier les bugs des navigateurs (surtout certains navigateurs) ... ou alors tu crées des extensions pour un navigateur précis ou que pour iPhone.

PS: ne pas utiliser :nth-of-type et se limiter à cause d'IE, c'est une manière de pallier le bug en le contournant sans l'affronter (ça se discute, ce dernier point)
Modifié par Felipe (28 Oct 2010 - 20:08)

Felipe a écrit :

Les tailles de texte, c'est souvent sur p, hN, ... et pas souvent sur les div. Je me passe sans problème d'héritage dans le cas du texte.

Je défini souvent des tailles de texte en em sur les div ou autres éléments parents si je veux écrire plus petit ou plus grand à tel ou tel endroit. Ce sont 2 méthodes différentes.

Pour info niveau accessiweb non ce n est pas un bug selon eux c est voulu et cela fait échouer à la labelisation