Le souci des feuilles de style contribuées c'est
- un peu pénible à faire initialement : techniquement la CSS, artistiquement ses éventuelles images et choix de palette et de design
- très pénible à mettre à jour : déjà y en a plein, ensuite faut tester des tas de choses différentes, certaines parties n'ont jamais été faites (typiquement la zone d'administration ou les fonctionnalités ajoutées post-création de la CSS), etc. Et de fait rarement mises à jour.
- certaines ne sont carrément pas utilisées (et encore je suppose que certaines sont choisies au pif par des bots de spam)
Regardons le dernier point avec la page des stats :
Toutes les CSS contribuées :
- RonRonnement-Bordeau 1%
- RonRonnement-Classic 2%
- RonRonnement-Mauve 1%
- RonRonnement-Orange 1%
- RonRonnement-Rose 1%
- RonRonnement-Sepia 0%
- RonRonnement-Turquoise 2%
- RonRonnement-Vert 2%
- black_bling 0%
- blue-smooth -> pas utilisée
- cascade-alternative 1%
- cascade 0%
- edition_papier -> pas utilisée ?
- grayscale-mobile & grayscale-print & grayscale -> pas utilisées
- grises 2%
- kaiska-new 2%
- kaiska-short 1%
- kitch -> pas utilisée
- newton 0%
- nightgrey 2%
- opensuse 1%
- plee_the_bear 1%
- retro -> pas utilisée
- solarized_dark_dark_code 1%
- solarized_dark_light_code 0%
- solarized_light_dark_code 0%
- solarized_light_light_code -> pas utilisée
- spasibo-mobile et spasibo 0%
- steelblue 1%
# Laisser tomber pour la maintenabilité
Posté par Adrien Dorsaz (site web personnel, Mastodon) . É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.
[^] # Documenter pour la maintenabilité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5 (+0/-0).
Ne faudrait-il pas mieux avoir la/le structure/squelette des différentes pages HTML (brut, sans devoir aller fouiller dans le code RoR) dans un dossier, et que celles-ci soient mises à jour lors des évolutions ? (mieux si c’est versionné pour pouvoir voir le diff…)
Ceci permettra aux mainteneuses et mainteneurs de styles tiers de pouvoir faire évoluer les styles, qui pourront être désactivées dans un premier temps, le temps d’être mis à jour. (un peu comme les modules de Drupal ou les extensions de SPIP.) En prévenant un peu tôt que ça va casser et en donnant le moyen de pouvoir suivre et réparer, il n’y aura plus de raison de se retenir de faire évoluer le site.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Documenter pour la maintenabilité
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Dans le code sources, les "views" contiennent les modèles qui définissent la structure de l'HTML.
En 4 ans, personne n'a proposé de modifications sur ces styles, il n'exise pas d'équipe de maintenance pour les styles.
[^] # Re: Documenter pour la maintenabilité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Merci pour l’info sur les "views" : je n’avais pas su où trouver l’info quand j’ai voulu faire un style perso.
J’ai bien compris pour l’équipe ; je parlais des gens qui maintiennent au sens des gens qui ont fait la conception (tant qu’ils ou elles veulent faire le suivi) ou les gens qui utilisent utilisent et veulent que ça reste. Bref, les 1% qui utilisent certains thèmes, si ça les intéressent on leur laisse les infos nécessaires.
Parlant de ça, il faudrait voir/déterminer par rapport aux vues les classes et identifiants importants/nécessaires pour déterminer automatiquement (script shell ou Ruby ou autre) le niveau de finalisation (en pourcentage) des styles et donc lesquels désactive/conserver lors des montées de versions. L’idée est d’avoir (le support de) la fonctionnalité sans que ce soit bloquant ni que vous ayez à maintenir les thèmes.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Variantes
Posté par nud . Évalué à 3 (+0/-0).
J'ai déjà proposé par le passé de supprimer tout ça quitte à laisser les gens utiliser une autre stylesheet hébergée ailleurs si ça les chante, mais une autre possibilité qui couvrerait une bonne partie des usages ce serait tout simplement de permettre d'avoir des nuances via des variables SASS ou CSS, genre on définit quelques couleurs et voilà. C'est comme ça que la plupart des sites "customisables" fonctionnent de nos jours et c'est relativement simple à maintenir tant qu'on ne permet que le changement de paramètres.
Evidemment dans un premier temps il est possible de supprimer tous les styles alternatifs en attendant que quelqu'un d'intéressé fournisse un patch.
[^] # Re: Variantes
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
C'est déjà le cas de la CSS par défaut qui est disponible avec de légères variations de couleurs ?
[^] # Re: Variantes
Posté par nud . Évalué à 3 (+0/-0). Dernière modification le 21 décembre 2023 à 15:00.
Oui, à peu près, mais certaines de ces alternatives (par exemple Sepia) modifient plus que la valeur des couleurs.
Cette approche permet aussi de couvrir les besoins de "thèmes sombres". On pourrait même détecter la préférence de l'utilisateur pour afficher un thème sombre ou clair, c'est à la mode.
De même, le support des différents types de devices (le "responsive design") devrait faire partie de la stylesheet par défaut et pas un style séparé (ce qui n'était pas possible y'a 10 ans). Idem pour l'impression. Ces cas ne justifient plus la présence de styles alternatifs.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.