[spip-dev] neodist et nomenclature des CSS

Dev
1

hello

il faudrait qu'on se décide sur la nomenclature des CSS
et que l'on tranche pour toute pour ne pas perdre trop de cheveux dans l'histoire ....

actuellement on a (dans l'appel d'ordre du schéma daisy
http://daisy.tetue.net/img/daisy-nomenclature.png

le pack "tinytypo"
- reset.css
- clear.css
- font.css
- link.css
- typo.css
- media.css
- form.css
- grid.css

le pack "spip'
- layout.css le layout de base de spip
- spip.css: les balises générés par spip
- les css des plugins via insert_head_css

le pack habillage
- theme.css le thème de spip (nu)
- perso.css le fichier perso s'il est présent, le fichier n'est pas présent par défaut
- custom.css le sur-thème qui décore le thème nu
                               actuellement on a le thème "tonton

+ question 1:
plusieurs personnes ont envie d'avoir plusieurs de base (techno, littéraire, ...)
(quelle strategie en terme de dossier ? notamment pour les chemins et aussi les liaisons avec des fonts, images)

+ questions2 :
pour l'habillage, on laisse comme cela ou on simplifie ?

par exemple
avoir un theme.css (et puis themes adaptés)
et un seul fichier de personnalisation vide (quel nom ? perso ou custom ?)

merci de vos retours :slight_smile:

2

Bonjour,
dans la liste des css pour les thèmes spip ne manque t-il pas : habillage.css ?
cordialement

3

je ne crois pas ....
habillage.css vient de SPIP 2.1
la feuille n'est plus présente depuis SPIP 3.0

4

hello

il faudrait qu'on se décide sur la nomenclature des CSS
et que l'on tranche pour toute pour ne pas perdre trop de cheveux dans
l'histoire ....

actuellement on a (dans l'appel d'ordre du schéma daisy
http://daisy.tetue.net/img/daisy-nomenclature.png

le pack "tinytypo"
- reset.css
- clear.css
- font.css
- link.css
- typo.css
- media.css
- form.css
- grid.css

le pack "spip'
- layout.css le layout de base de spip
- spip.css: les balises générés par spip
- les css des plugins via insert_head_css

le pack habillage
- theme.css le thème de spip (nu)
- perso.css le fichier perso s'il est présent, le fichier n'est
pas présent par défaut
- custom.css le sur-thème qui décore le thème nu
                               actuellement on a le thème "tonton

Dans une logique de surcharge du plus général au plus particulier, il me semblerait plus logique de charger dans cet ordre là :

- theme.css
   theme de la dist "nue", présent par défaut
- custom.css
   déclinaison du thème, pas présent par défaut
- perso.css
   surcharges personnelles, pas présent par défaut

C'est aussi ce que propose Tetue avec daisy, si j'interprète bien le team.css comme équivalent du perso.css

+ question 1:
plusieurs personnes ont envie d'avoir plusieurs de base (techno,
littéraire, ...)
(quelle strategie en terme de dossier ? notamment pour les chemins et
aussi les liaisons avec des fonts, images)

Plusieurs thèmes en même temps ? je ne vois pas comment gérer ça simplement, sans un développement avec une config en back office.
A voir dans la prochaine version ?

Si on veut distribuer un thème avec des ressources (images, js, fonts), on peut simplement proposer un zip qui reproduit l'arborescence voulue.
Après, c'est à chacun de gérer son custom.css : on le supprime ou on le renomme, on en met un autre.

Et on rédige un petit texte d'explication simple lors de la release de la 3.1, qui explique comment installer un custom.css

+ questions2 :
pour l'habillage, on laisse comme cela ou on simplifie ?

par exemple
avoir un theme.css (et puis themes adaptés)
et un seul fichier de personnalisation vide (quel nom ? perso ou custom ?)

Si on distribue des habillages de dist prêts à l'emploi, ça devrait être des custom.css, pour laisser la place à un perso.css qui permet à l'utilisateur de surcharger l'habillage (cf point ci dessus sur l'ordre de chargement).

Donc, le theme.css est distribué avec la dist, mais par défaut il n'y a pas de custom.css ni de perso.css.

5

Hello,

perso.css et custom.css sont redondantes, il n’y a aucune logique ni intêret d’avoir les deux.Ça a toujours été perso.css pour personaliser la dist, il n’y a pas de raison d’introduire ce custom.css, encore plus en tant que “surthème du thème”, ce qui ajoute encore un niveau d’abstraction.
Rappel : la dist doit rester simple et pedagogique !

Revenons aux bases :
theme.css : la variante d’habillage
perso.css : la feuille qui permet de personaliser

Cédric Morin

6

D'accord avec ça.
Et ça supprime un nom de fichier anglicisé.
Donc si des thèmes sont distribués, dans des perso.css

7

Non justement perso.css est à l'usage du seul webmestre, dans le dossier squelettes. Il n'est jamais fourni pas un squelette ni un plugin...
Si on distribue des themes ils fournissent theme.css !

8

Non, les variantes sont dans theme.css. Simplement, tu places le fichier de la variante dans squelettes pour qu'il soit prioritaire sur celui de la dist.
->perso.css permet alors de personnaliser la variante.

Enfin, c'est comme ça que je l'ai compris...

Christian

9

Ben non. perso.css doit toujours être vide (ou ne pas exister du tout) et réservée uniquement à la personne qui installe le site.

S'il y a plusieurs thèmes livrables, ça serait en numérotant des fichiers, et à chacun de copier leur contenu ou de renommer le fichier.

theme.css (thème par défaut, et il y en a forcément un, choisi par nous)
theme-2.css
theme-3.css etc

Dans tous les cas, il y a bien un thème par défaut qui se voit en premier. Et qui doit donc être choisi, parmi les différentes cibles de SPIP, en fonction de celle qui est la moins geek, la moins à même de personnaliser toute seule.

10

Alors je reviens sur l'idée de base, qui est de proposer des surcharges de la dist, pas de distribuer des thèmes complets.

Il y a justement un aspect pédagogique à avoir le thème simple de base (dist = theme.css) et des surcharges, pour montrer comment personnaliser simplement la typo, le jeu de couleurs ou une mise en page alternative.

Donc je reviens sur l'idée de :
- theme.css (dist)
- custom.css (ou theme_alternatif.css ou autre nom, optionnel)
- perso.css

La dist utilise tinytypo et son découpage daisy, et c'est très bien, autant suivre la logique jusqu'au bout et proposer cette méthode à la fois logique, pratique et simple à utiliser.

11

Il y a le theme, et la feuille qui sert à le personnaliser :

Le theme.css de daisy est le theme.css de SPIP.
Le custom.css de daisy est le perso.css de SPIP.

Il n’y a aucune notion de sur-thème dans daisy…

Cédric

12

Bof, daisy n'est pas une méthode stricte, avec un nommage absolu et standardisé, c'est juste une approche *pragmatique*, avec une logique de découpage et de surcharge.

Je ne vois pas ce qui vous gêne dans le fait d'avoir la possibilité de surcharger le thème de base.
C'est pas un truc technico-technique de dév, c'est simple à utiliser, et ça aurait cet avantage pédagogique de proposer des variantes faciles à prendre en main.

13

perso.css doit toujours être vide (ou ne pas exister du tout) et réservée uniquement à la personne qui installe
le site.

Ainsi, c'est clair et simple.

14

Donc si des thèmes sont distribués, dans des perso.css

Ben non. perso.css doit toujours être vide (ou ne pas exister du tout) et réservée uniquement à la personne qui installe le site.

Oui.

perso.css = custom.css (c'est la même chose, en français et en anglais)

Par défaut, dans le cadre d'une distribution, cette feuille doit être vide ou ne pas exister, puisque, par définition, elle est sensée contenir les personnalisations du Gus, lequel, au moment de la distribution, n'est pas encore intervenu :wink:

S'il y a plusieurs thèmes livrables, ça serait en numérotant des fichiers, et à chacun de copier leur contenu ou de renommer le fichier.

theme.css (thème par défaut, et il y en a forcément un, choisi par nous)
theme-2.css
theme-3.css etc

Oui.

Mais dans une logique de distribution de thèmes, supposée extensible (ie. je dois pouvoir ajouter mon thème) ceux-ci doivent être rangés dans des sous-répertoires, car il peuvent convoquer des fichiers tiers (images, fontes, etc.). Donc :

/themes/
  /theme-1
    /theme.css
    /img
    /etc.
  /theme-2
    /theme.css
    /font
    /etc.

où les sousrep « theme-1 » et « theme-2 » sont librement nommables.

Dans tous les cas, il y a bien un thème par défaut qui se voit en premier. Et qui doit donc être choisi, parmi les différentes cibles de SPIP, en fonction de celle qui est la moins geek, la moins à même de personnaliser toute seule.

Oui.

-- tetue

15

Oui, il n'y a pas de notion de « sur-thème » dans Daisy, en tout cas pas telle qu'évoquée ici dernièrement, tu as raison.

Mais la nomenclature Daisy prévoit d'éventuelles variantes stylistiques sur un thème donné, lesquelles fonctionnent différemment (franchement plus rares, telles que des « skin » saisonnières surchargeant temporairement un thème ou des variantes de couleurs par rubriques), c'est donc une autre histoire.

Et oui, j'ai pensé à tout :slight_smile:

-- tetue