Discussion sur la liste spip-user

Question :

<blockquote class="spip">

Dans la perspective d’utilisation d’un framwork css avec spip et dans le but de styliser par exemple le formulaire de login public, se pose la question des classes CSS natives de spip qui sont différentes de celles du framwork soit « boutons » pour spip et « btn » pour le framwork...

Selon-vous, pour réaliser une intégration du framwork est-t-il préférable d’ajouter des classes CSS au framwork (rupture avec distribution) ou d’en ajouter à SPIP (rupture avec la distribution) ? Concernant le répertoire /prive/formulaires, est-t-il possible de surcharger avec des squelettes maison pour éviter la disparition de ceux-ci en cas de MAJ SPIP ?

</blockquote>

Réponse 1 (de Tcharlss) :

<blockquote class="spip">

La bonne approche à mon sens, c’est celle optée par le plugin Bootstrap pour SPIP : tu intègres le framework tel quel, et tu ajoutes ou surcharge ce qu’il faut pour prendre en charge le markup de SPIP.
Par exemple ces adaptations feront en sorte que les .boutons de SPIP s’affichent comme les .btn du framework, idem pour les formulaires etc.

Dans le plugin bootstrap, ça se passe dans le dossier « bootstrap2spip » : http://zone.spip.org/trac/spip-zone/browser/_plugins_/bootstrap/trunk
Voir le readme également : http://zone.spip.org/trac/spip-zone/browser/_plugins_/bootstrap/trunk/readme.txt

Pour faire ça convenablement, idéalement il faut utiliser la version less ou scss du framework, afin de pouvoir effectuer des surcharges quand c’est nécessaire.
Concrètement, ça va chercher les modules less en priorité dans /bootstrap2spip, puis ensuite dans /bootstrap.
Exemple avec les boutons : http://zone.spip.org/trac/spip-zone/browser/_plugins_/bootstrap/trunk/bootstrap2spip/css/buttons.less
Au début du fichier, le fichier « vanilla » de boostrap est importé, puis après quelques classes propres à SPIP sont ajoutées.
Propre et efficace !

</blockquote>

Réponse 2 (de Mist Graphx)

<blockquote class="spip">

Si un framework utilise un markup spécifique pour les formulaires, les boutons,… ça oblige a créer un squelette adapté utilisant le même markup (d’ou spipr-dist ou zundation).

Bootstrap utilise un markup et des classes, pour définir les composants, qui impose une structure du markup spécifique.

Fundation utilise et impose moins de classes, mais se base sur la structure sémantique/hierarchie des tags html pour styliser -> ce qui peut aussi être problématique.

Reste a se poser la question quand on veut utiliser un framework :
« Qu’est-ce que je vais utiliser dans le framework ? »

http://zone.spip.org/trac/spip-zone/browser/_plugins_/bootstrap/trunk/bootstrap/css/bootstrap.less
ici on embarque la totale : les carousels, modals, popover, … sont ils utilisés ?
du coup je ne sais pas si on peut dire que c’est « propre et efficace » ^^

On prend la totalité des composants et on coche :

- si on utilise que deux ou trois composants sur la vingtaine de proposés : autant partir sur une « base.css » comme tinyTypo et copier les classes css que l’on souhaite ou trouver un équivalent sur le web (pour les boutons et les formulaires il existe de nombreux exemples).

ceci permettra de faire un theme léger et comportant peut de surcharges et redondances ou classes inutilisées.
ceci se rapprocherait plus de la technique du squelette-dist, ou du projet publié par Rastapopoulos : Integrall.

le drame des preprocesseur -> il faut surveiller les classes css générées !! on peut se retrouver a générer des centaine de lignes inutiles : personnellement je commence toujours sur sassmeister ou codepen mes composants pour voir immédiatement les css générées et optimiser au mieux le nombre de lignes produites, surtout quand on utilise les @extend.

En dernier lieu je rajouterais que souvent je lis :
« je ne suis pas bon en css, donc je vais utiliser un framework pour me faciliter la tache »

ben non, je ne pense pas que ce soit un bon raisonnement c’est comme dire : « je ne suis pas bon en php, je vais utiliser symfony CMF ou jelix, modix » : bon courage à toi.

Une bonne piste pour réfléchir a des *composants légers et personnalisables* suivant le theme du site :

http://empties.bourbon.io/

cette méthode pars du principe qu’un composant est forcément séparé en deux parties minimum lors de l’écriture :
-  layout
-  theme

dans le cas des empties.refills seul le layout/markup/js est proposé, le thème est laissé à la charge du designer - d’ou le fait que ce soit moche ^^.

on peut toute fois partir d’un theme déjà en regardant :
http://refills.bourbon.io/

désolé si ma réponse peut paraitre trollesque, mais je travaille depuis un plus d’un an sur une bibliothèque de composants que je partage sur mes projets et j’ai donc essayé tout les frameworks cités pendant de long mois (ainsi que d’autres comme suitcss, inuitcss, …) avant de choisir de prendre le meilleur de chacun d’eux ou juste ce qui m’intéresse.

Un framework c’est une boite a outil, un mécanicien n’y mettra pas les mêmes outils qu’un menuisier ou un plaquiste. C’est pareil pour un site, un site éditorial n’utilisera pas les mêmes composants qu’un site e-commerce, un site vitrine, un portfolio d’artiste : « Don’t use frameworks, make your own » me parait être une bonne philosophie…

</blockquote>