Des thèmes ?

Pour la sécurité, c'est le problème de la personne qui utilise le thème, ça doit être explicitement précisé (du style "Zeste de Savoir ne peut pas contrôler les thèmes que vous utilisez, soyez donc prévenant et mangez des légumes").
Pour les images, à priori il n'y a que les avatars et smileys qui sont en durs, tout le reste semble bien faire partie du fichier css.

Une chose est certaine, personne ne fera de thème tant qu'il n'y aura pas la possibilité d'en faire

Pas toutes les images, comme la clem sur la home qui est avec un img.

Le message d'avertissement est indispensable mais on n'est quand même censer assurer la sécurité des informations sur la plateforme. C'est le même souci que le Play Store d'Android.

Un fichier CSS seul peut créer une faille de sécurité ?

Un fichier verrolé peu importe son extension peut créer des failles.

La question n'est pas l'extension mais le langage : CSS n'est pas Turing-complet et ses codes sources ne sont même pas vraiment exécutables, ils se contentent de changer en local l’agencement et l'apparence des éléments fournis par le site distant.

Alors avez-vous un exemple concret de faille qui peut être exploitée avec juste une feuille de style ?

Ouai, tu charge une image dans ton CSS qui est vérolé. Je récupère tes identifiants sur le site et si tu es admin, que du bonheur. C'est le premier truc qui me passe par la tête, y'a surement des trucs plus drôle à faire.

Note, je peux aussi faire ça en postant cette même image ici..

Vraiment pas fan de l'idée, mais pas pour des raisons techniques.

Il y a peu de contributeurs "front" sur ZdS, et parmi ce qu'on appelle le front, il y en a encore moins sur la partie layout/design (le CSS, les icônes et les images en gros).

D'un autre côté, le projet est open source et les gens sont assez patients et ouverts pour discuter en zone dev ou autre. Du coup, si certaines icônes sont laides, si le thème pouvait être amélioré, … On peut en discuter.

Faut pas oublier que sur la première version du SdZ, le thème était un peu vieillot, et les admins à raison s'étaient dit "on n'a personne pour faire un truc beau, c'est une bonne idée de laisser la communauté s'en occuper". Dans un proet open source, cet argument existe toujours, simplement, on peut contribuer directement au code.

Et pour le coup, en tant que simple membre de la communauté, je serais beaucoup plus enthousiaste de voir quelqu'un de compétent (ou pas hein, quelqu'un qui débute !) venir demander en zone dev comment le front fonctionne, comment on peut le modifier, installer une version de ZdS dans son coin et montrer son thème pour savoir s'il intéresse des gens ou non. Plutôt que quelqu'un qui bricole le CSS dans son coin, CSS qui va être pétée quand il va y avoir des modifications dans le code source du front avec tous les utilisateurs qui vont venir râler que leur thème est cassé, …

Le seul problème technique que je vois est celui-là : la maintenance. Et l'argument de "c'est au développeur du thème de s'en occuper" (encore heureux !) ne tient pas vraiment.

Premièrement : les développeurs front de ZdS vont être bridés par un système à forte inertie. En gros, ils vont être responsables d'une "API CSS" (comprendre : des noms de classe figés, …) à laquelle il va falloir faire attention et surtout faire rétro-compatible.

Deuxièmement : en termes de QA c'est pénible. Il va falloir passer un coup sur les thèmes custom pour vérifier que rien n'est cassé. La QA c'est déjà lourd et pas franchement folichon, je suis pas fan d'en rajouter une couche.

Enfin, qui dit : fournir un service (à travers des feuilles de style custom) dit : proposer des évolutions. En gros "Hello Sandhose : tu pourrais rajouter telle classe stp. j'en ai besoin pour mon thème". Et ça, avec l'équipe actuelle de dev de ZdS ça me paraît casse-gueule.

tl;dr : C'est sympa comme feature, mais franchement le retour sur investissement me paraît très faible, d'autant plus que les gens peuvent contribuer directement au code source du site et du front s'ils le souhaitent.

Mouais, je comprend pas pourquoi tant de réticences alors que le cadre est finalement (j'ai l'impression) assez simple à mettre en oeuvre :

• Sur ZdS il faudrait
  • rajouter une option de profil pour linker un CSS externe (j'insiste, cela n'a pas à être hébergé par ZdS) + un avertissement de sécurité/stabilité qui va bien ("ZdS ne peut garantir que les thèmes externes fonctionnent correctement toussa")
  • rajouter un test dans le fichier base.html pour tester si oui ou non l'utilisateur veut un design distant

Par contre :

• Le code est actuellement découpé en SCSS et donc conseillé de jouer avec puis compiler en CSS pour ceux qui veulent
• C'est overkill quand on sait qu'un partage de tweak à faire sur une extension fait grosso-modo la même chose (quitte à avoir un sujet épinglé sur cette idée)
• Les tweakers devront se débrouiller pour se tenir à jour entre les versions, on a pas assez de main d'oeuvre pour s'amuser à documenté tout les petits changements de CSS qui pourraient avoir lieu entre deux versions

Mouais, je comprend pas pourquoi tant de réticences

Est-ce-que tu as déjà "maintenu" du code CSS avec un client-tiers ?

En gros, est-ce-que tu as déjà écrit du CSS qui devait être utilisé par quelqu'un d'autre (qui en dépend), style qui va embarquer un bout de ton application dans une div, des saletés de widgets etc.

Si la réponse est non, je pense que c'est pour cela que tu ne comprends pas les "réticences". Honnêtement le langage est déjà chiant en lui même. Les outils aussi, ça va mieux, mais c'est toujours pas la panacée. Et je peux t'assurer que, même quand contractuellement c'est écrit "on est libre de casser votre bouzin" (donc plus "fort" qu'un simple avertissement) c'est quand même atrocement pénible de faire face à quelqu'un dont tu as cassé le travail… :|

C'est pas tant techniquement que psychologiquement / nerveusement. C'est juste chiant à faire, ça introduit une forme de complexité (que ce soit un simple champ supplémentaire dans la base de données, l'écran dans lequel on peut c/c le lien vers sa CSS externe) le fait que le site qui sert le CSS soit cassé, … C'est simplement pénible, d'où la réticence.

Effectivement le CSS moins j'y touche mieux j'me porte Mais toujours est-il que le problème sous-jacent est un "faux problème" puisqu'avec tout les navigateurs modernes on peux de toute façon bidouiller le CSS en utilisant des extensions. La seule différence sera sur l’interprétation de la chose. Dans un cas on cautionne le truc puisqu'on permet carrément le chargement en natif, dans l'autre c'est à vous de faire les override parce qu'on ne veut pas prendre la responsabilité de foutre du travail en l'air .

Perso j'ai choisi depuis longtemps la troisième voie : M'investir directement en proposant des idées (ou réagire aux idées) via le forum et aussi directement développé pour la plate-forme

Sur mobile ça serait pratique de pouvoir personnaliser le CSS.

Je tiens juste à signaler à toute fin utile qu’un thème sombre Stylish est déjà développé et utilisé par plusieurs membres du site (dont moi).

Et oui je trouve que ce serait pratique de pouvoir gérer ça via le site mais je laisse les devs décider de ce qui est le mieux avec les ressources qu’ils ont.

Cela dit la maintenance du thème ne me semble pas un gros problème. Des fois il y a des maj qui pètent des trucs sur le thème sombre, mais au final c’est le genre de trucs qui se corrige rapidement.