Bonjour,
qu'appelle-tu performance ? Rapidité avec laquelle tu vas pouvoir avancer dans ton projet grâce à ce framework ou rapidité d'affichage due à l'utilisation de sélecteurs CSS performants (ou plutôt de la non-utilisation de sélecteurs non-performants comme *) ?
Jamais utilisé mais à la lecture du code (contexte : je connais trèèèès bien KNACSS, ai décortiqué et utilisé Bootstrap et vu passer pas mal de frameworks dont j'ai au moins regardé le code)
- très minimaliste et c'est ce que j'aime dans un framework (le changelog de la dernière version c'est "virer tout le JS et les tabs")
- dans l'ensemble bien pensé, à aucun moment j'ai sauté de ma chaise en me disant "Naaan !"
- le nommage pour la grille est délibérément simple : multi-classe avec un nombre et columns (column sans s possible si c'est avec "one"), alpha et omega. Je suis habitué au nommage à la Bootstrap que je préfère (.span8) mais celui-ci fait le choix d'être proche du langage naturel, c'est moins prise de tête sûrement. Idem pour .offset-by-N
Par contre, si on a pas de gouttière dans sa grille, on fait comment ? C'est pas très tout terrain j'ai l'impression. Mais si le design correspond toujours au choix fait par Skeleton, pas de souci.
- support IE7+, parfait. En début de semaine, j'ai ouvert au moins 2 pages de projets IE9+ et IE10+ je crois. Je dois supporter IE8+ (dernière version d'IE sur Windows XP, merci MS), je n'ai que faire de ce genre de chose pour l'instant... Et puis coder des frameworks quand on a droit à :last-child et :nth-child() c'est même plus du jeu... ^^ Bref, il faut regarder systématiquement le support ; le choix fait par d'autres n'étant pas toujours celui dont on a besoin.
- formulaires : il y a l'air d'y avoir l'essentiel, correctement fait
- le reset à la E. Meyers (sic) ne me plaît pas. Ça "pourrit Firebug" enfin rallonge l'affichage. Exemple je vois pas quel navigateur aurait besoin d'un reset pour margin: 0; padding: 0; border: 0; de l'élément div... Normalize.css serait bien plus proche de mes goûts en matière de "reset".
- la typographie est en pixels de A à Z. Je n'utilise que les em pour la taille de texte et sans unité pour line-height. Pour font-size en unité relative em, c'est un choix d'accessibilité mais pour line-height, c'est juste que j'ai pas besoin de changer la valeur à chaque fois que font-size change. Au lieu d'avoir 20px et 30px, je mettrais au moins 20px et 1.5. Si je change 20px pour 24px, pas besoin d'aller mettre 36px pour line-height... Le line-height de H1 et H2 est très faible ; ça donne quoi sur 2 lignes avec lettres accentuées et jambages ?
- les MQ existent mais ne font pas grand chose. Pas de classes d'aide ("helpers"), pas de convention (préfixe .large-* pour des classes n'ayant une action que en 1280+ par exemple).. C'est sûrement plus souple et permet le cousu main, pas de choix fait par le framework mais comme à l'usage j'ai souvent besoin de classes HTML spécifiques au RWD, ça a fini par se retrouver dans KNACSS qui fait très exactement ce dont j'ai besoin avec ses .small-w100 ou .large-mb0... Plus adapté à de gros projets, pour de petits projets on voudra sûrement utiliser comme sélecteur CSS dans une MQ les sélecteurs spécifiques au projet déjà utilisées avant la MQ.
- les instructions CSS ne sont pas écrites selon un ordre défini par une convention (alphabétique ou à la
http://csslisible.com/fr/ qui est notre convention interne). Peu importe la convention, le tout c'est d'en avoir une. Bon si on doit pas modifier Skeleton c'est pas bien grave...
- il y a un line-height de 1 sur body (hu ?) puis de 21px via la propriété font un peu plus loin ("14px/21px") donc la 1ère déclaration ne sert à rien
Pour de petits projets, un tel framework très minimaliste (
micro-framework d'après Raphaël et Nico3333fr) où ensuite tu peux et dois tout faire toi-même m'a l'air correct.
Modifié par Felipe (25 Jan 2014 - 09:41)