Discussion du vendredi : les frameworks css

(reprise du message précédent)

Une autre ressource :
http://css.developpez.com/tutoriels/framework-css/

L'article date de plus d'un an.

je viens de découvrir celui-ci : http://code.google.com/p/dtcss/
J'aime bien :
- l'utilisation de variables réutilisables
- la structure du code
exemple :

#define HEADER_COLOR red
h1, h2, h3 {
        color: HEADER_COLOR;
        a:link {
                color: blue;
        }
        a:visited {
                color: darker(blue);
        }
}

Ca génère du code css standard et ça laisse libre au niveau du positionnement (pas de "contrainte" de grille)

L'info vient d'ici : http://www.smashingmagazine.com/2009/06/25/35-css-lifesavers-for-efficient-web-design/
Modifié par seblavenant (26 Jun 2009 - 22:41)

Hé hé je me demandais pourquoi j'avais une hausse dans mes stats
Blueprint et OOCSS (de Nicole Sullivan) ont aujourd'hui mes faveurs, en pratique et en théorie.

Une utilisation optimale des frameworks se fait quand l'intégrateur et le webdesigneur parlent la même langue. Sur un projet en cours, je me suis arrangé pour que le webdesigneur utilise la même grille que Blueprint.
Problème de sémantique ? Ça me fait à moitié sourire de n'avoir que cette critique en bouche Si c'est le seul obstacle vers un projet parfait c'est plus que tolérable. Par contre si ça pose vraiment problème, Blueprint est accompagné d'un générateur qui permet de palier à ce problème.

Les frameworks c'est bien pour :
* prototyper (ben ouais, la sémantique on s'en fout on veut du résultat vite et propre)
* faire progresser une équipe (ben ouais, lire le code des autres c'est bon)
* structurer sa présentation
* utiliser des grilles de manière performante

C'est moins bien pour :
* les modifier : faut être suffisamment barbu en CSS pour les utiliser et les modeler à son envie
* les projets qui n'ont pas de largeurs normalisées (du coup la grille, dur dur)

Après les frameworks c'est modulaire : y'a pas de nécessité de tout employer.

Il y a ensuite une autre approche type HAML qui permet de générer du CSS de manière semi-dynamique et apporte une approche objet/héritage qui manque beaucoup aujourd'hui.

Bonjour,

J'ai été chargé dans mon entreprise (vente au détail 100 magasins), de réaliser un espace web privé de consultation de points, modification de coordonnées privées...pour les clients qui ont la carte du magasin.
Sachant que cet espace allait être inséré dans notre site web public (iframe), j'ai cherché un framework css et je suis tombé sur YAMLhttp://www.yaml.de/en/. Je n'ai pas été déçu, moi qui ne suis vraiment pas un pro des css, j'ai pu me concentrer sur mon code php "métier" et aboutir à une première version en un mois, qui avait de la gueule.
Le framework gère pour vous les anomalies de IE, les problèmes de marge, la structure des répertoires est bien pensée, les conventions de nommage des classes est intelligente.
Mon employeur est satisfait, alors moi aussi !!
Le site passe en ligne dans une semaine, nous souhaitons que nos internautes le soient aussi.

Bonjour Je viens de prendre conscience des possibilités offertes par ce types de solution. Je n'y vois perso que du plus. J'ai à titre de test utilisé 960.gs rapidement, juste pour voir, c'est vrai que la mise en oeuvre est très simple. Et puisque il ne s'agit que de layout, je ne vois pas trop ou ça bloque. Niveau sémantique que ne pourriez-vous par faire via ce type d'outil ?

La question que je me pose donc naturellement maintenant est :
"Si je devais en adopter un, lequel ?"

Comment les comparer, quelles sont les avantages des uns et des autres ?

Merci en tout cas de m'avoir ouvert les yeux la dessus.

ernstein a écrit :
Niveau sémantique que ne pourriez-vous par faire via ce type d'outil ?

L'utilisation de tel ou tel framework CSS n'a à priori aucune conséquence sur la sémantique HTML.

Oui je le vois bien comme ça, ce n'est donc pas à mettre aux comptes des point négatifs concernant l'emploi ou non de ce type d'outil.

Après avoir mis en oeuvre 960, (je vais essayer blueprint aujourd'hui), je penses à mon sens que le seul bémol et le fait de baliser le code en y intégrant de manière strict un comportement de rendu. le simple fait de définir

<div id="mon_div" class="grid_8"></div>

fige de manière ferme le comportement de rendu de cette portion de code si le framework est chargé. Et pour tout dire, c'est ce qui m'embête puisque je travail le plus possible avec du code réutilisable.. cela va me contraindre, si d'aventure je souhaite l'utiliser, à sur baliser afin de publier mon code DANS une structure de ce type pour ne pas figer quoi que ce soit....



Je vais donc y réfléchir à deux fois. Quant au simple fait de créer un design basé sur une grille, bien évidement ça reste une excellente démarche.

Oui j'ai testé bluePrint pour pas mourir con et voir si je pouvais gagner du temps et je me suis vraiment trouvé bloqué sur certain truc et j'avais vraiment l'impression de perdre du temps alors j'ai rapidement laissé tombé, un peu plus tard j'ai réessayé pour voir si c'était pas moi, et non toujours pareil donc definitivement j'aime pas les framework Css....

Bonjour,

Boks est différent des autres frameworks car il propose une interface visuelle et pour ma part je n'en connais pas d'autres ou alors aucun m'ayant laissé un souvenir favorable. Ainsi je pense que lorsque l'on conçoit une maquette (avant l'intégration) avec un design qui s'appuie sur une grille (composition, typographie) il peut être bon de continuer la suite des étapes avec ce genre d'outil. De plus, le souci de standardisation (choix des éléments, comportements, nommage...) me semble être un critère de plus en plus important dans nos métiers.

Utiliser Boks ne veut pas dire "ne plus coder à la main" car il ne permet pas de s'avancer dans les détails d'un design, il est ici question de la structure de base qui parfois peut sembler laborieuse à mettre en place mais que Boks rend plus agréable de part son "assistance" graphique. Ensuite il faudra reprendre la main pour aller plus loin.

ernstein a écrit :
Bonjour faramazpat, sur quoi as tu bloqué en particulier ?

j'ai bloqué sur le positionnement qui n'est pas si simple que ça quand on te donne une maquette avec un design qui ne respecte pas de grille, et sur le faite que je devait rajouter des div dans tous les sens au lieu d'utiliser mes elements existants ( UL, etc.. ), le fait aussi que tous soit flottant et parte en couille quand t'as un truc qui dépasse à peine.

j'utilise généralement le reset dans mes css, les plus possibles les positionnements au lieu du flottant et j'essaye d'utilisé les balises de la page au lieu d'imbriquer les div, voila en gros ma philosophie du css.

Et comme tout framework il y a un temps d'adaptation à prendre en compte et quand t'es pas convaincu du résultat t'es pas trop motivé. peut être que si je voyais quelqu'un l'utiliser dans mon entourage et voir les avantages, je changerais peut être d'avis.

Bonjour,
J'utilise moi aussi 960.gs
Je pourrais très bien en utiliser un autre. Mais celui-ci suffit à ma société.
Un point important. L'utilisation d'un framework css doit être prévu dès la base du projet. C'est-à-dire lors de la création de la charte graphique.

Mais je voudrais surtout expliquer pourquoi utiliser un framework css.
Tout simplement pour plus de clarification dans les class utilisées. Cela permet de franchir un pas vers le css objet.
Il est beaucoup plus facile de plonger dans la css d'un collègue.
Cela permet d'avoir des conventions. Mais ne les imposent pas pour autant.

Pour les infographistes :
Cela parait limitatif pour les designer de devoir forcément se limiter à un colonnage. En réalité ils devraient depuis longtemps faire avec.
Dans le monde du print le même système est utilisé.
Pourquoi est-ce que le print utilise un système de colonage ? Parce qu'un graphique basé là dessus est plus dynamique, plus lisible, plus mieux tout simplement...
L'infographie sur le web est jeune mais ne devrait pas oublier toute l'expérience accumulé par les maître du print et du design.

Je met au défi quiconque de me montrer un site qui ne respecte pas un système de colonage et qui est pour autant dynamique pour le visiteur et facile à lire.


Donc du coup si on utilise un système de colonage pourquoi tout réinventer ? Autant utiliser un système qui permet de le mettre en place facilement et rapidement. Désormais je gagne bien 1 journée entière sur l'intégration d'un site qui m'en aurait demandé 3.

En fait j'abonde dans ton sens masseuro.

Il est évident que la mise en place de ce type de solution repose sur le fait d'avoir conçu un design en conformité avec une grille.

Donc pour résumé deux étapes/
1) création d'un design basé sur l'emploi d'une grille. C'est efficace, ça répond à pleins de questions, ça structure le projet oblige à respecter quelques règles (de plus ).

2) utilisation ou non d'un framework pour passer de ce design à la réalisation.
Ben du coup pourquoi sans privé puisque qu'il faut l'avouer c'est redoublement efficace.

Après avoir passer un peut de temps avec 960 et blueprint, j'ai finalement opté pour le second qui intègre des classes très pratiques quand il s'agit d'ajouter des colonnes avant ou après des block.

Sinon pour rebondir sur une phrase de faramazpat, rien ne t'oblige à re baliser un <ul> est un block au même titre qu'un <div> Donc rien ne t'empêche d'écrire <ul class="span-6>

++

Bonjour kamarades !

Tout d'abord merci à Alsacréation de lancer ce sujet fort intéressant et bravo pour la qualité générale du site !

Pour ce qui est des frameworks CSS je me pose comme vous énormément de questions sur leurs utilités et il y'a une chose importante qui n'a pas été abordé il me semble : l'évolutivité !
En effet, à l'aube de l'implémentation de HTML5 / CSS3 avec la sortie de Safari4, Opéra10 et aujourd'hui normalement FF3.5, il me semble que notre façon de coder va changé.

Je m'explique. Tout bon intégrateur veille à la sémantique de son code et à l'utilisation appropriée de ses balises. HTML4.01 et XHTML1.0 proposent déjà un grand nombre de balises (j'ai plus le nombre en tête) et HTML5 va en rajouter de nouvelles pour améliorer la sémantique (<header>, <footer>, <article>, etc.). Toutes ces nouvelles balises couplées avec CSS3 et notamment les nouveaux sélecteurs vont nous permettre de plus en plus de nous passé de ".class". Pour ma part je code toujours de manière à avoir un HTML le plus propre et light possible, c'est pourquoi si je peux me passer de ".class" je m'en passe.
Je suis en train de réaliser un projet en HTML5/CSS3 qui me permet d'avoir une intégration sans aucune ".class" et un minimum d'"ID" pour les interactions avec Javascript uniquement.

Tout ça pour dire que la manière de coder avec un framework peut être contraire à une certaine méthode de travail qui privilégie l'évolutivité des technologies à la logique de productivité.

Je me pose alors cette question de savoir si l'utilisation d'un framework est lié à la politique de rendement qui régit notre monde et notre porte-feuille, et met de côté la démarche qualité qui veut que chaque projet est unique et donc différent.
Modifié par meudah (30 Jun 2009 - 15:32)

meudah, supprimer les classes de ton code HTML est sans doute un bon moyen de faire un code plus léger et lisible. Par contre, d'expérience ce n'est pas vraiment un gain de productivité, au contraire. Un jeu de classes bien pensé, y compris des classes décrivant l'apparence d'un élément, permet à un développeur de réutiliser des styles existants pour un nouvel écran fonctionnel sans faire appel à nouveau à l'intégrateur web, et sans qu'il soit nécessaire de dupliquer des styles CSS ou de multiplier les sélecteurs.

Voir à ce sujet l'approche object oriented CSS (Nicole Sullivan) ou plus globalement le concept de styles modulaires reposant sur les classes.

À mon sens, ceci est une bêtise, ou du moins un excès:

#content > :first-child + * + * {
  /* Styles pour le troisième enfant du bloc de contenu,
     qui s'avère être un paragraphe avec le nom de l'auteur
     d'un article... */
}

Si la moindre modification du HTML demande de revoir le code CSS car les sélecteurs ne correspondent plus aux bons éléments, alors on a un problème de méthode. Les sélecteurs CSS avancés c'est bien, mais c'est casse-gueule. Je me rend compte en travaillant sur un projet sans support de IE6 (donc possibilité d'utiliser tous les sélecteurs CSS 2.1) que beaucoup de choses sont possibles mais pas souhaitables, car à être trop malin avec ses sélecteurs on aboutit à un code impossible à maintenir.

Oui je suis d'accord avec toi, et je comprends le concept de "styles modulaires" qui s'inscrit dans la logique des frameworks CSS. C'est effectivement une autre façon de faire. Faire appel aux sélecteurs "+" et ">" est effectivement dangereux car rigide au niveau du code HTML.

Pour ma part si j'ai besoin d'identifier mes objets autrement qu'avec la balise elle-même je le fais avec une ".class" et utilise les sélecteurs pour skiné les enfants de cet objet. Disons simplement que je crée un skin par défaut des balises HTML et que si j'ai besoin de les différencier je crée des ".class". De cette manière j'ai une librairie d'objets skiné que je peux réutiliser et non une librairie de ".class" qui me permettent de créer des objets.

Je n'ai aucune prétention sur ma façon de faire, c'est peut être la mauvaise méthode et si je suis là c'est justement pour en discuter

meudah a écrit :
De cette manière j'ai une librairie d'objets skiné que je peux réutiliser et non une librairie de ".class" qui me permettent de créer des objets.

C'est la question du «jusqu'à quel niveau faut-il être modulaire?». Et la réponse n'est pas évidente.

Après avoir lu pas mal d'articles sur les grilles, et créé des mises en pages full CSS où les bugs d'IE m'empoisonnaient la vie, j'ai eu à intégrer 2 sites dont le design pouvait s'adapter sur une grille. Retours d'expérience :

* Le graphiste n'avait pas pensé "grille", j'ai du sortir la calculette et pousser quelques pixels pour que ça tienne. Mais dans l'ensemble, les contraintes de largeur d'écran font converger graphisme et grille.
* Si vraiment ça ne tient pas, l'outil Blueprint Grid Generator adapte les largeurs des classes Blueprint aux dimensions du projet. Utile quand le design nécessite 16 colonnes au lieu de 24, ou quand elles doivent être plus larges que par défaut.
* La feuille de style corrigeant les bugs d'IE est une bénédiction. Positionnement des legend, correction du peekaboo, clearfix, on en oublierait presque qu'IE6 est un cancre.
* Comme le dit l'Oncle Tom, on obtient un prototype ou un squelette très rapidement.
* Ça permet d'aligner du texte dans une colonne très simplement (par exemple entre le header et le footer).
* Les développeurs peuvent très facilement ajuster un template HTML.
* C'est totalement compatible avec des styles modulaires (je l'ai fait pour les coins arrondis).
* Bien penser à surcharger la CSS du framework plutôt que de la réécrire, pour pouvoir suivre les évolutions du framework sans tout reprendre.

Compass reprend les fonctionnalités de Blueprint grid generator mais va beaucoup plus loin : il permet d'utiliser blueprint et d'autres frameworks, permet de générer les CSS en utilisant des variables, et de compresser les fichiers à uploader.

Edit du 29-07-2009
BlueCalc propose les mêmes fonctionnalités que Blueprint grid generator, avec une manière de procéder différente. On indique les contraintes à respecter (largeur mini/maxi de colonne et de marge, largeur du design, et il propose toutes les grilles possibles. Peut se révéler plus pratique car le résultat est plus visuel.
Modifié par Goulven (29 Jul 2009 - 09:41)