Dans l'absolu je ne suis pas persuadé que les CSS alternatives soient une fonctionnalité à mettre en avant. C'est pratique pour les contributeurs ou pour certains power users mais je ne pense pas que ce doit être une "solution" pour un quelconque problème. Les problèmes courants et moins courants (comme les divers problèmes d'accessibilité et d'handicap) doivent être gérés dans la CSS par défaut.
Si l'on met la fonction en avant et si l'on conseille aux gens de l'utiliser, il faut alors fournir des garanties sur les CSS alternatives. De même, si l'on maintient plusieurs CSS "officielles" (ce qui est le cas actuellement) cela complexifie la maintenance et le développement car chaque changement du markup site implique de mettre toutes les CSS à jour. Vu la "main d'œuvre" limitée et le peu d'utilisation de la fonctionnalité, le choix rationnel serait de sabrer.
Concernant le suivi, et toujours conformément à ce problème de main d'œuvre, pourquoi maintenir le suivi plutôt que d'utiliser les outils fournis par la forge que l'on utilise ? C'est comme cela que fonctionne webcompat.com: ils ont un compte "bot" qui ajoute les bugs pour les non-membres de github. D'ailleurs pour ce qui est de linuxfr-design, est-on censé utiliser le suivi ou bien reporter un bug sur github ?
Par ailleurs j'ai une PR qui moisit depuis 4 mois sans réaction aucune.
[^] # Re: CSS Alternatives
Posté par nud . En réponse à la dépêche Refaire LinuxFr.org : résultats de l’enquête. Évalué à 8.
Dans l'absolu je ne suis pas persuadé que les CSS alternatives soient une fonctionnalité à mettre en avant. C'est pratique pour les contributeurs ou pour certains power users mais je ne pense pas que ce doit être une "solution" pour un quelconque problème. Les problèmes courants et moins courants (comme les divers problèmes d'accessibilité et d'handicap) doivent être gérés dans la CSS par défaut.
Si l'on met la fonction en avant et si l'on conseille aux gens de l'utiliser, il faut alors fournir des garanties sur les CSS alternatives. De même, si l'on maintient plusieurs CSS "officielles" (ce qui est le cas actuellement) cela complexifie la maintenance et le développement car chaque changement du markup site implique de mettre toutes les CSS à jour. Vu la "main d'œuvre" limitée et le peu d'utilisation de la fonctionnalité, le choix rationnel serait de sabrer.
Concernant le suivi, et toujours conformément à ce problème de main d'œuvre, pourquoi maintenir le suivi plutôt que d'utiliser les outils fournis par la forge que l'on utilise ? C'est comme cela que fonctionne webcompat.com: ils ont un compte "bot" qui ajoute les bugs pour les non-membres de github. D'ailleurs pour ce qui est de linuxfr-design, est-on censé utiliser le suivi ou bien reporter un bug sur github ?
Par ailleurs j'ai une PR qui moisit depuis 4 mois sans réaction aucune.