Refactor Css pour faciliter la customization

[seballot]

Problèmes rencontrés

• C'est un peu le bordel entre bootstrap, le css de base de yeswiki, et le css des themes
• Quand on veut faire un theme on est obligé d'annuler des styles définit par bootstrap ou par le code de base de yeswiki, ce qui complique le code et fait beaucoup appel au !important
• On ne peut pas personnaliser le thème par défault, à part quelques couleurs

Pistes de solution

Bootstrap

Reprendre le code de bootstrap 3 en le mettant à la sauce yeswiki : on prend juste ce dont on a besoin, on améliore/simplifie certains styles par défaut, et on remplace toutes les valeurs en dur par des variables css

On peut partir du code source de bootstrap en less, faire les modifs puis le compiler. Y'a aussi un portage de bootstrap3 en SCSS : https://github.com/twbs/bootstrap-sass/

Splitter le code de base

En ayant des fichiers séparés, on pourra ainsi lors de l'écriture d'un thème, choisir de charger ou non les styles du coeur

/* yeswiki.css */
@include "bootstrap/panels"
@include "bootstrap/buttons"
@include "bootstrap/modal"
....
@include "yeswiki/revisions"
@include "yeswiki/login"
...

1. Soit je charge tous les styles du coeur, et par dessus je fais mes modifs

/* mon-theme.css */
@include "yeswiki.css"

// mon code custom

2. Soit je décide d'être plus custom, et je charge moi même un a un a tous les styles du coeur dont j'ai besoin.

/* mon-theme.css */
@include "bootstrap/panels"
// genre je vire les boutons pour les redéfinir moi meme from scratch
// @include "bootstrap/buttons"
@include "bootstrap/modal"
....

SCSS

On pourrait aussi installer une chaîne de compilation pour utiliser du scss. Soit avec du node, soit avec une lib php comme : https://scssphp.github.io/scssphp/

A priori, avec les variables css et les include on peut s'en sortir avec du css (même si le scss est quand meme plus confortable pour coder). Il y a aussi la question du nombre de requetes générées par les include. A priori ce n'est plus gênant de multiplier le nombre de requetes maintenant, mais peut être à revérifier?

Quoi mettre dans le coeur et quoi dans le theme

C'est toujours un équilibre difficile. D'un côté on ne veut pas trop contraindre le style dans le code du coeur, mais d'un autre on ne veut pas que chaque theme doive tout re implémenter

Une bonne pratique est surement d'éviter les contraintes de styles dans le HTML, par exemple les col-xx, pull-right et autre text-center ne devraient pas etre utilisés, car c'est ensuite difficile à surcharger depuis le thème

L'utilisation de grid css pour les disposition par default dans le coeur pourrait etre une bonne idée, car on peut facilement tout rechambouler

[mrflos]

hello,
D'accord avec tout ce que tu proposes.
Pour l'histoire de scss ou css : je proposerai bien que dans le code du coeur de yeswiki et les extensions du coeur ce soit du scss, mais qu'au build du source du yeswiki, il fasse la compilation/concatenation/minification dans styles/yeswiki-core.min.css.
Le créateur d'un theme sera libre de faire son theme en scss (en important styles/yeswiki-core.scss, ou chaque scss dans le détail) ou css (en important styles/yeswiki-core.min.css). L'avantage étant pour moi d'avoir le code lisible en dev, mais minimisé pour la prod.
Cela voudra dire aussi que le mainteneur d'un theme doit suivre les évolutions des scss du coeur, a voir si c'est pas trop d'interdépendance..

J'aimerais bien en profiter aussi pour améliorer le asset manager, pour aussi gérer dans priorités dans l'ordre des css et js, et aussi permettre la concatenation/minification.

Enfin sans urgence et en mode cerise sur le gateau : les thèmes twig sont facilement customisables, sauf les parties dynamiques en vuejs, qui chargent des composants depuis un dossier particulier. Ca serait bien de voir si l'on peut faire un helper en js qui vérifierait si l'on veut charger import Panel from './components/Panel.js' s'il n'y a pas de components custom import Panel from './custom/javascripts/components/Panel.js'