search

alsacreations / KNACSS

feuille de styles CSS sur-vitaminée
http://www.knacss.com
Do What The F*ck You Want To Public License
554 stars 116 forks source link

Au programme pour KNACSS v3.0 #48

Closed raphaelgoetter closed 10 years ago

raphaelgoetter commented 10 years ago

La milestone v3.0 de KNACSS est prévue pour le mois de juin 20 mai 2014

Voici ce que je prévois de modifier ou rajouter dans cette v3... N'hésitez pas à ajouter votre grain de sel si vous en avez envie.

Prévoir des variables de configuration permettant d'appliquer des styles conditionnels (sous cette forme en LESS) :

Suggestion pour @ ie678 (version LESS) : 

& when (@ ie678 = true) {
    .ie678 .gm-style img {
        height: 100%;  /* IE678 hack for Google Maps images */
    }
    // ... IEfix stuffs
}

Suggestion pour @ styling (version LESS) : 

@ styling: true;

// If you want to style any element or set of features differently from others,
// then set its configuration variable to true or false instead of @ styling
@ styling-code: @styling;
@ styling-blocks: @styling;
@ styling-nav: @styling;
@ styling-tables: @styling;
@ styling-blockquote: @styling;
@ styling-forms: @styling;
@ styling-whatever: @styling;
// etc  }

Styles de citations et séparateurs

Il est prévu de styler un minimum les éléments suivants (si la variable @ styling vaut "true" cf. plus loin) :

blockquote {
    margin-left: 0;
    padding-left: 1em;
    border-left: 4px solid rgba(0,0,0,.15);
    font-style: italic;
}
q {
    font-style: normal;
}
q,
.q {
    quotes: "“\00a0" "\00a0”";
}
q:lang(fr),
.q:lang(fr) {
    quotes: "«\00a0" "\00a0»";
}
hr {
    display: block;
    clear: both;
    height: 1px;
    margin: 1em 0 2em;
    padding: 0;
    border: 0;
    color: #ccc;
    background-color: #ccc;
}

Ajout des classes .start et .end

En complément de .left et .right pour les sites qui se lisent de la droite vers la gauche.

Cela permettra d'avoir des .start {float: right} plutôt que des .left {float: right} sur ces sites.

[dir=rtl] .start {
    float: right;
}
[dir=rtl] img.start {
    margin-left: 1em;
    margin-right: auto;
}
[dir=rtl] .end {
    float: left;
}
[dir=rtl] img.end {
    margin-right: 1em;
    margin-left: auto;
    }
}

Davantage de préprocesseurs

Les préprocesseurs sont devenus suffisamment matures et pratiques en développement qu'il serait dommage de s'en priver.

Je prévois donc une plus grande orientation de LESS et Sass pour KNACSS, par exemple :

REM est supporté sur tous les navigateurs depuis IE9.

Les unités de tailles de polices seront dorénavant traitées en REM (avec transformation en em si le booléen @ ie678est activé).

C'est actuellement déjà le cas pour les niveaux de titres, et je trouve plus simple et plus compréhensible d'écrire : 

h1 {font-size: 2.4rem;} // (avec un fallback .ie678 dans une feuille LESS séparée)

que : 

h1 { .rem2em(2.4);}

Simplifier les grids et autogrids

La solution la plus simple pour supprimer le whitespace d'un display inline-block est l'usage de l'unité rem : il suffit d'affecter une font-size 0 au parent, puis de rétablir la font-size en rem à chaque boîte.

Cela éviterait tous les autres artifices de font-family + letter-spacing + word-spacing + text-rendering et autres cumuls de bidouilles.

Le seul souci est la compatibilité IE9 minimum.

Mais il est assez simple de faire ceci puisque :root n'est reconnu qu'à partir d'IE9 : 

/* whitespace for modern browsers including IE9+ */
:root .grid {
    font-size: 0;
}
:root .grid > * > * {
    font-size: 1.4rem;
}

... et du coup, n'appliquer les bidouilles font-family + letter-spacing + word-spacing + text-rendering que sur IE8 ! (puisque pour IE6/IE7, qui ne comprennent pas inline-block, il y a déjà un hack de inline + zoom : 1)

Utiliser clip pour les contenus masqués

Modifier les styles actuels de .visually-hidden par ceux-ci, plus adaptés aux différents sens de lecture (RTL / LTR) : 

.visually-hidden { 
    position: absolute !important; 
    clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
    clip: rect(1px, 1px, 1px, 1px); 
    overflow: hidden;
    height: 1px; width: 1px;
}

cf : http://developer.yahoo.com/blogs/ydn/clip-hidden-content-better-accessibility-53456.html

Modifier également cette règle en conséquence : 

.skip-links a {
        position: absolute;
        left: -9999px;
        padding: 0.5em;
        background: #000;
        color:#fff;
        text-decoration: none;
    }

Meilleur découpage des fichiers KNACSS

Le fichier 00-config.less sera découpé en trois parties :

Dans la partie suivante, supprimer .mod (inutile car crée déjà un BFC) : 

/* blocks that must contain floats */

.clearfix:after,
.line:after,
.mod:after {
  content: "";
  display: table;
  clear: both;
}

dans la partie suivante, appliquer un line-height: normal : 

code, pre, samp, kbd {
    font-family: Consolas,'DejaVu Sans Mono',Courier,monospace;
    line-height: 1;
    white-space: pre-wrap;
}

Pistes à creuser : https://github.com/raphaelgoetter/KNACSS/issues/52

raphaelgoetter commented 10 years ago

N'hésitez pas à laisser votre avis et vos idées :)

louisremi commented 10 years ago

Super ! rem était le dernier truc qui manquait à knacss pour me convaincre de switcher

direction commented 10 years ago

Désolée je reçois des notifications de ce repo car vous utilisez @direction et ça me signale mdr

KittyGiraudel commented 10 years ago

De mon côté il faut que je revois énormément le framework (côté Sass j'entends). Je vais profiter d'un changement de version majeure pour bouleverser un peu les choses et refactoriser beaucoup de code. La façon dont je gère ça actuellement ne me plait pas du tout. Elle n'est pas clair et peu flexible. C'est nul.

AlexandreBroudin commented 10 years ago

startet endc'est pas terrible à mon avis, je suis plus pour pull et push ou encore pull-origin , push-direction et pour éviter de faire des @ aux users (par exemple @​direction) : http://csswizardry.com/2014/01/use-zero-width-spaces-to-stop-annoying-twitter-users/

raphaelgoetter commented 10 years ago

@direction : oups, désolé:) @AlexandreBroudin : en fait c'est dans la lignée de CSS pour des raisons d'internationalisation justement. par exemple margin-Start, margin-end, flex-Start, flex-end, etc. existent déjà. Je ne ferai que suivre la lignée

AlexandreBroudin commented 10 years ago

Ok, c'est vrai que pour la cohérence c'est bien de rester là dessus en effet. perso je reste quand même sur mon pull & push de mon coté :D

Du coup sur IE ça serait un fallback des margin-start etc. en margin-left dans ce cas pour chaque class, si tu suis cette logique d'internationalisation ? Attention je ne suis pas sur que margin-start/end puissent être auto-prefixés par autoprefixer du moins si on se base sur caniuse

proser commented 10 years ago

Mmmh @ie8support: true; Je pensais d'abord qu'il s'agissait uniquement du support d'IE8. Ptet un @ie678support (ouais c pas forcément mieux).... ?

Et "plus de préfixes vendeur" -> il n'y a pas un risque que les utilisateurs oublient d'utiliser les outils adéquats et qu'il y ait des pertes de compatibilité ? (dans les cas où les préfixes sont encore utiles)

KittyGiraudel commented 10 years ago

Sans être un framework spécialement avant-gardiste, KNACSS n'est pas non plus un framework visant à avoir une rétro-compatibilité très ancienne (si je ne m'abuse) du coup se contenter d'un $support-ie pour activer le support d'Internet Explorer 8- me semble bien.

Faire des variables distinctes pour chaque version d'IE permet un meilleur granulé de la situation mais rend le code plus compliqué ce qui n'est pas non plus merveilleux.

proser commented 10 years ago

+1 avec @iesupport, c'était surtout l'intitulé qui était trompeur pour moi :)

KittyGiraudel commented 10 years ago

Au regard de la suppression des vendor-prefixes, c'est très discutable. Un des avantages de préprocesseurs est de pouvoir dump facilement du contenu notamment via les mixins.

Le mieux serait d'avoir une variable pour gérer ou nom l'affichage des vendors. Ce qui permettrait aux mixins (e.g. flexbox) de ressembler à ça :

// Global variables
$vendors: true;

// Mixin Flexbox
@mixin flexbox($align, $whatever) {
  @if $vendors {
    display: -ms-flexbox;
    /* Other shitty vendors ... */
  }
  display: flex;
}
raphaelgoetter commented 10 years ago

@proser @HugoGiraudel Sur la question du nom de la booléenne concernant IE, c'est vrai que je ne suis pas du tout décidé non-plus :

@HugoGiraudel Pour les préfixes, plus j'y pense et moins j'ai envie de m'embêter à me taper leur duplication systématique. D'autant plus que les outils modernes permettent de le faire facilement automatiquement et surtout en se mettant à jour tous seuls

KittyGiraudel commented 10 years ago

@HugoGiraudel Pour les préfixes, plus j'y pense et moins j'ai envie de m'embêter à me taper leur duplication systématique. D'autant plus que les outils modernes permettent de le faire facilement automatiquement et surtout en se mettant à jour tous seuls

Sauf que tu pars du principe que KNACSS va être utilisé dans un workflow plus large ce qui n'est définitivement pas certain. Ton usage personnel au sein d'Alsacréations implique peut-être un workflow Grunt/Gulp/Autoprefixer ou un quelconque autre système de post-prefixing mais ce n'est pas la majorité.

Maintenant il faut savoir si tu fais ce framework avant tout pour toi et ton équipe en le rendant open-source pour que d'autres en profitent, auquel cas tu fais bien comme tu le souhaites puisque c'est surtout pour toi. Ou si tu tiens un framework open-source visant à servir le plus grand monde, y compris ton équipe auquel cas tu ne peux pas te réduire à "de toutes façons il y aura une Grunt task pour préfixer".

En ce qui concerne le nommage de la variable de support d'Internet Explorer, $support-* est probablement préférable à $*-support puisque ça permet de conserver une bonne lisibilité des variables dans le cas où on aurait des variables similaires pour d'autres navigateurs.

Par exemple :

// Old version support
$support-ie: true;
$support-firefox: false;
$support-opera-mini: false;

... est — selon moi — plus lisible que :

// Old version support
$ie-support: true;
$firefox-support: false;
$opera-mini-support: false;

Ceci étant dit, j'utiliserai surement une map dans la version Sass, rendant les choses plus faciles :

$support: (
    ie: true,
    firefox: false;
    opera-mini: false,
    svg: true
)
AlexandreBroudin commented 10 years ago

+1 @HugoGiraudel à propos d'IE, Pour les prefixes j'ajouterais que rien empêche d'avoir par dessus un autoprefixer dans une tache grunt ou gulp qui nettoierai ta CSS pour la maintenir à jour, c'est pratique pour lorsqu'il y a utilisation des plugins tierce etc. Du coup on peut avoir déclarations des mixins prefixantes ET un autoprefixer

raphaelgoetter commented 10 years ago

@HugoGiraudel : "Sauf que tu pars du principe que KNACSS va être utilisé dans un workflow plus large ce qui n'est définitivement pas certain."

Ben pas forcément. Une majorité des gens vont simplement utiliser la version classique "CSS"... qui dispose des préfixes.

Seules les versions LESS et Sass (?) ne disposeraient pas de préfixes parce qu'ils sont justement dédiés à un public un peu plus connaisseur.

tetue commented 10 years ago

Je ne suis pas gênée par les noms des sélecteurs .left et .right :

Sur ce point, et parce que ce sont des classes utilitaires, c'est le confort de l'intégrateur que je privilégierais plus que la rigueur sémantique du code résultant.

kosssi commented 10 years ago

@raphaelgoetter c'est cool pour la v3.

Par contre je ne comprends toujours pas pourquoi tu te prends la tête avec le CSS...

Je pense réellement que tu gagnerais énormément de temps à maintenir juste la version less. Il suffit de faire un script grunt ou gulp pour générer le CSS dans un dossier built que tu versionnes.

Ainsi tu peux générer une version non minifié, minifié avec ou sans les prefix en quelques secondes.

raphaelgoetter commented 10 years ago

@tetue : oui mais bon, ça n'arrive jamais de se retrouver avec un .left qui se retrouve à droite dans certaines circonstances ? (responsive, RTL, etc.) ? Comme dit, les specs évoluent dans le sens où les directions left et right sont peu à peu mises de côté au profit de start et end. Même si .left ne m'empêche vraiment pas de dormir, je suis de plus en plus convaincu par du .start

raphaelgoetter commented 10 years ago

@kosssi : la meilleure réponse est celle que @HugoGiraudel a donnée un peu avant toi :)

KittyGiraudel commented 10 years ago

Je soutiens start et end en ce qui concerne les directions. Ca colle aux normes et ça a davantage de sens.

mistergraphx commented 10 years ago

Hello, vu qu'il faut pas hésiter à mettre son grain de sel ;) J'ai peut être pas assez lu le code ou utilisé Knacss, mais personnellement j'ai abandonné depuis pas mal de temps les classes qui gère la grille sur mon markup, je n'utilise que dans mon thème des mixins pour générer ce que je souhaite sans toucher au html. L'insertion des span-x ou col-X ou autre n'est utilisable que pour le prototypage rapide : en mon sens. A la base c'est Semantic grid system qui m'as ouvert sur ce sujet, mais j'ai pas l'impression que ce soit intégré a Knacss (surement que je me trompe).

raphaelgoetter commented 10 years ago

@mistergraphx Je ne sais pas si je dois te répondre oui ou non :) Il n'y a pas de span-x ou col-X dans KNACSS en effet, au contraire je pense honnêtement que les grilles sont gérées assez "simplement" et "logiquement". À vrai dire, il y a 2 sortes de grilles :

Ensuite, pour ce qui est de Semantic GS (que je trouve plutôt pertinent), j'en conclus pour le moment que ce n'est pas aussi facile que cela dans la vraie vie.

En effet, dans un site, il y a grosso-modo deux types d'éléments : 1- ceux qui définissent la structure (header, footer, nav, aside, .content, ...) 2- tous les autres

Les principes de semantic.gs s'appliquent principalement sur des éléments de structure... et c'est à mon sens là où il y en a le moins besoin puisque ces éléments n'ont pas (ou peu) de nature à être massivement réutilisables.

Un cas concret de nécessité de réutilisabilité serait celui-ci :

J'ai 10 éléments neutres (div par ex.) quasi-identiques en tous points (couleur de fond, police, propriétés de base)... sauf 1 ou 2 qui doivent se distinguer, par exemple parce que l'un d'entre eux ne doit pas avoir de marge haute.

La question est : comment distinguer facilement cet élément un peu différent des autres ? (et les autres comme lui dans le document ?)

Il va bien falloir leur appliquer une distinction dans le HTML, donc plutôt une classe, donc pourquoi pas faire simple et compréhensible avec une classe ".mt0" ?

Le faire avec un @extend me paraît bien moins pratique puisque de toute façon il faudra distinguer les div avec des classes au final.

Bref, je suis toujours circonspect

Et pour en revenir aux éléments de structure tel que aside, section, header, etc. il ne faut pas se leurrer : en pratique, on va leur appliquer directement des styles (puisqu'il s'agit d'éléments bien définis) sans avoir besoin d'utiliser des @extends qui ne sont censé s'appliquer qu'à des éléments réutilisables.

mistergraphx commented 10 years ago

@raphaelgoetter ;-) +1 : je suis tout a fait d'accord : comme ont dit ça dépend (http://www.lesintegristes.net/2013/03/19/integration-web-humilite/). Dans le cas d'un framework , il peut être utile d'ajouter une possibilité d'utiliser soit un mode "sémantique" soit une mode prototype au cas par cas.

Pour le cas du mt0, je suis pas si convaincu, car sur un mode phone ou tablette on aura peut être pas du tout besoin de cette classe trop typé à mon sens mais utile sur le mode Desktop, et on devra peut être même lui rajouté du margin suivant comment on affiche et à quel endroit. Mais bon question de cas et comme on dis "ça dépend...".

Bonne V3 en tous cas, et merci pour ces travaux qui m'éclairent sur bien des sujets fréquemment.

AlexandreBroudin commented 10 years ago

@tetue start et end ou bien plus de sens que left et right, même si lorsqu'on passe en responsive ça n'a parfois pas plus de sens, même avec la méthode que je préfère pull et push. Mais:

& when (@direction = rtl) {
    .left {
        float: right;
    }
}

Ce n'est vraiment pas bon, sur un projet qui doit avoir du LTR et RTL, avoir un left qui fait du right et un right qui fait du left, je n'y trouve aucun confort, surtout lors du debug.

Comme disait @raphaelgoetter start et end s'alignent sur les specs et ça c'est cool.

@kosssi il y a des gens relativement peu aventureux qui veulent juste pouvoir utiliser la CSS sans se poser de questions, après ça s'adapte à plein de situations le fait d'avoir une CSS déjà compilée.

kosssi commented 10 years ago

@raphaelgoetter Je n'ai pas compris ta réponse. Ce n'ai pas parce que ton produit est utilisé par différents utilisateurs que tu ne peux pas contenter tout le monde ;) Le but pour toi est de mieux structurer KNACSS et ainsi maintenir une version LESS et autogénérer le CSS. L'automatisation fait gagner du temps et donc de l'argent :D

Voila en gros comment je verrai le dossier :

A chaque fois que tu fais une modif du less il faut lancer grunt qui fera l'ensemble des fichiers CSS. Tu peux même mettre un test avec Travis pour vérifier que le boulot est correctement fait pour chaque pull-request. Je peux m'occuper de cette parti si tu veux.

raphaelgoetter commented 10 years ago

@kosssi "Le but pour toi est de mieux structurer KNACSS et ainsi maintenir une version LESS et autogénérer le CSS" --> oui c'est ainsi que je fais, les fichiers CSS sont générés (et autoprefixés) automatiquement à partir des LESS... Sauf que ma structure de dossiers est différente et que je n'utilise pas Grunt mais Prepros. Pour l'instant, je n'ai pa envie de changer de structure ni d'outil puisque cela correspond exactement à notre processus interne dans l'agence. Et ce serait un peu ballot que KNACSS ne corresponde plus à nos besoins ;)

kosssi commented 10 years ago

A ok, autant pour moi ^^, c'est que l'on voit pas les scripts d'autogénération. Ca pose probleme pour ceux qui veulent participer au projet je pense ;)

Bon courage en tout cas pour la suite,

raphaelgoetter commented 10 years ago

Bah, quand on aura basculé sur Grunt / Gulp ou autre Brunch, on en reparlera ;)

PhilippeVay commented 10 years ago

Numéros de version : Après 2.9, il peut y avoir 2.10, 2.11, etc (tout comme il y a jQuery 1.10 toujours compatible IE8 et moins ou Firebug 1.12)

Styles : Il est techniquement réalisable de configurer KNACSS aux petits oignons avec ou sans ces styles via une ou plusieurs variables de configuration/compilation (ça fait suite au retour #45 concernant les styles appliqués à l'élément code). Je souhaiterais que le principe soit étendu aux quelques styles graphiques restants : lister tous les choix de couleur de texte, de fond et de bordure (par exemple #ccc pour les tables) et pouvoir les configurer via un minimum de variables.

Le choix d'une unique variable @styling pour décider de tout styler ou rien, sans plus de granularité ne me semble pas pertinent : il n'y aurait plus moyen de seulement styler l'élément code et pas le reste. Par contre ça me paraît une bonne idée de pouvoir ne rien styler avec une unique variable, c'est-à-dire sans devoir mettre 5 ou 6 variables différentes à @false. Ceci devrait permetre d'avoir plus facilement le choix :

@styling: true;

// If you want to style any element or set of features differently from others,
// then set its configuration variable to true or false instead of @styling
@styling-code: @styling;
@styling-blockquote: @styling;
@styling-something: @styling;
@styling-whatever: @styling;
// etc

Et du coup, tu pourrais ajouter pas mal de choix stylistiques par défaut sans que ça gêne vraiment ceux qui ne les veulent pas (et sans tourner au vrai framework qui style trop de choses).

.start et .end Imposer ces classes me paraitrait lourdingue mais si c'est en complément OK. Ça ralera quand même parce que 98% des webdesigners occidentaux n'ont pas besoin de gérer des sites RTL mais pour les 2% restants, c'est un énorme avantage (on a régulièrement des sites multilingues et déjà eu le japonais à gérer, il arrivera bien qu'on ait l'hébreu ou l'arabe comme contrainte pour un client...)
Par contre attention à ne pas configurer des classes comme .first ou .last dont se sert un CMS comme Drupal ni la dizaine de classes réservées (par moi) sur notre projet maritime. Faudra que je t'envoie la liste (quand je l'aurai retrouvée, hum).

Ton code pour @direction m'a pas l'air d'être la version la plus maintenable (les règles CSS sont séparées des règles LTR correspondantes, double mise à jour à prévoir) mais les 2-3 autres manières de faire que j'imagine ont chacune un inconvénient. À discuter IRL :)

Faire générer les préfixes vendeurs par un outil OK, mais comme déjà évoqué par @kosssi il faudrait indiquer comment tu les génères. Quel outil toi tu utilises avec très exactement les cases cochées, le chemin, etc dans Prepros lors de la compilation LESS vers CSS, quel support des versions de navigateur tu vises (pas Android 2.1, pas Firefox 3.6, etc). Et pour les autres outils (grunt, etc), si tu as l'info, quels options ou fichiers-types même si nous on ne s'en sert pas pour compiler du LESS. Pouvoir reconstruire le répertoire /css/ de KNACSS sans avoir à te demander, ça c'est essentiel de le documenter et pour les autres outils ça faciliterait la prise en main de ceux pas encore à l'aise avec les préprocesseurs/outils.

Unité rem J'utilise actuellement em de la même façon que j'utiliserais rem si je n'avais plus IE8 à supporter pour nos clients ; je ne vois toujours pas l'intérêt de cette unité (ah si, si on me donnait à intégrer des designs avec 15.000 tailles de texte différentes n'importe où. Mais c'est pas un problème de CSS là, c'est le graphiste qu'il faut désintégrer, enfin un problème de qualité). Le problème des em c'est la cascade, bah yaka© éviter la cascade de font-size... [Résolu]

Semantic UI Dans leur 2e exemple qui est un menu, je ne comprend pas facilement que .header se rapporte à la classe parente .menu alors que .menu-header ou .navbar-brand si, sans confusion possible.
Et il se passe quoi si un autre élément/composant utilise la classe .item (ou .header) ; comment ils évitent les conflits en les imbriquant ? Soit on ne peut pas, soit ils ne réutilisent pas .item ailleurs et du coup c'est facile... mais ça empêche quand même l'intégrateur d'utiliser cette classe pour ses besoins. "Griller" des noms de classes aussi simples c'est pas une très bonne idée... Je vois pas mal d'avantages aux préfixes (façon "namespaces").

raphaelgoetter commented 10 years ago

Salut @PhilippeVay et merci pour ton retour très intéressant !

Je vais mettre à jour mon premier post en fonction de certaines de tes propositions : ainsi ce post sera toujours celui de référence.

raphaelgoetter commented 10 years ago

Accessoirement rem est parfait dans certains cas, par exemple pour les whitespaces d'inline-blocks avec un parent en font-size: 0

KittyGiraudel commented 10 years ago

Notes de version : oui, on pourrait utiliser du 2.10 mais franchement, je trouve que c'est plus compliqué à lire (par exemple, jQuery 1.10 j'ai du mal à m'y faire et à me dire que c'est une version ultérieure à la v1.2). Je préfère par conséquent la nomenclature 2.9.5, 2.9.6, ... 2.3

Passer de 2.9 à 2.10 n'a pas la même signification que de passer de 2.9 à 3.0.

Dans le premier cas, tu as apporté des modifications et amélioriations n'entrainant aucun souci de rétro-compatibilité. Dans le second cas, tu as modifié le coeur du projet suffisamment profondément pour entrainer des soucis de rétro-compatibilité, et potentiellement des changements d'API.

Autrement dit, il ne présente aucun risque de mettre à jour un projet en 2.10, par contre il faut être bien prudent lors du passe en 3.0.

D'où le semver.

raphaelgoetter commented 10 years ago

@HugoGiraudel oui oui on est bien d'accord.

Mais je crois qu'on ne parlait pas de la même chose.

Quoi qu'il en soit, les versions mineures seront notées 2.9 ou encore 2.9.5 (et pas 2.10 par exemple); tandis que les versions majeures seront notées 2.0 ou 3.0

nico3333fr commented 10 years ago

Pour le RTL/LTR, pour l'avoir fait sur un site multilingue mêlant les deux, l'option .left et .right qui sont inversés n'est pas si dramatique, ça dépend de deux choses :

Autre danger, les helpers style .ml1 qui peuvent être problématiques à gérer dans ces cas, de ce que j'ai vu, il faut les utiliser avec parcimonie, mais là, c'est plus de l'ordre de la pratique et du talent/cerveau de l'inté.

Ajoutons à cela que tu es fan du display: table, qui se marie très bien avec le RTL, vu qu'il n'y a rien à faire, ça marche tout seul. Dans l'absolu, c'est bien d'y penser, mais est-ce que c'est le truc le plus critique ? Je suis pas convaincu. :)

Perso, je ne cache pas que je ne fais AUCUN site purement en RTL, en général, c'est du multi-langue, et la référence est clairement une langue LTR (anglais souvent).

Si jamais, pour la typo, tu peux aussi enrichir les quotes, j'ai fait ça pour RÖCSSTI, inspiré du chouette taf' de @tetue : 

/*
 * repris de http://tinytypo.tetue.net/ de @tetue
 * tuné avec l'aide de http://www.nicolas-hoffmann.net/utilitaires/codes-hexas-ascii-unicode-utf8-caracteres-usuels.php
 *
 * voir http://en.wikipedia.org/wiki/International_variation_in_quotation_marks pour les références
 */
q {
  quotes: "\201C" "\201D" "\2018" "\2019";
}
:lang(fr) > q {
  quotes: "\00AB\A0" "\A0\00BB" "\201C" "\201D" "\2018" "\2019";
}
:lang(en) > q {
  quotes: "\201C" "\201D" "\2018" "\2019";
}
:lang(es) > q {
  quotes: "\00AB" "\00BB" "\201C" "\201D";
}
:lang(it) > q {
  quotes: "\00AB\A0" "\A0\00BB" "\201C" "\201D";
}
:lang(de) > q {
  quotes: "\201e" "\201c" "\201a" "\2018";
}
q:before {
  content: open-quote;
}
q:after {
  content: close-quote;
}

Question : pour les fonctions qui calculent le rythme vertical, le passage au REM avec fallback en EM n'est pas trop dur à gérer ??? Je serai curieux d'avoir des retours à ce sujet.

raphaelgoetter commented 10 years ago

@nico3333fr

Salut et merci pour tes retours !

Pour ce qui est des quotes, je ne sais pas si tu l'as vu au tout début du billet mais c'est prévu. Ce que j'ai prévu est effectivement plus sommaire, je ne suis pas sûr qu'il faille vraiment aller plus loin, je vais y réfléchir.

Pour le rythme vertical, il faut voir avec @eQRoeil c'est lui le spécialiste ! :)

eQRoeil commented 10 years ago

Hello @raphaelgoetter

Pour la simplification des grilles avec l'utilisation de rem à a place des "bidouilles" comme je te l'ai dit sur Twitter, cela me semble OK. J'avais évoqué le cas récent (suite à un projet avec déploiement d'un type de TV instore) d'une TV tournant sur opera 9 et je m'inquiétais du non support de :not() C'est déjà un cas d'usage rare (sait-on jamais...) , et je viens de vérifier, ladite TV tournait sur opera 9.8 qui supporte :not()

Pour pallier le non-support de :not() je pensais à une CSS spéciale pour ie678 qui comporterait les hacks déjà présents et éviter ainsi l'usage de :not() qui deviendrait inutile

Je pense que c'est ce que tu évoques par "Créer un fichier CSS indépendant pour @ ie678" ?

Pour le reste ( je laisse les préprocesseurs aux spécialistes ;) ) :

.start .end cela me plait bien

les variables aussi, (une idée du % d'utilisateurs de post processeurs parmi les mangeurs utilisateurs de KNACSS ? poll ?) Le risque est la confusion : variables à destination des post-processeurs | variables CSS ?

En ce qui concerne le rythme vertical et fallback em, cela ne me semble pas problématique (pour les calculs en tout cas, à expliquer/appréhender je ne sais pas...) ( + @nico3333fr )

Suggestions :

Pascal ( du coup j'ai changé le nom d'utilisateur pour avoir les mentions ;) )

KittyGiraudel commented 10 years ago

Le risque est la confusion : variables à destination des post-processeurs | variables CSS ?

Il y a une excellente discussion sur la compatibilité variables natives / variables Sass (qui peut s'étendre à n'importe quel pré-processeur) sur le repo de Sass entre Nathan Weizenbaum (lead dev Sass) et Tab Atkins Jr. (spec writer) : https://github.com/nex3/sass/issues/1128

Tl;dr : les pré-processeurs vont devoir s'adapter parce que les spécifications viennent d'être officiellement officialisées de manière officielle.

raphaelgoetter commented 10 years ago

@eQRoeil

Merci pour ton retour éclairé.

Je pense que c'est ce que tu évoques par "Créer un fichier CSS indépendant pour @ ie678" ?

Moui, mais je pense que :not() sera quand-même nécessaire pour éviter d'écrire une règle générale qui serait écrasée par la suite.

Le risque est la confusion : variables à destination des post-processeurs | variables CSS ?

Plus j'y réfléchis, plus je me dis que c'est peut-être encore un peu rapide : comme tu le dis, il risque d'y avoir confusion entre les variables LESS, les variables Sass, les variables "ancienne spec" et les variables "nouvelle spec".

Même si je prévois d'utiliser de plus en plus fréquemment les variables "standards" au-lieu de LESS, je pense que cela ne mérite pas d'être poussé dans un Framework pour le moment... peut-être dans KNACSS v4 ? :)

passer de base à font: 100% (et pas 62.5)

Non, toujours pas, au contraire on y est très attaché. Surtout avec un usage plus massif des rem : c'est un vrai bonheur de lisibilité et de maintenabilité du code de lire font-size: 2.4rem et de savoir immédiatement que cela correspond à un équivalent de 24 pixels.

ajouter des margin et padding basés sur "l'espace de base"

Je me tâte, mais je suis prêt à me faire convaincre

passer en mobile-first ;)

Ouais, idem. Autant je suis fan de la philosophie (en gros), autant je rappelle qu'un media query ne fonctionne pas sur IE<9 et que c'est lourd de devoir passer par du respond.js ou autre polyfill.

En attendant que tout le monde laisse tomber IE8, je trouve plus "secure" de faire du IE8-first

implémenter picture, srcset et css grids dans tous les navigateurs du marché

Tu peux préciser ce que ça représenterait concrètement dans KNACSS ?

eQRoeil commented 10 years ago

@raphaelgoetter

pour ie678 je pense que tu parles d'un fichier indépendant à inclure (si besoin) (?) je pensais plutôt à 2 css différentes : une à destination des IE 678 / une autre pour les browsers. La seconde est clean , la première est agrémentée ( :poop: ) Je suis conscient que ce n'est pas forcément très pratique à l'usage.

variables

Les post processeurs remplacent les variables (voir https://github.com/iamvdo/postcss-vars ) + @iamvdo Les variables CSS sont censées ne pas être remplacées mais évaluées par le navigateur. L'intérêt (à mon avis) d'utiliser les variables avec post processeurs est d'écrire du CSS future proof (avec l'espoir de fournir la CSS avant post processing un jour aux navigateurs) mais les usages sont différents. Les variables CSS permettraient d'avoir des valeurs différentes en fonction du contexte dans lequel on se trouve (par exemple des font-size / line-height / margin différentes en fonction d'une MQ) C'est cette confusion que j'évoque (et c'est peut-être moi qui me plante ;) )

Non, toujours pas, au contraire on y est très attaché.

Je me doutais de ta réponse ;) Du coup passer les margin en rem aussi ? Un fallback px (je parle bien de margin) pose-t-il problème avec les vieux IE et le zoom ? On peut espérer une correction du côté de MS pour cette bizarrerIE)

espace de base Si par défaut les margin et padding sont des multiples de l'espace de base, cela peut permettre de conserver un rythme vertical cohérent avec celui défini dans les Hn, p, ul etc. Rien n'empêche d'utiliser les ml10 ml20 ... ou d'en créer de nouvelles mb23 pt11 pour se conformer à une maquette... Les ml10 etc. sont là à titre d'exemple ("créez vos margin et padding pour vous conformer à vos maquettes") ou correspondent-elles à un besoin récurrent ?

mobile first c'est dans l'optique d'une feuille de style à part pour ie678 (avec reprise des medium-* ou large-* en fonction des MQ...) (En fonction des stats &/ou des styles, c'est parfois moins "casse gueule" de fournir la version mobile avec un max-width aux navigosaures)

Cela n'oblige pas à penser la mise en page mobile d'abord, tu peux très bien commencer par la mise en page desktop. Avoir des styles qui ne s'appliquent qu'à partir d'un certain breakpoint fait que tout ce qui est avant n'est pas affecté. Par exemple tu code un 3 colonnes (en appliquant des classes préfixées .large-*) En dessous du breakpoint initial les styles de cette classe ne sont pas appliqués, les styles par défaut assurent une mise en page 1 colonne... De cette manière il m'est arrivé de faire un projet responsive alors que ce n'était pas demandé par le client, simplement parce que j'ai utilisé ma grille par défaut. J'intégrais pour grands écrans sans me soucier du "en dessous". Je ne dis pas que cela fait tout le boulot évidemment (!) Et pour ce projet je n'ai pas été plus loin pour les petits écrans, cela aurait mérité quelques améliorations bien sûr. (et ce n'était pas une mise en page très complexe, une colonne pour ie678 n'était pas problématique...)

picture, srcset, css grids

Sur un malentendu, dans ton élan je me disais... ;)

ghost commented 10 years ago

Pour ma part, c'est du détail, mais pour revenir au point nommé "Meilleur découpage des fichiers KNACSS", il serait peut-être intéressant de placer toutes les variables dans le fichier principal knacss.less (ce que je fais d'ailleurs manuellement avec cette version), plutôt que de séparer celles-ci dans plusieurs fichiers.

L'avantage est de n'avoir qu'un seul fichier less à ouvrir dans son IDE (le fichier "main"), on y entre/modifie alors la valeur des variables dont on a besoin, on (dé)commente les fichiers less dont on a (pas) besoin, et on y place ses règles, tout ça dans le même fichier. (ouai, je chipote, mais j'économise des clics à ma souris... et je retarde ma future tendinite ! :) Plus sérieusement, c'est toujours assez ch...embêtant de jongler entre plusieurs fichiers de conf, surtout qu'ici, il n'y a pas 500 variables à configurer.

Sinon, tout a fait d'accord pour enlever les préfixes vendeurs. Je passe de toute façon toujours mon css à la moulinette Prepros avant la mise en prod.

Sinon... longue vie à Knacss !

KittyGiraudel commented 10 years ago

Il est de coutume de ne garder que les imports dans le fichier principal. Les variables ont leur propre fichier.

ghost commented 10 years ago

@HugoGiraudel Merci pour ta réponse. Mais il est également de coutume de manger du haggis en Écosse :)... (je n'ai rien contre les écossais, hein !!) Si une coutume n'aboutit qu'à rendre les choses plus difficiles, on peut se demander s'il n'est pas judicieux de faire différemment, non ?

Et puis, comme je l'ai dit, ici, il n'y a qu'une bonne vingtaine de variables, un peu plus dans la v3, ce n'est pas comme un "php.ini" qui en mets dans tous les sens... En suivant cette coutume, il faut alors créer son propre fichier de variables pour ses propres règles qu'on placera bien évidemment dans un fichier à part, ça commence à faire bcp de fichiers, non ? :)

Dans tous les cas, cette idée n'engage que moi. Et au pire, je pourrai toujours transférer les variables dans mon fichier unique.

KittyGiraudel commented 10 years ago

KNACSS n'apporte peut-être qu'une vingtaine de variables par défaut, mais pour un utilisateur de KNACSS raw (sous-entendu non compilé), il n'est pas exclu d'en rajouter.

Pour peu que la personne rajoute une quinzaine de variables, et bien évidemment les commentaires qui vont avec, on peut aisément se retrouver avec une soixantaine de lignes pour la configuration. Ca commence à faire du bon fichier de conf' déjà. Si on y rajoute les imports et leurs éventuels commentaires, le fichier devient très vite assez important.

Ce n'est pas une bonne idée. Les variables servent à la configuration du projet. Les imports servent à diviser le projet en modules. Ce sont deux choses différentes ; elles n'ont pas à être mélangées.

raphaelgoetter commented 10 years ago

Et hop, la V3.0.0 est sortie à l'instant !