Refonte des calculs des em dans le reset ?

raphaelgoetter commented 11 years ago

Suite à une discussion fort intéressante sur le Forum Alsacréations (http://forum.alsacreations.com/topic-4-64347-1.html), j'ai de plus en plus envie de modifier la façon de calculer les em sur KNACSS.

Actuellement :

html {font-size: 62.5%} /* rem ready */
body {font-size: 1.4em} /* equiv 14px */
p, li, td, caption, pre, figcaption, dd {font-size: 1em}
h1 {font-size: 1.8571em;} /* equiv 26px */
h2 {font-size: 1.7143em;} /* equiv 24px */
etc.

Après modifications, cela donnerait :

html {font-size: 62.5%} /* rem ready */
body {font-size: 1em}
p, li, td, caption, pre, figcaption, dd {font-size: 1.4em} /* equiv 14px */
li li, li p, td p, td li, dd p {font-size: 1em}
h1 {font-size: 2.6em;} /* equiv 26px */
h2 {font-size: 2.4em;} /* equiv 24px */
etc.

Avantages :

le calcul des em est beaucoup plus facile pour les divers éléments : je veux un élément h4 de "20px", j'écris 2em et non pas 1.4286em comme actuellement. Idem pour tous les autres éléments, leurs marges et hauteurs de ligne
les classes alternatives telles que .smaller, .small, .big, etc. seront bien plus intuitives

Inconvénients :

il faut définir une taille de 1.4em individuellement à chaque élément de bout de chaîne, et éviter les cascades surprises dans les imbrications (ex. li p)
si un élément de contenu ne se trouve pas au sein de p, li, td ou dd (= s'il est par exemple uniquement dans un div ou dans un form), sa taille de police ne sera pas "14px" comme espéré, mais "10px"
ça risque de casser certains endroits du rythme vertical (à vérifier ?)

Qu'en pensez-vous ?

Note : je prévois de passer aux full "rem" en 2015, inutile d'essayer de me convaincre ici ;)

Note 2 : je ne suis pas sûr que cela vaille le coup d'orienter le débat vers LESS / Sass : de toute façon en utilisant des préprocesseurs, les calculs ne sont plus un problème. L'idée est au contraire de faciliter la vie à ceux qui n'utilisent pas de préprocesseurs (oui il y en a encore ;))

nico3333fr commented 11 years ago

Au début, j'étais totalement partisan de la version 1em, mais j'ai constaté que devoir tout définir en fin de chaine était pénible, finalement, je pars toujours de la taille de fonte finale "normale" du site (le corps du texte), et je base tout dessus (donc plutôt la solution en 1.4em).

Même sans préproc, les calculs se font vite avec qq bon outils :)

ffoodd commented 11 years ago

L'échelle typographique est vouée à être personnalisée de toute façon, ce qui implique qu'il faudra se débrouiller pour en modifier les valeurs. Parmi les commentaires de Knacss un outil est à disposition pour générer une échelle typographique en em - ce qui simplifie grandement la tâche. C'est certes moins intuitif mais ça n'en reste pas moins facile à gérer, et garantit la santé de cette jolie cascade !

Sur un plan purement typographique, la question méritait d'être posée mais j'estime qu'être sur le web ne justifie pas l'utilisation de 15 corps de texte différents... Quelques lectures pourraient convaincre de l'intérêt d'une échelle ferme :

Par conséquent je suis plutôt partisan de la méthode actuelle qui simplifie grandement la gestion de la cascade et garantit une cohérence typographique indispensable - en attendant la prise en charge de rem qui résoudra la question.

cahnory commented 11 years ago

Je rejoint @nico3333fr et @ffoodd. Les calculs ne sont pas compliqués, en tout cas c'est moins contraignant à mes yeux que de devoir penser au contexte et à la cascade des em. Bon, ce n'est pas bien compliqué non plus mais le calcul n'impacte que le dev alors que la solution 2 impacte le dev et le browser (plus de sélecteur, plus spécifiques,… faiblement mais dans l'absolut c'est le cas). Pré-processeur ou non, je préfère donc la solution 1 qui, sans lancer de débat, voit ses défault disparaître avec.

lionelB commented 11 years ago

Hello

Concernant la version Sass de KNACSS, tu pourrais ajouter un petit mixin pour faciliter le calcul de la taille

//Function that compute em value from pixel value
@function em($target-px, $context-px) {
  @return ($target-px / $context-px) * 1em;
}

raphaelgoetter commented 11 years ago

Je fais un résumé des premiers retours :

@nico3333fr préfère la version 2 (edit : ah non la version 1)
@ffoodd préfère la version 1
@cahnory est d'accord avec @nico3333fr ... et préfère la version 1 :)
@lionelB triche et parle de préprocesseurs :)

cahnory commented 11 years ago

heu l'un de nous deux a mal lu le commentaire de @nico3333fr je pense :D

nico3333fr commented 11 years ago

Heu oui, je préfère la version 1 :)

lionelB commented 11 years ago

Désolé pour le hors sujet, j'avais pas vu la note 2 :( Je penche aussi pour la version 1. Et donc pour ceux qui n'utilise pas de préprocesseur, on peut rajouter la formule pour passer des pixel au em en commentaire ;)

KittyGiraudel commented 11 years ago

La version 2 est selon moi plus agréable, et ce pour plusieurs raisons :

Devoir assigner des tailles de police avec 5 décimales, c'est horrible tant d'un point de vue lisibilité que maintenabilité ; je ne sais pas pour vous, mais j'ai horreur de devoir sortir ma calculatrice pour définir une taille de police de 28px à mon titre
La version 2 offre du code "rem-ready" ; le jour où on veut passer en rem, il y a juste à changer les "em" en "rem" ; aucune refactorisation du code n'est impliquée

Pour finir, la différence de code entre les deux (en terme de poids et de performance) est absolument minime, et ne peut donc pas être un critère de choix.

En fait j'ai surtout l'impression que la version 1 est imbuvable sans un préprocesseur pour faire les calculs derrière. Dans le cas de l'utilisation d'un préprocesseur, elle est surement mieux (moins de code, même résultat, aucune difficulté supplémentaire).

raphaelgoetter commented 11 years ago

@nico3333fr alors j'ai pas compris du tout quand tu écris "et je base tout dessus (donc plutôt la deuxième en 1.4em)."

raphaelgoetter commented 11 years ago

@HugoGiraudel : les deux versions sont rem ready puisque rem se base sur la taille de HTML ;)

cahnory commented 11 years ago

@raphaelgoetter tu déformes ces propos, "(donc plutôt la solution en 1.4em)" ;)

nico3333fr commented 11 years ago

@raphaelgoetter Oui, j'ai édité le truc 2 s après l'avoir posté, tu as dû recevoir le mail (ces mails qui ne se mettent pas à jour :o) )

raphaelgoetter commented 11 years ago

Merci pour vos retours.

Je reste encore mitigé. Cela me gêne beaucoup d'imposer des tailles en em imbitables à 4 chiffres après la virgule, et de fausser la cascade dès le départ en imposant une valeur à body.

raphaelgoetter commented 11 years ago

(Tiens j'ai eu des notifications de 2 réponses par mail mais je ne les vois pas ici)

Selon moi, voici un aperçu de la situation et de ses conséquences :

_Cas 1 : html (pas de font-size) --> body (pas de font-size) _

Conséquence : pas de cascade subie, mais tous les éléments devront être spécifiés par rapport à la taille de police navigateur (16px) et avec des calculs complexes
Parfait si on a une calculette ou un préprocesseur

_Cas 2 : html (62.5%) --> body (pas de font-size) _

Conséquence : pas de cascade subie, mais tous les éléments devront être spécifiés par rapport à la taille de police navigateur (10px) et avec des calculs simples
Les calculs sont simples mais il faut généralement écraser la valeur 10px trop faible pour tous les éléments en bas de chaîne

_Cas 3 : html (62.5%) --> body (1.4em) _

Conséquence : tous les éléments descendants de body subissent la cascade. Cela nous arrange pour les éléments qui doivent faire 14px, mais tous les autres éléments devront être spécifiés, et avec des calculs complexes
Les calculs sont simples mais uniquement pour les éléments génériques de 14px

Pour faciliter les choses, prenons un cas concret courant en production : je souhaite disposer des éléments suivants (ma base quel que soit le cas est de 14px) :

des paragraphes alternatifs de 12px
dans la sidebar, un niveau de titre 4 de 16px
un label de 11px dans un div de 14px
un label de 11px dans un paragraphe de 14px
un label de 11px dans un paragraphe de 13px

D'après vous, quelle serait le meilleur choix parmi les 3 cas sus-cités ?

raphaelgoetter commented 11 years ago

J'ai beau triturer le truc dans tous le sens, il n'y a vraiment pas de solution ultime.

Quelle que soit la méthode employée, on a forcément un problème quand on a des éléments imbriqués (par exemple un label dans un p) à partir du moment où le label doit avoir une taille différente de son parent (par exemple label 15px dans un p de 14px)

Au final, la solution passe forcément par :

calculette
préprocesseur
rem (+px éventuellement)

Je rêve de pouvoir enfin utiliser rem en production. Tout serait enfin réglé.

tests en live : http://codepen.io/raphaelgoetter/pen/ldrfp

KittyGiraudel commented 11 years ago

Je rêve de pouvoir enfin utiliser rem en production. Tout serait enfin réglé.

Tu peux. :)

raphaelgoetter commented 11 years ago

@HugoGiraudel : oui si plus personne n'utilisait IE6-IE8, et si plus personne n'était handicapé visuel sur IE6-IE8, je pourrais...

KittyGiraudel commented 11 years ago

Ou si tu utilisais un préprocesseur (ou pas en fait hein, c'est juste plus simple avec un préprocesseur).

raphaelgoetter commented 11 years ago

Oui mais là on tourne en boucle. Le but est depuis le départ de trouver la meilleure méthode sans préprocesseur (car tout le monde ne les utilise pas, et de loin).

KittyGiraudel commented 11 years ago

Il n'y a pas de méthode meilleure que les autres. Tu l'as dit toi même, quelle que soit la solution choisie on tombe sur un os.

Selon moi, la seconde solution est la plus simple. Basculer en base 10, ça permet des calculs faciles, et donc un développement plus agréable. J'ai horreur de devoir faire des calculs.

ffoodd commented 11 years ago

Personnellement je reste sur ma pratique de l'échelle typographique - et donc la solution n°2 - à ceci près que je ne fixerais pas forcément le body à 1.4em. Il m'est arrivé récemment de le mettre à 1.6em et de recalculer mon échelle en conséquence, car le corps de base l'exigeait.

Le corps du body ( et pas du christ ) doit être le corps courant à mon sens, et pas simplement 1.4em pour faire joli dans les calculs. Ça ressemble trop à une exception du fameux nombre magique : poser arbitrairement cette valeur ne facilitera pas forcément la tâche..

D'ici quelques mois je basculerais vers les rem avec un fallback en px, mais en attendant je ne vois rien d'insurmontable dans le fait de calculer son échelle typographique "de tête" et sans les mains :D Et gérer la cascade.. Et bien je dirais que c'est notre job.

PS : pour le problème des éléments imbriqués, pourrait-on imaginer une solution complexe à mettre en place mais facile à utiliser ? Je pense à faire un premier soft reset comme actuellement dans Knacss, puis un second pour trouver l'équilibre : le soft reset servant simplement à homogénéiser le rendu navigateurs, et la seconde échelle ( basée sur des classes ) pour ajuster les corps. Rien qu'en écrivant ça, ça me semble extrêmement compliqué pour gérer une échelle typographique, mais l'idée serait de créer la solution plutôt que de chercher à éviter le problème...

nico3333fr commented 11 years ago

Pour ma part, le body à 1.4em, c'est à titre d'exemple, ça dépend totalement du site.

Par contre, et même sans préproc, c'est pas si difficile de définir les tailles, ça ne prend pas un monstre temps, et les classes .bigger, .smaller, etc. sont aussi là pour gérer les tailles de fonte additionnelles. Avec un peu d'habitude, je redéfinis très peu de nouvelle taille de fonte, donc pour moi, c'est un faux-problème, en tout cas, pas un problème "majeur". ^^

ffoodd commented 11 years ago

En effet j'imagine bien que les power-users que nous sommes ne rencontrent que rarement des problèmes avec ce travail de calcul, cependant il me semble aussi que la source de cette discussion était la prise en main de ce système par des gens moins habitués à ce travail - ou je fais erreur..? La discussion citée en source par Raphaël illustre d'ailleurs assez bien ce problème, mais je suis peut-être hors sujet..

Je reste aussi sur ma position de non-problème puisqu'à chaque projet je dois refaire cette échelle - que j'ai d'ailleurs éjectée du soft reset.

Cependant les tests de Raphaël sont très utiles car dans le cadre de Knacss ils peuvent vraisemblablement améliorer les versions Sass / LESS.

raphaelgoetter commented 11 years ago

@ffoodd "cependant il me semble aussi que la source de cette discussion était la prise en main de ce système par des gens moins habitués à ce travail - ou je fais erreur..?"

-> Oui, voilà :)

ffoodd commented 11 years ago

Au temps pour moi :)

raphaelgoetter commented 11 years ago

Ah non je veux dire " oui je confirme que l'usage de KNACSS n'est pas forcément pour nous autres power users"

ffoodd commented 11 years ago

Ok :) Ça remet donc en perspective certaines parties de cette discussion, car nous avons tendance à penser selon notre workflow personnel. Et vous êtes tous des intégrateurs chevronnés, je suis - il me semble - le moins expérimenté dans cette discussion. Donc merci @nico3333fr pour la prise de conscience avec :

Avec un peu d'habitude, je redéfinis très peu de nouvelle taille de fonte, donc pour moi, c'est un faux- problème, en tout cas, pas un problème "majeur".

Certes, nous, nous avons cette habitude, et nous comprenons les tenants et aboutissants de cette mécanique. Mais on peut se poser la question autrement : si un débutant se lance dans une intégration et utilise Knacss ( car évidemment il en aura ouïes de chaudes recommandations ), quelle chance y a t'il pour qu'il ait besoin de supporter les déficiences visuelles sur IE8 ..? Probablement aucune.

-- À priori il se fichera également de son rythme vertical, de son échelle typographique et du support navigateur <3

Donc effectivement, dans le contexte de Knacss, définir 1em ( ou rien, d'ailleurs ) sur le body ne semble pas être une mauvaise idée puisqu'on met ce mécanisme à la portée des débutants. Quelques commentaires avisés pourraient suffire à prévenir les erreurs les plus courantes.. Sans compter que les versions préprocesseurs peuvent utiliser des mixins pour appliquer les rem dès aujourd'hui, et dans leur cas le problème est résolu !

Il faudrait peut-être sonder les utilisateurs moins à l'aise, pour voir ce qui est le plus compréhensible et maniable ?

ffoodd commented 11 years ago

( ou alors je suis reparti dans un délire sans queue ni tête, frappez moi si c'est le cas >< )

raphaelgoetter commented 11 years ago

" frappez moi si c'est le cas" -> on peut vraiment ? :p

ffoodd commented 11 years ago

Me spammer sera plus facile :D

nico3333fr commented 11 years ago

En fait, revenons à la base : je cite le site de Knacss : "Take a moment to read all the notes and advices (in this tutorial) before jumping on. KNACSS doesn’t always fit beginners’ needs. Remember great power comes with great responsibilities."

bcarbonn commented 11 years ago

Bonjour à tous,

Je me joins à ce débat intéressant pour vous donner mon avis et vous parler de mon expérience en intégration.

Tout d'abord j'utilise KNACSS depuis peu et je le trouve vraiment très bien fait, sauf concernant un point... la gestion des tailles de typo ! Devoir passer par des calculs avec des résultats à 4 chiffres après la virgule me dérange, c'est sans doute une question d'habitude, mais personnellement j'ai toujours travaillé avec un body à 1em et appliqué les bonnes tailles sur les bouts de chaines, l'avantage est qu'il n'y a aucun doute / erreur possible, on sait de suite en regardant le code à combien on est : 1.3em = 13px.

Comme le dis Raphaël, la solution ultime n'existe pas, mais il me semble plus simple à utiliser la solution numéro 2 proposée au début de ce sujet.

Pour ce qui concernent les Inconvénients :

" il faut définir une taille de 1.4em individuellement à chaque élément de bout de chaîne, et éviter les cascades surprises dans les imbrications (ex. li p) "

=> De manière générale c'est ce qu'on fait la plupart du temps, définir une taille à chaque fois permet de maitriser parfaitement la taille des typos et de ne rien oublier (par ex, on risque de laisser une taille à 14px au lieu de 13px parce qu'on l'a pas vu).

" si un élément de contenu ne se trouve pas au sein de p, li, td ou dd (= s'il est par exemple uniquement dans un div ou dans un form), sa taille de police ne sera pas "14px" comme espéré, mais "10px""

=> Avoir un élément uniquement dans un div, n'est sémantiquement parlant pas très correct, peut être on peut lui trouver une balise pour lui donner du sens ? Sinon ce genre de situation reste assez rare pour ma part, la solution serait de l'imbriquer dans un span avec une classe ".textBaseSize" par exemple. Pas très beau j'avoue..

KittyGiraudel commented 11 years ago

Je remonte un peu le sujet. Il a été décidé quelque chose sur la marche à suivre finalement ?

Vu que je plonge à nouveau dans la version Sass, c'est histoire de se caler sur la décision prise pour la version CSS.

En ce qui me concerne, j'ai pour l'instant utilisé les REM avec fallback en PX pour les tailles de police (pas pour le reste, je voulais pas tout basculer en REM, mais je me tate).

raphaelgoetter commented 11 years ago

La marche à suivre dépend du support d'IE. REM n'est reconnu qu'à partir de IE9. Le fallback proposé en PX impacterait IE6-IE8, or c'est justement sur ces navigateurs qu'un bug de zoom texte interdit d'agrandir les polices en PX, ce qui cause des problèmes d'accessibilité.

Je préfère donc attendre un peu et passer en REM lorsque IE9 sera bien plus présent sur le marché et quand on laissera tomber IE8 : https://github.com/raphaelgoetter/KNACSS/issues/11

cahnory commented 11 years ago

Je pense que ce code pas nettoyé va faire hurler @HugoGiraudel mais pour information j'ai pondu ça : https://gist.github.com/cahnory/06a0c27c558969f945f4

Ça met cette question au second plan, les dimensions étant toujours spécifiées en pixel sans unité.

nico3333fr commented 11 years ago

@cahnory si jamais, j'avais refait les fonctions en Sass un peu à l'arrache pour RÖCSSTI si ça peut t'aider (j'ai pas tout compris toutes les subtilités, mais la fonction recrache les mêmes valeurs que http://soqr.fr/vertical-rhythm/ qui me convenait très bien ^^ ).

Pour les REM, chez moi c'est clair, sauf projet sans IE<9 => pas pour le moment. Reste que ça ne va pas changer grand chose dans mes CSS le jour où j'y passe, comme j'ai indiqué plus haut, c'est vraiment pas un problème inquiétant. :)

cahnory commented 11 years ago

@nico3333fr j'ai effectivement suivi les règles de calcul d'@eQRoeil pour mon code (pas sur que tu parlais de ça mais en clair, je crois qu'on les a tous suivi :)).

Le but de mon code est de permettre de passer facilement des em aux rem (entre les projets, au sein d'un projet forcément vu qu'em est relatif ça peut ne pas passer ^^), de définir la taille d'1rem, la taille d'1em (body font-size),… Peut importe ce que l'on choisi comme settings, on travaille toujours en pixel sans unité.

alsacreations / KNACSS

Refonte des calculs des em dans le reset ? #10