J'ai l'impression que cette fonctionnalité amène une très grande complexité dans la maintenance du site, car le CSS est directement lié à l'HTML et au JavaScript. Ainsi dès que l'on veut améliorer / modifier une partie de l'interface, il y a de fortes chances que les CSS tiers soient aussi impactées.
Pour cette fonctionnalité, je trouve que l'on est dans la même situation que le projet GNOME au sujet des options : plus on en ajoute, plus la maintenance du code est difficile (le nombre d'options augmente de manière exponentielle le nombre de tests à faire).
Tout comme GNOME, l'équipe de développement est très petite et bénévole, ce qui permet de justifier de ne pas ajouter trop d'options / fonctionnalités.
Je suis donc pour prendre le même genre de décision: réduire le plus possible le nombre de fonctionnalités pour augmenter la qualité du code restant.
Je sais que c'est assez rude pour nos utilisateurs, mais il faut être réaliste: depuis 4 ans (depuis que j'ai développé la nouvelle interface pour l'espace de rédaction), toutes les CSS alternatives sont cassées dans l'espace de rédaction (j'avais touché à l'HTML et au JavaScript).
Ça fait donc 4 ans que les CSS sont cassées pour la fonctionnalité majeur de LinuxFr: l'espace de rédaction collaboratif.
Le deuxième aspect important pour LinuxFr est la présentation et la lecture des articles. Un nouveau design plus moderne avait été proposé par mjourdan et pour l'implémenter, nous allons devoir forcément toucher au CSS, à l'HTML et au JavaScript. Ainsi, pour pouvoir améliorer ce second point majeur du site, nous serons encore une fois forcé de casser toutes les CSS alternatives.
En conclusion, je suis pour supprimer la fonctionnalité assez rapidement pour pouvoir plus facilement améliorer le CSS principal du site, ce qui aura beaucoup plus d'impact positifs pour les utilisateurs.
Je propose de faire cette suppression en même temps que le passage à Rails 7, ça simplifiera justement le nombre de tests à faire pour Rails 7 / Ruby 3.
# Laisser tomber pour la maintenabilité
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi CSS contribuées, utilisation et mise à jour. Évalué à 2 (+0/-0).
Hello,
J'ai l'impression que cette fonctionnalité amène une très grande complexité dans la maintenance du site, car le CSS est directement lié à l'HTML et au JavaScript. Ainsi dès que l'on veut améliorer / modifier une partie de l'interface, il y a de fortes chances que les CSS tiers soient aussi impactées.
Pour cette fonctionnalité, je trouve que l'on est dans la même situation que le projet GNOME au sujet des options : plus on en ajoute, plus la maintenance du code est difficile (le nombre d'options augmente de manière exponentielle le nombre de tests à faire).
Tout comme GNOME, l'équipe de développement est très petite et bénévole, ce qui permet de justifier de ne pas ajouter trop d'options / fonctionnalités.
Je suis donc pour prendre le même genre de décision: réduire le plus possible le nombre de fonctionnalités pour augmenter la qualité du code restant.
Je sais que c'est assez rude pour nos utilisateurs, mais il faut être réaliste: depuis 4 ans (depuis que j'ai développé la nouvelle interface pour l'espace de rédaction), toutes les CSS alternatives sont cassées dans l'espace de rédaction (j'avais touché à l'HTML et au JavaScript).
Ça fait donc 4 ans que les CSS sont cassées pour la fonctionnalité majeur de LinuxFr: l'espace de rédaction collaboratif.
Le deuxième aspect important pour LinuxFr est la présentation et la lecture des articles. Un nouveau design plus moderne avait été proposé par mjourdan et pour l'implémenter, nous allons devoir forcément toucher au CSS, à l'HTML et au JavaScript. Ainsi, pour pouvoir améliorer ce second point majeur du site, nous serons encore une fois forcé de casser toutes les CSS alternatives.
En conclusion, je suis pour supprimer la fonctionnalité assez rapidement pour pouvoir plus facilement améliorer le CSS principal du site, ce qui aura beaucoup plus d'impact positifs pour les utilisateurs.
Je propose de faire cette suppression en même temps que le passage à Rails 7, ça simplifiera justement le nombre de tests à faire pour Rails 7 / Ruby 3.