Après avoir enregistré le contenu de la publication, il s’affiche pendant environ 4 ms dans la publication rendue, avant qu’un cercle de chargement n’apparaisse pendant 2 ms, puis il disparaît :
Solutions
Si son affichage dans l’aperçu est accidentel, et que son retrait de la publication rendue est délibéré en raison de préoccupations de sécurité que j’ignore, ne pourriez-vous pas au moins remplacer <button> par <button disabled> ?
Je pose la question car je constate une utilisation fréquente de <code> et <kbd> là où <button> serait sémantique, en particulier dans les tutoriels et les étapes de reproduction.
Je ne suis pas sûr que ce soit un bug en soi. Je comprends votre confusion.
Pour empêcher que les balises HTML et les noms d’attributs/classes ne soient filtrés, cela doit être explicitement autorisé dans le cœur de Discourse ou dans un plugin.
Par exemple, une liste par défaut se trouve ici :
Il est également possible d’autoriser une balise uniquement pour l’aperçu. Par exemple, les contrôles d’image comportent plusieurs combinaisons de balises/noms de classes/attributs.
Vous voyez le bouton dans l’aperçu car c’est un effet secondaire de la balise qui est autorisée ici.
Cependant, l’attribut disabled est ignoré car il n’est pas défini.
Je n’ai pas vérifié comment la liste des éléments autorisés est analysée ; je me demande si c’est le comportement attendu. . Actuellement, il semble que la balise soit autorisée indépendamment des attributs. Je m’attendrais à ce que le bouton ne soit pas rendu si vous n’utilisez pas exactement, par exemple, <button class="alt-text-edit-ok btn btn-primary">.
Vous pouvez créer un plugin pour autoriser <button> après le rendu du post. Faites-moi savoir si vous avez besoin d’aide.
@Arkshine, je vous suis reconnaissant. Cependant, je ne suis pas un opérateur d’instance. J’ai simplement remarqué cela en formulant du contenu.
C’est l’un des nombreux cas où les représentations HTML5 et CSS3 dans l’aperçu diffèrent du rendu final, ce qui rend la rédaction de contenu pour Discourse difficile. C’est particulièrement vrai lorsque les modifications ont été désactivées ou limitées à un très court laps de temps, à l’échelle de l’instance.
Malheureusement, vous ne pouvez pas définir de paramètres dans cette situation, donc si vous souhaitez ajouter une autre balise, vous devrez forker mon dépôt et l’ajouter vous-même ici.
@Arkshine, cela ne peut-il pas être intégré en amont ? Je pose la question car cela affecte toutes les instances que j’utilise, et demander à toutes d’intégrer un correctif pour quelque chose d’aussi trivial pour elles serait probablement irréalisable.
Habituellement, je créerais un problème pour ce genre de chose sur le dépôt GitHub pertinent, mais la section des problèmes est désactivée pour ceux de Discourse.
@Jagster, si cette balise était simplement indisponible, je le ferais. Cependant, le fait que l’aperçu ne fonctionne pas comme un aperçu est un Contribute > Bug.
Comment le classeriez-vous comme une fonctionnalité – comment réécririez-vous le titre pour le démontrer ?
Contribute > Feature est une catégorie pour les fonctionnalités manquantes. Contribute > Bug est réservé aux erreurs, et il ne s’agit pas d’une erreur ici.
Peut-être souhaitez-vous l’utiliser exactement comme vous utiliseriez la section « Issues » sur GitHub ?
Je pense que l’incohérence entre les aperçus et les publications rendues peut raisonnablement être considérée comme un Contribute > Bug.
La solution consistera probablement à bloquer cela dans l’aperçu également, ce qui signifie que « l’ajout du support des <button> dans les publications » serait une demande Contribute > Feature valide à l’avenir
. Actuellement, il semble que la balise soit autorisée indépendamment des attributs. Je m’attendrais à ce que le bouton ne soit pas rendu si vous n’utilisez pas exactement, par exemple, 