alsacreations / knacss

feuille de styles CSS sur-vitaminée

KNACSS

Né en 2012 et après plus de 10 années de bons et loyaux services, le projet initial « KNACSS » d'Alsacréations est officiellement obsolète, n'est plus maintenu et ne sera plus mis à jour.

Documentation version v8 (v8 = Reborn)

• Site web de présentation de KNACSS Reborn : https://www.knacss.com/
• Documentation KNACSS Reborn

Documentation anciennes versions (v7)

• Documentation KNACSS v7
• Pense-bête PDF KNACSS v7

knacss's Issues

Print stylesheet improvements

What about:

1. Turning all images to black and white with CSS filters when printing?

img { 
  filter: grayscale(100%);
}

(Plus vendor prefixes.)

2. Removing all background-images and shadows?

* {
  background: transparent !important;
  box-shadow: none !important;
  text-shadow: none !important;
}

3. Avoiding a useless :after attribute when dealing with empty or JS links?

a[href^="javascript:"]:after,
a[href^="#"]:after {
    content: "";
}

[Sass & LESS] Variables par défaut

Les versions LESS et Sass pourraient proposer une panoplie de variables, notamment pour des couleurs de départ par exemple.

C'est une bonne idée ou on sort du cadre du framework ?

.line dans la dom vs .line dans un fichier less

Slt slt,

Quand j'utilise dans la dom:

<div class="line">lorem</div>

j'ai bien dans mon inspecteur :

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

Mais quand ma dom est :

<div class="test">lorem</div>

et que je fais dans mon fichier less :

.test{.line;}

je n'ai pas dans mon inspecteur :

.test:after{
content: "";
display: table;
clear: both;
}

Je ne crois pas que se soit un comportement normal ou une particularité de mon projet.

En tous cas, j'ai corrigé dans le fichier 01-base.less avec :

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

Masquer les scripts

On a toujours cette règle dans le fichier base :

body > script {
    display: none !important;
}

Est-elle toujours d'actualité ? Si je ne m'abuse on s'en servait lorsque le body était directement défini en display: table, mais KNACSS ne propose plus le modèle tabulaire (sauf erreur).

Correction de commentaire (pixels -> em)

Corriger le commentaire :

s,m,l,n,0 = small(10px),medium(20px),large(30px), zero or none(0)

Affichage gênant du ruban sur le site

Bonjour,

Sur un écran de moins de 10 pouces, le ruban vert en position fixed du site gêne assez la lecture du contenu.

Edit : suppression de la question + modification du titre

Nouveau systeme de grille ?

Suite à des discussions très intéressantes avec Pascale C. @eQRoeil, je me tâte de plus en plus à modifier radicalement le système de grilles actuelles de KNACSS.

Actuellement, il existe deux systèmes de grilles (c'est d'ailleurs le 1er problème) :

• les .grid
• les .autogrid

En détail : http://knacss.com/demos/tutoriel.html#grids

Avantages des grids (float):

• syntaxe simple
• colonnes de même largeur ou non
• gouttières modifiables

Inconvénients des grid :

• flottants
• gouttière en % uniquement
• une seule ligne possible (un .grid4 ne peut contenir que 4 éléments exactement)

Avantages des autogrids (inline-block):

• syntaxe simple
• les éléments se répartissent automatiquement, on ne se soucie pas des gouttières
• on peut avoir autant d'éléments qu'on veut, ça continue à marcher tout seul

Inconvénients des autogrids :

• on ne peut pas décider de la largeur des gouttières

Au final, aucun des deux n'est vraiment parfait et surtout la présence des deux systèmes est confusant.

Pascal propose une alternative issue de SUIT CSS, qui consiste en un remix des deux : une sorte d'autogrid avec des gouttières définissables.

http://codepen.io/raphaelgoetter/pen/wuamr

L'avantage est qu'un seul système pourrait répondre à tous les besoins

L'inconvénient est que cela nécessite forcement un conteneur supplémentaire dans le HTML, et donc une modification complète et irréversible de KNACSS (pas de rétrocompatibilité possible).

Qu'en pensez-vous ? On se lance ?

Google Maps "Pegman" and img { max-width:100% }

Rule:

    img { max-width: 100% }

makes Pegman from GMaps disappear. Problem reported on Alsacréations forum by Derwoed.

I could confirm this bug on previous Google link, by adding the rule on Firefox 21.

Pegman is displayed with the following code:

 <div style="width: 32px; height: 40px; overflow: hidden; position: absolute; left: 0px; top: 0px;">
   <img draggable="false"
           src="http://maps.gstatic.com/mapfiles/cb/mod_cb_scout/cb_scout_sprite_api_003.png"
           style="position: absolute; left: -9px; top: -102px;
                     -moz-user-select: none; border: 0px none;
                     padding: 0px; margin: 0px;
                     width: 1029px; height: 255px;">
</div>

A parent div has the class .gmnoprint: it could be a way to remove max-width from its content, but maybe not the best way of managing this bug.

classes manquantes version LESS (largeurs de blocs)

Hello,
dans la version Less des fichiers, les largeurs de blocs s'arrêtent à 960PX (sauf erreur) ?

Au programme pour KNACSS v4.0.0

La milestone v4.0 de KNACSS est prévue pour le mois de février 2015

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

• Laisser tomber IE8
• Ajout de variables CSS "standards" (à méditer)
• Passer toutes les grilles et gouttières en Flexbox
• Se débarrasser de la plupart des !important grâce à un meilleur usage des media queries

Laisser tomber IE8 et old Android

Pour pouvoir enfin faire du Web : http://blog.goetter.fr/articles/ie8-must-die/

• utiliser rem (sans fallback)
• utiliser Media Queries sans fallback
• utiliser calc(), nth-child, :not
• fontes en .woff
• etc

Ajout des variables "standard" CSS

Les variables commencent à être utilisables en CSS :

EDIT : en fait pas tant que ça... à méditer donc

Passer toutes les grilles et gouttières en Flexbox

Quelques pistes :

• http://www.alsacreations.com/tuto/lire/1659-une-grille-responsive-avec-flexbox-et-LESS.html
• KNACSS grid flexbox : http://codepen.io/raphaelgoetter/pen/mzKrh?editors=110
• KNACSS autogrid flexbox : http://codepen.io/raphaelgoetter/pen/nkgKp?editors=110
• http://flexboxgrid.com/
• http://philipwalton.github.io/solved-by-flexbox/demos/grids/

Se débarrasser de la plupart des !important grâce à un meilleur usage des media queries

La plupart des !important apparaissent dans des contextes spécifiques (Responsive, notamment), pour écraser des règles de base.

En laissant tomber IE8 et en utilisant plus massivement les media queries, il sera très simple de faire des conditions exclusives :

• si je suis sur grand écran, alors la marge sera X
• si je suis sur petit écran, alors la marge sera Y

... ainsi, plus la peine d'écraser sauvagement à coup de !important

autogrid justify needs whitespace

Hello,
KNACSS uses text-align: justify for autogrid. I generate HTML from PHP, and noticed that DIV children of an autogrid DIV had no gaps between them. When generating the HTML for the DIV's in PHP, i had to include an extra "\n" character after each closing DIV tag to get them justified in the autogrid.
On codepen you can check this: remove all whitespace between the DIV's in the autogrid2 example: the gap between them disappears.

Of course i do not like to generate the "\n" in PHP just because of the autogrid.

.autogrid2 > *:after { content: " "; white-space: pre; display: inline-block; }
did not work. maybe someone with more css knowledge could pull this off in css only.

Refonte des calculs des em dans le reset ?

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

A propos des styles de police

Actuellement on a ça :

html {
font-size: 62.5%;
}

body {
background-color: #fff;
color: #000;
font-family: "Century Gothic", helvetica, arial, sans-serif;
font-size: 1.4em;
line-height: 1.5;
}

Pourquoi pas :

html {
    font: 62.5%/1.5 "Century Gothic", helvetica, arial, sans-serif;
}

body {
    font-size: 1.4em;
}

Plusieurs choses effectuées :

• retrait de background-color: #fff et color: #000 puisque cela correspond aux valeurs par défaut (ou alors j'ai raté quelque chose ?)
• utilisation de la déclaration shorthand pour les propriétés relatives à font
• remontée de toutes les déclarations d'un cran (l'idée était surtout d'utiliser la version raccourcie, peu importe que ce soit dans html ou body)

Des avis ? :)

Petit ménage

Supprimer quelques !important inutiles (poke @IamnotCyril)

Supprimer le reset sur b et i (poke @geoffrey_crofte)

Changer la licence de KNACSS

Passer en WTFPL

http://fr.wikipedia.org/wiki/WTFPL

répétition inutile

supprimer textarea, figure, label du "soft reset" car déjà ciblés précédemment

Passer toutes les grilles et gouttières en Flexbox

voilà voilà voilà :)

code rule too invasive

The code rule (and some others) is a little bit invasive and anoying since it define some colors not necessarily compatible with other frameworks.

Please consider the use of 3rdparty CSS rules styling the <code> element (like prism).

The final website integrator doesn't control these two frameworks and the final rendering is not very nice :(

I suggest to disable any "styling" rule to keep only layout ones, or at least defining dedicated classes for these presets (not necessarily bad by the way!).

Century Gothic n'est pas une police systeme

Je sais que tout le monde aura tendance à modifier la typographie, mais je crois que Century Gothic n'est une police systeme que sur certains Windows (et qui n'a rien à voir avec Helvetica ou Arial).

Passer en unité rem (milestone 3)

Juste un post-it si jamais j'oublie :)

Au programme pour KNACSS v3.0

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.

• Booléens
• Styles de citations et séparateurs
• Ajout des classes .start et .end
• Davantage de préprocesseurs
• Passage à (davantage de) REM
• Simplifier les grids et autogrids
• Utiliser clip pour les contenus masqués
• Meilleur découpage des fichiers KNACSS
• Corrections diverses

Booléens

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

• @ ie678 : true; // "true" to activate IE6/IE7/IE8 support
• @ gmaps : true; // "true" to activate google maps fixing
• @ styling: true; // "true" to design basic elements like code, mark, blockquotes, tables, etc.
• @ skip-links: true; // "true" to design skip links for accessibility concerns
• @ hyphens: true; // activate automatic hyphens on small screens
• @ helpers-width: true; // decide whether or not you need width helpers
• @ helpers-spacing: true; // decide whether or not you need spacing helpers

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 :

• fichier de config avec des variables pour construire son projet (ça c'est déjà le cas)
• se débarrasser des préfixes vendeurs (-moz-, -webkit-, ...) dans les versions LESS, et Sass de KNACSS : cela pourra être géré de façon automatique par plein d'outils (Autoprefixer, Prepros, Grunt, etc.). Note : il est essentiel de bien documenter cette partie
• des booléens permettant de construire ses CSS selon des choix : support des anciens IE ou non, styles de mise en page minimum ou non, etc.

Passage à (davantage de) REM

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 :

• 00-config.less (uniquement la config générale)
• 01- fonts (tailles et familles de polices)
• 02-colors (couleurs et backgrounds)

Corrections diverses

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

• proposer un meilleur affichage pour les kbd imbriqués (si @ styling-code = true). Exemple : <p>To make George eat an apple, press <kbd><kbd>Shift</kbd>+<kbd>F3</kbd></kbd></p>

• supprimer les styles de code dans <pre> <code>

• Ajouter une font-stack pour les titres h1; h2 et h3

• Créer un fichier CSS indépendant pour @ ie678 et @ styling

• Ajouter un Break Point "medium" pour obtenir au final :

  • tiny : <=320
  • small <= 480
  • medium : <=768
  • (normal)
  • large : >1280

• Modifier la règle (trop spécifique) :

  :not(.gm-style) img {
  height: auto !important;
  }

• Ajouter quelques values supplémentaires dans le fichier de config.less : tiny-value, extra-large-value, ultra-large-value

• Rétablir l'alignement de texte text-align: left pour les enfants des autogrids [class*="autogrid"] > *

• Corrections de certains :after :

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

Pistes à creuser : #52

KNACSS LESS : supprimer les préfixes

Je prévois de supprimer toutes les déclarations préfixées (webkit, moz, ms, etc.) au sein de KNACSS en version LESS.

Je rajouterai un avertissement pour prévenir qu'il sera sans-doute nécessaire de s'occuper soi-même de l'ajout de ces préfixes (ce qui est généralement fait automatiquement aujourd'hui : autoprefixr, mixture, prepros, grunt, etc.).

L'avantage étant de gagner beaucoup en lisibilité, et de raccourcir le code initial.

Si jamais vous avez des arguments convaincants pour m'en empêcher, n'hésitez pas :)

NOTE : si Hugo Giraudel est de mon avis, il serait bienvenu de mettre à jour la version Sass en même temps :)

correction marges .grid

Prévoir une sécurité margin-left: 0

.grid > * > * {
  margin-left: 0;
}

Une bizarrerie ? (wordpress get template part)

Hello et bravo pour ce super outil !
je viens de m'arracher les cheveux quelques heures sur une bizarrerie dont je vous livre les détails.. si vous pouvez reproduire / comprendre... ?

je fais un template wordpress avec knacss, et tout heureux avec mon autogrid je le place juste avant un get template
ul class="products autogrid5" >
have_posts() ) : $loop->the_post(); get_template_part( 'content', 'product' ); endwhile; ?>
/ul>

dans mon content-product.php j'ai un simple
li class="prodInList" style="" id ="product ">

/li>

et la, HORREUR le dernier li (coloré) n'arrive pas jusqu'a bout du conteneur, mais s'arrete une dizaine de pixels avant !!
apres moultes arrachages de cheveux dont je vous epargne les détails j'ai juste remplacé le get_template par le contenu de content-product et tout est rentré dans l'ordre...

bizarre, incomprehensible, je ne trouve pas les mots...

si vous avez une idée... !

Bonne continuation !

Remplacer overflow: hidden par display: table ?

KNACSS se base sur des éléments .mod dotés d'un overflow: hidden afin de leur donner des "superpouvoirs" (cf. http://www.alsacreations.com/astuce/lire/1543-le-contexte-de-formatage-block-en-css.html )

A priori, overflow: hidden ne pose guère de problèmes, mais il n'est quand-même pas anodin (puisqu'il va masquer tout contenu susceptible de déborder). En clair, c'est loin d'être parfait.

Je me tâte de plus en plus à le remplacer par un autre moyen de disposer de "superpouvoirs", à savoir display: table (eh oui, les tableaux c'est la vie !).

Les voici en action : http://codepen.io/raphaelgoetter/full/GaqLr

Rappel : le support de display: table est IE8+

Qu'en pensez-vous ?

variable pour RTL et LTR

Note pour moi-même : idée LESS pour KNACSS : https://twitter.com/PhilippeVay/status/428475047297040384

Retrait des imports superflus

En tête de chaque fichier LESS, on peut lire :

@import "00-config";

A moins que ce ne soit différent en LESS, il n'y a pas besoin de ça puisque c'est le fichier knacss.less qui fait tous les imports.

Je propose donc de retirer cet import superflu de chaque fichier, et de ne pas le mettre dans la version Sass non plus bien sur.

Conserver le commentaire de présentation de licence

Il y a une convention pour les licenses dans les commentaires afin d'éviter qu'elles soient supprimées lors d'une minification (si le minifier respecte cette convention, ce qui est le cas de YUI minifier par exemple). Ça consiste à faire suivre l'ouverture du commentaire par un "!" comme ceci :

/*!
* www.KNACSS.com V2.8b (2013-09) @author: Raphael Goetter, Alsacreations
* Licence CC-BY http://creativecommons.org/licenses/by/3.0/fr/ 
*/

(merci à cahnory pour l'idée)

Grilles et typo

Trouver un moyen de corriger automatiquement les problèmes de grilles et de typo "exotiques".

Illustration du problème : http://forum.alsacreations.com/topic-4-69187-1-Knacss-grid-et-google-font.html

Solution trouvée par Pure : http://blog.purecss.io/post/60789414532/how-we-improved-grids-in-pure-0-3-0

hgroup

hgroup a été retiré des specifications, aussi la règle le concernant dans le fichier base doit être modifiée.

Is 62.5% a bad practice?

Hey,

Some developers http://csswizardry.com/2011/05/font-sizing-with-rem-could-be-avoided/ http://stackoverflow.com/questions/1672514/what-are-good-and-bad-points-if-i-use-body-font-size62-5 argue that having the below code is a bad practice.

html {
font-size: 62.5%;
}

However, Mozilla kind of encourages this approach https://developer.mozilla.org/en-US/docs/CSS/font-size

What are your thoughts?

Correction grid reponsive

ajouter du poids à la règle (important) :

@media (max-width: 640px) {
.grid > * > * {width: 100% !important}
}

Surtout : problème de white-space dû à word-spacing, à corriger d'urgence : http://codepen.io/raphaelgoetter/pen/xantf

Supprimer les unités "em" dans les line-height

il reste des em inutiles.

Skip links

A l'heure actuelle, les skip-links sont gérés en les sortant de l'écran via un position absolu à -7000px sur la gauche. Ca marche, mais ça demande quand même au navigateur de créer une box de 7000px de long.

Aussi, je suggère de passer sur une méthode plus simple :

.skip-links {
  position: absolute;
}

.skip-links a {
  position: absolute;
  clip: rect(0 0 0 0);
  padding: 0.5em;
  background: black;
  color: white;
  text-decoration: none;
}

.skip-links a:focus {
  position: static;
  clip: none;
}

Attention, code non testé. L'idée est simplement de passer sur clip: rect().

Why forcing background-color to white in body?

Pas compris l'intérêt et en l'occurrence, ça génère un problème pour moi (pas compris la cause) :

J'ai appliqué une ombre à l'élément body et je suis obligé d'ajouter un background-color: transparent; lorsque j'utilise KNACSS

body {
    margin-left: auto;
    width: 75%;
    box-shadow: 0 0 12px rgba(0, 0, 0, .8);
}

Knacss et Gmap API v3

Bonjour !

j'ai recontré un petit souci avec les infobulles (InfoWindow) de ggmap.

• absence de la croix de fermeture (juste 2px du bord gauche de l'image)
• débordement vertical des images contenues dans l'infobulle, par exemple les infobulles faites par gmap lui même sur des éléments cliquable de la carte, avec une preview de la streetview. (à noter qu'après fermeture et réouverture de l'infobulle, l'affichage était bon).

solutions trouvées

• problème de la croix résolu en ajoutant la règle .gm-style img {max-width : none;}
• problème des débordements d'images résolu en supprimant la règle img {height:auto;}

Unstyled lists feature request

Petite feature request :

Bien souvent, j'utilise des listes pour structurer des listes de choses mais qui n'ont pas vocation à être présentées en tant que liste avec bullet.

ul.unstyled {
    list-style-type: none;
}

Pistes à étudier

Bonjour Raphael, utilisant ces derniers temps knacss sur plusieurs sites en construction et apportant toujours les mêmes modifs, j'ai décidé de les noter et de t'en faire part. J'ai aussi mis des suggestions, des pistes à réfléchir... bref si ça peut faire avancer le schmilblick, tu vois ! (on a déjà échangé sur alsacreations, pseudo Newzic).

---

Lors du téléchargement d'un knacss depuis http://knacss.com/builder/, le fichier knacss contenait le tout en 2 fois.

---

h1-like... ce serait bien aussi un p-like ?

p, .p-like,
ul,
ol,
dl,
blockquote,
pre,
td,
th,
label,
textarea,
caption,
details,
figure,
hgroup {margin-top: .75em;
margin-bottom: 0;
line-height: 1.5}

.p-like {font-size: 100%}

---

Valeurs 0.xxx, inutile de mettre le 0 : https://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml

"Leading 0s
Omit leading "0"s in values.
Do not use put 0s in front of values or lengths between -1 and 1.
font-size: .8em;"

Dans Knacss, on trouve quelques valeurs sans le "0" avant le point mais certaines (h1, h2, h3 par exemple) commençant par "0."

---

/* ==tables*/

On a 2 déclarations qui pourraient être regroupées en une seule :

table {width: 100%;}

et quelques lignes en dessous il y a :

table {border: 1px solid #ccc}

---

L'économie de code étant à la mode, pourquoi avoir le choix entre 2 façons de nommer :

.m-reset, .ma0 {margin: 0}

Pourquoi ne pas opter pour une seule façon de nommer ? La plus courte tant qu'à faire :

.ma0 {margin: 0}

Idem pour .ma1, .mas, .ma2, .mam, etc. (pour ma part à chaque utilisation de knacss, j'efface tous ces doublons).

---

.clear ou .clearfix ? On trouve les 2

---

Manquerait :
.small-pa0 {padding: 0 !important}
.tiny-pa0 {padding: 0 !important}

(car on l'a pour les margin).

---

Puisqu'on a
strong {font-weight: bold}
il faudrait alors :
strong , .strong {font-weight: bold}
et
.no-strong {font-weight: normal}

Et sinon des notations plus courtes ? (400 pour normal, 700 pour gras)

---

grid

Lorsque l'on utilise un h1 (ou autre h) comme premier élément dans une grille (grid), on perd la marge supérieure.

-div class="grid"-
-div class="grid2"-
-div-
-h1-Titre qui perd son margin-top -/h1-

(finalement je remplace souvent les directives margin-top de p, ul, ol, etc. par un padding-top qui est plus "obéissant")

---

Print

Classe pour les éléments à ne pas imprimer :
.no-print {display: none}

Print plus complet : https://github.com/inseo/bpi-print/blob/master/print.css

---

form : ne devrait-il pas avoir le même margin-top que p, ol, ul... ?

---

textarea : est réglé à un endroit avec margin-top: .75em
Mais pas de margin-top pour les input.
Ce qui fait que dans un formulaire, le label au dessus de textarea se retrouve avec un espace supplémentaire par rapport au label au dessus d'un input.

---

En cherchant un menu knacss sur Google ("knacss menu") premier résultat :
http://www.knacss.com/demos/7.html

semble ne plus fonctionner. Il y a d'ailleurs plusieurs dossiers dans knacss.com/demos/

A propos des préfixes

J'amène ce sujet sur le tapis parce que je pense qu'il y a une incohérence sur l'état actuel des choses. J'ai cru voir passer dans le changelog de KNACSS v3.0 que les préfixes constructeurs ont été retiré, afin de laisser Autoprefixer faire son boulot.

C'est là un débat que j'ai déjà eu avec les mainteneurs du projet Jeet.js. A partir du moment où on retire les préfixes sous prétexte que ce n'est pas le rôle du framework de faire ça, mais bien à une bibliothèque externe, on rend le projet dépendant de ladite bibliothèque.

En l'occurrence, si on considère que KNACSS n'a pas a assigner les préfixes parce qu'Autoprefixer fait ça très bien, on fait d'Autoprefixer une dépendance de KNACSS.

En soi, ce n'est pas forcément gênant. En fait, ça dépend vraiment de la portée de KNACSS là encore : si vous considérez que ce n'est qu'un outil dans le workflow d'Alsacréations alors j'imagine que faire d'Autoprefixer une dépendance n'est pas gênant ; après tout vous contrôlez le workflow. Maintenant si KNACSS a pour vocation d'être un framework CSS pour tout le monde, c'est selon moi une mauvaise idée que de ne pas générer les préfixes. Tout le monde n'utilise pas Autoprefixer.

Maintenant que le problème est soulevé, quelles sont les alternatives ? Il y en a plusieurs :

• Laisser tel quel, sans préfixes. Tant pis pour ceux qui n'utilisent pas Autoprefixer.
• Conditionner l'output des préfixes par un booléen dans la configuration.
• Ajouter les préfixes là où il doit y en avoir.

Nous avons vu les problématiques engendrées par la première approche. L'idée de mettre en place un booléen de configuration semble viable mais ça alourdit encore la configuration de KNACSS déjà chargée.

Sachant qu'Autoprefixer se moque qu'il y ait des préfixes ou non je le rappelle. Dans le cas où il y en a déjà, il les enlèvera pour les remettre (ou pas s'ils ne sont pas nécessaires).

Autrement dit, préfixer KNACSS ne se ferait pas au détriment d'Autoprefixer ; les deux peuvent fonctionner très bien ensemble, sans faire de ce dernier une dépendance du premier.

Je terminerai aussi sur le fait que la code base de KNACSS n'est pas non plus monstrueuse, et son utilisation de propriétés nécessitant d'être préfixées l'est encore moins. Si on a besoin d'une dizaine de lignes en tout et pour tout, c'est un grand maximum. Je ne suis pas sur que ça vaille le coup de les faire sauter, sachant les soucis que ça peut engendrer chez les utilisateurs n'intégrant pas Autopréfixer dans leur workflow.

My 2 cents. :)

placeholder

Bonjour Raphael,

J'ai une interrogation, dans le la css "form"

Je pense qu'il faudrait ajouter cette ligne :
input::-moz-placeholder { opacity: 1; color: #777; }

Car sur les dernières versions de Firefox, un deuxième ":" (deux points) est ajouté dans la notation (https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-placeholder), de plus, une opacité est appliqué sur le texte.

Qu'en penses-tu ?

Super boulot !

grids - font-size et whitespace

Bonjour Raphael,

En utilisant "classic grids", je rencontre le bug suivant sur Safari 7 : en fonction de la largeur de la fenêtre du navigateur, deux colonnes d'une largeur de 50% sont une fois cote à cote une fois l'une au dessus de l'autre.

Le problème survient lorsque je change la taille de police du body par une valeur supérieur à 1.4em (le reste du framework étant inchangé).

Faut-il faire évoluer les valeurs de letter-spacing et word-spacing ?

Merci d'avance, Florian.

Variables de configuration

Actuellement, KNACSS propose un certain nombre de variables, notamment des variables de configuration de l'output, sous la forme de booléens.

$ie678: true;
$styling: true;
$gmaps: true;
$skip-links: true;
$hyphens    : true;
$helpers-width: true;
$helpers-spacing: true;

Quand on les voit toutes à la queue-leu-leu comme ça, on comprend très bien à quoi elles servent mais quand elles sont perdues dans le code c'est parfois pas évident de savoir si elles contiennent une valeur ou bien un booléen destiné à la configuration.

Aussi je proposé de les préfixer par enable- afin de les différencier des autres types de variables. De plus, leur nom aurait naturellement plus de sens.

$enable-ie678: true;
$enable-styling: true;
$enable-gmaps: true;
$enable-skip-links: true;
$enable-hyphens : true;
$enable-helpers-width: true;
$enable-helpers-spacing: true;

Opinions ? :)

Box-sizing et les pseudo-éléments

Actuellement :

* {
    box-sizing: border-box;
}

Le sélecteur universel n'intègre pas les pseudo-éléments. Je pense qu'il serait de bon ton de les rajouter à la règle :

*, :after, :before {
    box-sizing: border-box;
}

Nommage des variables

Il y a selon moi certaines incohérences dans le nommage des variables des versions LESS et Sass.

En effet, certaines variables utilisent des traits d'union :

$line-height: 1.5;
$h1-size: 3.2rem;
$h2-size: 2.8rem;
$h3-size: 2.4rem;
$h4-size: 2.0rem;
$h5-size: 1.8rem;
$h6-size: 1.6rem;
$tiny-value: 0.5em; 
$small-value: 1em;
$medium-value: 2em;
$large-value: 4em;
$extra-large-value: 6em;
$ultra-large-value: 10em;

Et certaines variables n'utilisent pas de séparateurs entre les mots:

$basefont   : 14px;
$fontstack1: Helvetica, Arial, sans-serif;
$fontstack2: Consolas, 'DejaVu Sans Mono', Courier, monospace;
$fontstack3: FreeSans, Arimo, "Droid Sans", Helvetica, Arial, sans-serif; 
$basecolor: #000;
$basebg: #fff;

On va même plus loin avec certains variables qui utilisent un séparateur entre certains mots, pas d'autres :

$basecolor-link: #333;
$basecolor-link-hover: #000;

Je propose donc :

// Config file : variables, mixins, ...


// booleans
$ie678              : true; // "true" to activate IE6/IE7/IE8 support
$styling            : true; // "true" to design basic elements like code, mark, blockquotes, etc.
$gmaps              : true; // if google maps is used
$skip-links         : true; // "true" to design skip links for accessibility concerns
$hyphens            : true; // activate automatic hyphens on small screens
$helpers-width      : true; // decide whether or not you need width helpers
$helpers-spacing    : true; // decide whether or not you need spacing helpers

// font sizes
$base-font-size     : 14px; // if "14px" then 1em = 14px
$line-height    : 1.5; // equiv line-height 1.5
$h1-size        : 3.2rem; // equiv "32px"
$h2-size        : 2.8rem; // equiv "28px"
$h3-size        : 2.4rem; // equiv "24px"
$h4-size        : 2.0rem; // equiv "20px"
$h5-size        : 1.8rem; // equiv "18px"
$h6-size        : 1.6rem; // equiv "16px"

// font stacks
$font-stack-common          : Helvetica, Arial, sans-serif; // common font
$font-stack-monospace           : Consolas, 'DejaVu Sans Mono', Courier, monospace; // monospace font
$font-stack-universal           : FreeSans, Arimo, "Droid Sans", Helvetica, Arial, sans-serif; // universal stack

// font colors
$base-color             : #000; // text color on body
$base-color-link            : #333; // primary links color;
$base-color-link-hover  : #000; // primary hovered/focused links color;

// backgrounds
$base-background                    : #fff; // body background color

// spacings
$tiny-value             : 0.5em; // tiny value for margins / paddings
$small-value            : 1em; // small value for margins / paddings
$medium-value           : 2em; // medium value for margins / paddings
$large-value            : 4em; // large value for margins / paddings
$extra-large-value      : 6em; // extra large value for margins / paddings
$ultra-large-value      : 10em; // ultra large value for margins / paddings

// breakpoints
$tiny-screen            : 320px; // tiny screens media query
$small-screen           : 480px; // small screens media query
$medium-screen          : 768px; // small screens media query
$large-screen           : 1024px; // large screens media query
$extra-large-screen     : 1280px; // extra large screens media query
$ultra-large-screen     : 1600px; // ultra large screens media query

// misc
$gutter     : 20px; // gutter value (%, px, em, rem) for grid layouts

Au delà du format des variables, j'ai pris la liberté d'en renommer certaines pour plus de compréhension. Notamment :

$basefont -> $base-font-size
$basebg -> $base-background
$fontstack1 -> $font-stack-common
$fontstack2 -> $font-stack-monospace
$fontstack3 -> $font-stack-universal

Fix font-size iOS version LESS

Il manque la règle commentée /* orientation iOS font-size fix */ dans la version LESS

Problème d'affichage de reCAPTCHA avec le module "tables" de KNACSS

Bonjour !

Quand on utilise le module "tables" proposé dans le téléchargement de KNACSS, celui-ci explose l'affichage de reCAPTCHA.

/* ----------------------------- */
/* ==tables                      */
/* ----------------------------- */

table,
.table {
  max-width : 100%;
  table-layout: fixed;
  border-collapse: collapse;
  vertical-align: top;
}

Pour les autres qui seraient confrontés au même problème (et pour suggérer un fix pour une prochaine version de KNACSS), je propose deux solutions.

Cette première solution à l'inconvénient de ne pas être reconnue par tous les navigateurs (sélecteur :not) : on va modifier la règle d'origine comme suit, pour lui dire d'ignorer la table générée par reCAPTCHA :

table:not(#recaptcha_table),
.table {
  max-width : 100%;
  table-layout: fixed;
  border-collapse: collapse;
  vertical-align: top;
}

Une autre solution, plus passe-partout, est de rétablir le table-layout par défaut, en ajoutant ce correctif juste en dessous de l'original (sans modifier ni retirer la règle d'origine) :

table#recaptcha_table
{
  table-layout:auto;
}

En espérant que cela servira à d'autres ! :-)

Très cordialement,

Signé: Bouchon du forum alsacreations

Ajout d'un booléen pour les fallbacks en pixels ?

Dans les version préprocesseurs, les valeurs en rem sont actuellement automatiquement dupliquées en pixels (compatibilité IE8 et Opera Mini) :

sass {
  @include rem(2);
}

Renvoie :

sass {
  font-size: 28px;
  font-size: 2rem;
}

Pour éviter de surcharger inutilement le code, il y a deux manières de voir les choses :
1- laisser tomber les rem pour Opera Mini et n'utiliser le fallback que pour IE si @ie678 = "true"
2- employer un nouveau booléen de type $px-fallback: true/false

Honnêtement, la première solution me plaît mieux ;)

Ne pas oublier de mettre à jour la version dans le bower.json

Salut Raphaël

Je vois que tu as mis une nouvelle version 2.9.1.

N'oublie pas de mettre à jour la version dans le fichier bower.json :)

Je l'ai remarqué grâce au message suivant :

bower knacss#*                mismatch Version declared in the json (2.9.0) is different than the resolved one (2.9.1)

qui apparaît quand je fais un bower install knacss

Bien à toi

Extends * { box-sizing } rule to :before/:after

Comme évoqué sur twitter (https://twitter.com/o_patry/status/316664748005527552).
Feature request pour appliquer le même box-sizing aux éléments générés via :before/:after qu'aux autres.

*, *:before, *:after {
    box-sizing: border-box;
}

Règle print hors de son fichier

Le fichier base contient :

@media print {
    .no-print {
        display: none;
    }
}

Cette règle ne devrait-elle pas être dans le fichier print ?