alsacreations / knacss Goto Github PK
View Code? Open in Web Editor NEWfeuille de styles CSS sur-vitaminée
Home Page: http://www.knacss.com
License: Do What The F*ck You Want To Public License
feuille de styles CSS sur-vitaminée
Home Page: http://www.knacss.com
License: Do What The F*ck You Want To Public License
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;
}
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 :
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. :)
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
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
supprimer textarea, figure, label du "soft reset" car déjà ciblés précédemment
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 ;)
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 !
Hello,
dans la version Less des fichiers, les largeurs de blocs s'arrêtent à 960PX (sauf erreur) ?
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.
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 ? :)
Corriger le commentaire :
s,m,l,n,0 = small(10px),medium(20px),large(30px), zero or none(0)
What about:
img {
filter: grayscale(100%);
}
(Plus vendor prefixes.)
* {
background: transparent !important;
box-shadow: none !important;
text-shadow: none !important;
}
a[href^="javascript:"]:after,
a[href^="#"]:after {
content: "";
}
voilà voilà voilà :)
hgroup
a été retiré des specifications, aussi la règle le concernant dans le fichier base
doit être modifiée.
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 :
background-color: #fff
et color: #000
puisque cela correspond aux valeurs par défaut (ou alors j'ai raté quelque chose ?)font
Des avis ? :)
Passer en WTFPL
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
Il manque la règle commentée /* orientation iOS font-size fix */ dans la version LESS
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 ?
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.
!important
grâce à un meilleur usage des media queriesPour pouvoir enfin faire du Web : http://blog.goetter.fr/articles/ie8-must-die/
Les variables commencent à être utilisables en CSS :
EDIT : en fait pas tant que ça... à méditer donc
Quelques pistes :
!important
grâce à un meilleur usage des media queriesLa 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 :
... ainsi, plus la peine d'écraser sauvagement à coup de !important
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?
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
Le fichier base
contient :
@media print {
.no-print {
display: none;
}
}
Cette règle ne devrait-elle pas être dans le fichier print
?
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 ?
Prévoir une sécurité margin-left: 0
.grid > * > * {
margin-left: 0;
}
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.
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 :
Inconvénients :
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 ;))
Note pour moi-même : idée LESS pour KNACSS : https://twitter.com/PhilippeVay/status/428475047297040384
Bonjour !
j'ai recontré un petit souci avec les infobulles (InfoWindow) de ggmap.
solutions trouvées
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).
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) :
En détail : http://knacss.com/demos/tutoriel.html#grids
Avantages des grids (float):
Inconvénients des grid :
Avantages des autogrids (inline-block):
Inconvénients des autogrids :
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 ?
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
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.
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!).
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")
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/
il reste des em inutiles.
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;
}
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)
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).
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 !
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()
.
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.
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;
}
}
Supprimer quelques !important inutiles (poke @IamnotCyril)
Supprimer le reset sur b et i (poke @geoffrey_crofte)
Juste un post-it si jamais j'oublie :)
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;
}
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
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 }
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;
}
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;
}
}
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);}
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
)
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;
}
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;
}
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 :
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
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 :)
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);
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.