New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Road to KNACSS V6 #186

Closed
raphaelgoetter opened this Issue Feb 14, 2016 · 17 comments

Comments

Projects
None yet
6 participants
@raphaelgoetter
Member

raphaelgoetter commented Feb 14, 2016

Idées en vrac / généralités...

Grille

  • Améliorer la grille actuelle. Cf. #207
  • Laisser tomber la bidouille du .01px des grilles actuelles ? EDIT : non, c'est toujours buggué sur IE10-IE11 sans ce hack

Breakpoints

Positionnement

  • Supprimer le positionnement tabulaire. .row et .col n'ont plus lieu d'être depuis Flexbox, peuvent entrer en conflit avec d'autres frameworks et ne font que parasiter KNACSS

Modularisation

KNACSS doit pouvoir être utilisé par morceaux. Je dois pouvoir me contenter du reset + les grilles par exemple, ou bien juste les classes utilitaires, sans que ce soit compliqué.

Séparer dans un dossier spécifique :

1- la config (variables de projet)
2- les vendor (normalize, include-media)
3- les library (base, print, misc, forms, tables)
4- les objects (media, autogrid, grid)
5- les utility classes (positionnement, rwd, helpers)
6- les grilles

À piocher ailleurs

@raphaelgoetter raphaelgoetter self-assigned this Feb 14, 2016

@raphaelgoetter raphaelgoetter added this to the KNACSS 6.0 milestone Feb 14, 2016

@PhilippeVay

This comment has been minimized.

Contributor

PhilippeVay commented Feb 17, 2016

  1. Quelles possibilités de Sass veux-tu utiliser que ne permet pas LESS ? Veux-tu vraiment complexifier le code de KNACSS au point que ce ne soit pas possible de le faire en LESS ? Une des raisons qui m'a fait choisir LESS et pas Sass en 2011 (après des tests approfondis de 0,5j :p ) est que ça reste forcément simple, pas de feature übercompliquée.
  2. Est-ce qu'un framework peut simplifier l'usage de Grid Layout en proposant des classes toutes faites ou bien ce n'est pas plus long de le faire projet par projet avec les classes de son choix ?
    Les .flex-start et .flex-end sont AMHA une super idée pour simplifier l'usage de Flexbox.
    Mais vu que Grid Layout permet de faire ce qu'on veut en 2D et pas selon un simple axe (sans ou avec wrap comme Flexbox), la liberté est telle que... Et à chaque point de rupture, tu peux avoir un layout complètement différent.
    Ce seraient AMHA plutôt les templates de @fvsch qui en profiteraient.
@raphaelgoetter

This comment has been minimized.

Member

raphaelgoetter commented Feb 17, 2016

Quelles possibilités de Sass veux-tu utiliser que ne permet pas LESS ?
Pour commencer, les possibilités de boucles bien plus simples qu'en LESS (et bien pratiques quand on veut générer automatiquement des .grid-2 ... .grid-12 en évitant ce qu'on fait actuellement en LESS

Veux-tu vraiment complexifier le code de KNACSS au point que ce ne soit pas possible de le faire en LESS ?
Le complexifier, carrément pas. Par contre faciliter certaines choses comme le point précédent, oui.

En fait, la raison globalement est encore plus simple : la plupart des usagers de pré-processeurs (autant intégrateurs que clients ou autres) sont plus habitués à Sass. Sans vouloir complexifier ni révolutionner notre process actuel, une migration me semble profitable à moyen-long terme.

Est-ce qu'un framework peut simplifier l'usage de Grid Layout en proposant des classes toutes faites ou bien ce n'est pas plus long de le faire projet par projet avec les classes de son choix ?

Je ne sais pas si cela mériterait encore de s'appeler "framework" tant les possibilités natives de Grid Layout sont grandes.
Ceci dit, quelques classes bien choisies permettraient de faciliter les choses, et surtout d'apporter une sorte de consistance en nommage.

Dans cette démo, par exemple : http://codepen.io/raphaelgoetter/full/ZQLBxd/

On pourrait classer et automatiser pas mal de choses :

  • nombre d'éléments dans la grille
  • premiers et derniers dans l'ordre
  • row et col spanning
  • gouttière ou non
  • etc.
@ericemc3

This comment has been minimized.

ericemc3 commented Feb 22, 2016

Bonjour,
je suis d'accord avec ces évolutions.

Et pourquoi ne pas laisser tomber la technique du 62.5% par la même occasion ?

@fgirardey

This comment has been minimized.

Contributor

fgirardey commented Feb 22, 2016

Personnellement je préfère garder la technique du 62.5%.

Si le problème de conversion entre rem et em pose problème c'est généralement parce qu'on utilise pas les rem pour les bonnes raisons.

@ericemc3

This comment has been minimized.

ericemc3 commented Feb 22, 2016

beaucoup en reviennent, et d'ailleurs l'excellent ouvrage (CSS3, pratique du design web) cosigné par Raphaël expose assez bien en quoi c'est une bidouille assez laide et une mauvaise pratique...

@fgirardey

This comment has been minimized.

Contributor

fgirardey commented Feb 22, 2016

Ah oui je vois, moi je dis ça parce que le seul moment où ça a pu me poser problème c'était parce que je n'utilisais pas les bonnes unités pour les bonnes raisons. Après ça m'intéresse de savoir à quel niveau c'est une mauvaise pratique.

@raphaelgoetter

This comment has been minimized.

Member

raphaelgoetter commented Feb 23, 2016

Bon. En ce qui me concerne, je ne cautionne qu'en partie l'idée que ce soit une mauvaise pratique.

Voici ce que dit le livre CSS3 de Hugo :

Dans le but de simplifier les calculs de tailles de police, il est coutume de définir la taille de la
police de la racine du document (l’élément html) à 62.5 % via la déclaration suivante :

/**
* Taille par défaut du navigateur : 16 px
* 16 × 62.5% = 10 px
*/
html {
font-size: 62.5%;
}

En effet, tous les navigateurs ont par défaut une taille de police de 16 pixels. Or 16 × 62.5
vaut 10, ce qui rend tous les calculs autour de l’unité rem extrêmement évidents. Besoin de
l’équivalent de 16 pixels ? Facile, c’est 1.6rem.

Malheureusement, je me dois de faire l’avocat du diable et de vous intimer de cesser cette
mauvaise pratique. Effectivement, cette astuce transforme des calculs pénibles en simples
opérations mentales, mais elle présente aussi des inconvénients.
En effet, elle va nécessiter de redéfinir la taille de la police de tous les conteneurs textuels, tels
que p, li, les titres, et bien d’autres encore. Les calculs sont donc plus simples, mais en même
temps plus nombreux !
En définissant la taille de police de la racine du document à la taille de texte désirée, généralement
entre 12 et 20 pixels, on s’abstient de devoir redéclarer la font-size sur tous les éléments !

Mais ce que ne dit pas le livre (et tous les articles contre cette pratique), est qu'il n'est pas du tout nécessaire de devoir redéfinir la taille de tous les éléments textuels... il suffit d'ajouter une règle très simple :

body {
  font-size: 1.4em; /* la taille de base pour tous les éléments sera un équivalent de 14px */
}

C'est aussi simple que cela, et c'est ce que fait déjà KNACSS depuis très longtemps.

En bref, avec cette technique :

  • on conserve une taille de base fluide de 1.4em/px pour tous les éléments (= on ne casse rien du tout)
  • on bénéficie d'une compréhension et d'une maintenance de code ultra-simplifiée dès lors qu'on utilise des rem sans pré-processeurs. Parce qu'un jour on se passera de pré-processeurs ;)
@ericemc3

This comment has been minimized.

ericemc3 commented Feb 23, 2016

et merci pour ces explications fort détaillées ! Cela n'alourdit pas le code en effet autant que certains le prétendent. Mais les "plus" me paraissent insuffisants eu égard aux inconvénients d'une pratique non standard, et qui semble en perte de vitesse

@fgirardey

This comment has been minimized.

Contributor

fgirardey commented Feb 23, 2016

Mais quels sont les inconvénients du coup @ericemc3 ? Comme le dit @raphaelgoetter une simple règle sur le body évite d'alourdir le code. Tu vois d'autres soucis potentiels ?

@ericemc3

This comment has been minimized.

ericemc3 commented Feb 23, 2016

ce qui me gêne juste c'est la compatibilité entre différents projets. Pour certains je compte utiliser Knacss, pour d'autres je m'appuie sur d'autres librairies/frameworks, et jongler dans les media queries, d'un projet à l'autre, entre différentes significations des unités me trouble. Je m'étais dit au début, ce n'est pas grave, tout le monde va passer à cette règle du 62.5 %, qui devient un standard. Mais j'ai l’impression que c'est plutôt l'inverse. Maintenant, ce n'est pas dramatique, et Knacss est un superbe outil

@fgirardey

This comment has been minimized.

Contributor

fgirardey commented Feb 23, 2016

C'est pas faux ce que tu dis @ericemc3… à choisir sur d'autres projets je préfère également 1rem = 16px, faudrait faire un sondage 😇

@fvsch

This comment has been minimized.

fvsch commented Feb 23, 2016

Perso je préfère:

html {
  /* With default browser settings, 1rem = 20px */
  font-size: 125%;
}
body {
  /* For instance, if we want to default to 15px */
  font-size: .75rem;
}

Okay ça rajoute une division par 2, ce qui peut perturber un peu, mais c’est pas Maths Sup.
Et c’est vachement courant d’avoir des écarts de 20px (ou multiples de 20) dans un design.

Mais bon c’est pas indispensable.

Ah oui et un problème qu’avait la technique du 62.5% à une époque c’est que certains navigateurs avaient des options pour fixer une taille de texte minimum, et si on la fixait à 12px par exemple le font-size de l’élément html restait à 12px, puis on demandait par exemple du 1.5em pour obtenir du 15px mais on obtenait donc du 18px.

@raphaelgoetter

This comment has been minimized.

Member

raphaelgoetter commented Mar 6, 2016

Bonjour et merci à tous pour vos arguments et explications.

Dans notre équipe, la règle du 62.5% est toujours largement et unanimement appréciée : aucun bug connu nulle part, une maintenance et une lecture du code simplissime. Bref, on ne va certainement pas modifier ce point à court terme dans KNACSS.

En tout cas, on préfère toujours cette règle plutôt que celle choisie par Bootstrap dont même la toute dernière version impose encore du pixel :

Bootstrap's global default font-size is 14px, with a line-height of 1.428.

(beurk)

@ericemc3

This comment has been minimized.

ericemc3 commented Mar 6, 2016

Bonjour,

cela me parait en effet sensé, si c'est simple et que ça marche, oublions les débats métaphysiques !

Merci pour ce débat fort intéressant.

@nico3333fr

This comment has been minimized.

Contributor

nico3333fr commented May 16, 2016

Y a un léger bug sous IE9-11 avec le 62.5%, l'arrondi donne 9px et des poussières : cela se fixe avec :
font-size: calc(1em * 0.625);

Juste au cas où ;)

@raphaelgoetter

This comment has been minimized.

Member

raphaelgoetter commented May 16, 2016

@nico3333fr : oui c'est en place depuis un petit bout de temps normalement : https://github.com/alsacreations/KNACSS/blob/master/sass/_01b-base.scss#L43 ;)

@nico3333fr

This comment has been minimized.

Contributor

nico3333fr commented May 16, 2016

@raphaelgoetter autant pour moi, j'ai regardé la version CSS un peu trop vite :)

@raphaelgoetter raphaelgoetter changed the title from KNACSS V6 to Road to KNACSS V6 Jul 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment