5139 sujets

Le Bar du forum

Demande d'avis workflow SASS

Bonjour,

J'ai créer un petit framework de développement SASS, et j'aimerais avoir vos retour sur celui-ci.

Ce framework tire parti d'un nouvelle fonctionnalité introduite dans SASS 3.2, les placeholder.

loogr.css

Le principe est assez simple une mixin (loogr) génère un collection d'objet.

ensuite vous stylez comme ceci .


.selector {
    @extend %myobject-1--namespace;
    @extend %myobject-2--namespace2;
}


- Où namespace correspond à la feuille de style.
- Où namespace2 correspond à la media queries.

Ce qui génère : 


.selector {
     le contenu de myobject-1
}

@media screen and (max-width : 300px) {
     .selector {
        le contenu de myobject-2
    }
}


Ce framework vous permet d'utiliser autant de grille que vous voulez sans pour autant les inclure dans le CSS final. Seul ce que vous utiliserez sera rajouter.

N'hésitez pas à me faire remonter vos critiques, merci !

Edit : ajout d'un petit aperçu du fonctionnement.
Modifié par rs459 (23 Dec 2012 - 21:12)
Administrateur
Bonjour,

pas sûr d'avoir compris ... est-ce que ça permet de déclarer les instructions d'un @media à côté des instructions que ça écrase tout en les écrivant, dans la CSS finale, dans un minimum de blocs @media ? Genre ce qu'il y a sur le site d'elysee.fr (mes tweets : https://twitter.com/PhilippeVay/status/281337476025577472 et '(...) qu'un préproc CSS regroupe les règles "responsive" dans le minimum de blocs at-media')
Modifié par Felipe (26 Dec 2012 - 12:40)
Bonjour,

Dans les fait c'est un peu ça, tous les objets déclarés dans la mixin loogr le sont via le mécanisme des placeholders.

Chaque objet de cette mixin est incorporé dans chaque règle ou "loogr(namespace)" est utilisé, avec une possibilité de l'utiliser via "@extend %objet--namespace", et ceci tout en étant en dehors de la MQ.

En cas de non utilisation, l'objet n'apparaitra pas dans le résultat final. (principe du placeholder dans SASS 3.2) , d'ou l'important nombre de grille.


//SCSS
.selector {
    @extend %display-block--all;
    @extend %display-inline--mynamespace1;
    @extend %display-static--mynamespace2;
}

.otherSelector {
    @extend %float-left--all;
    @extend %float-right--mynamespace1;
    @extend %float-none--mynamespace2;
}

//mynamespace1
@media () { ... }

//mynamespace2
@media () { ... }


va donner comme résultat :


.selector {
    display : block;
}

.otherSelector {
    float : left;
}

//mynamespace1
@media () {
    .selector { 
        display : inline;
    }

    .otherSelector {
        float : right;
    }
}

//mynamespace2
@media () { 
    .selector {
        display : static;
    }

    .otherSelector {
        float : none;
    }
}


Tout est généré dans la même règle.

Et pour les choses plus complexe, tu as ensuite 2 choix, soit tu utilises la technique respond-to() , soit tu crée un objet dans la mixin loogr :



//loogr.inc.scss
    ...
//Own Object
	 	%bordered--#{$namespace} {
	 		@if $namespace == all {
	 			border : 2px solid black;
	 		}
	 		@elseif $namespace == under480 {
	 			border : 4px solid darkgreen;
	 		}
	 	}



.selector {
    @extend %bordered--all;
    @extend %bordered--under480;
}

// namespace under480;
@media ( max-width : 480px ) { ... }




.selector { 
    border : 2px solid black;
}

@media ( max-width : 480px ) {
    .selector {
        border : 4px solid darkgreen;
    }
}


Donc tout ce qui sera fait de cette manière, apparaitra dans une seule et même MQ, au contraire de respond-to().

EDIT : petite omission. Et petit ajout.
Modifié par rs459 (26 Dec 2012 - 17:56)
Pour revenir sur le message précèdent.


//loogr.inc.scss
    ...
//Own Object
	 	%bordered--#{$namespace} {
	 		@if $namespace == all {
	 			border : 2px solid black;
	 		}
	 		@elseif $namespace == under480 {
	 			border : 4px solid darkgreen;
	 		}
	 	}


Ce code pourrait aussi être refactorisé comme ça :


%bordered-style-one--#{$namespace} {
	 border : 2px solid black;
}
%bordered-style-two--#{$namespace} {
	 border : 4px solid darkgreen;
}


Ce qui rend l'objet indépendant des namespace.
Modifié par rs459 (26 Dec 2012 - 19:30)
Un article qui vient d'apparaître dans mes flux RSS du matin : http://sasscast.tumblr.com/post/38673939456/sass-and-media-queries

Pour les anglophobes et les gens pressés : réunir les MQs à la fin du CSS avec Sass c'est possible, il y a plusieurs modules pour le faire, mais au final, que ça soit fait ou pas n'a quasiment pas d'impact sur le performances (comparatif Avec/ Sans MQ réunies pour des feuilles de styles de 40 et 2 000 MQs).

Donc c'est avant tout une histoire de goût et de syntaxe, ou du moins il n'y a pas d'argument qui permettent de dire que réunir les MQ est mieux que de ne pas le faire.
Merci pour ton retour.

Ce qui me chagrine le plus avec l'approches des MQ séparées, c'est la visibilité qu'on a sur la cascade dans le rendu CSS "pre-prod".D'un autre coté c'est très intéressant car cela permet de bien séparer son code de façon très modulaire.

Il faut que je murisse un peu mon approche, le nombre de selecteurs qui résultent sont trop nombreux (BUG IE's qui supportent un nombre restreint de selecteur).

J'ai eu cette l'idée de cette approche quand SASS 3.2 a pointé son nez, utiliser un placeholder crée en dehors de la @media pour lequel il est destiné, déclenche un avertissement dans SASS 3.2 et sera une erreur dans > 3.3 .

En revanche pour prototyper, avoir à sa disposition un très grand nombre de grille, j'ai trouvé le concept intéressant. Les approches qui limitent le nombre des colones pour les petits viewport, me laisse perplexe dans le sens ou c'est justement quand le viewport est le plus étroit que la fine granularité est la plus intéressante.

J'ai crée un exemple pour les grilles, dans le projet et sous forme de GIST.
Sujet clos
Aller à