Refonte des calculs des em dans le reset ? about knacss HOT 38 CLOSED

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 :)

from knacss.

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 :

• Typo & web
• Lisibilité web
• Webgrids

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.

from knacss.

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.

from knacss.

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;
}

from knacss.

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 :)

from knacss.

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

from knacss.

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

from knacss.

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 ;)

from knacss.

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).

from knacss.

@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)."

from knacss.

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

from knacss.

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

from knacss.

@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) )

from knacss.

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.

from knacss.

(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 ?

from knacss.

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

from knacss.

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

Tu peux. :)

from knacss.

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

from knacss.

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

from knacss.

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).

from knacss.

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.

from knacss.

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...

from knacss.

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". ^^

from knacss.

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.

from knacss.

@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à :)

from knacss.

Au temps pour moi :)

from knacss.

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

from knacss.

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 ?

from knacss.

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

from knacss.

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

from knacss.

Me spammer sera plus facile :D

from knacss.

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."

from knacss.

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..

from knacss.

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).

from knacss.

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 : #11

from knacss.

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é.

from knacss.

@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. :)

from knacss.

@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é.

from knacss.