A tag "button" do HTML5 é exibida na pré-visualização do editor, mas não nos posts renderizados

Contribuir Bug
1

Problema

Após salvar o conteúdo da postagem, ele é renderizado por aproximadamente 4 ms na postagem renderizada, antes que um círculo de carregamento apareça por 2 ms e desapareça:

Soluções

Se a renderização no visualizador for acidental e a remoção da postagem renderizada for deliberada devido a preocupações de segurança que desconheço, você não poderia, pelo menos, substituir <button> por <button disabled>?

Pergunto porque vejo uso frequente incorreto de <code> e <kbd> onde <button> seria semântico, especialmente em tutoriais e passos de reprodução.

1 curtida
Render `<button disabled>` in markdown
2

Não tenho certeza se é um bug em si. Entendo sua confusão.

Para evitar que tags e atributos/nomes de classe HTML sejam filtrados, isso precisa ser explicitamente permitido no núcleo do Discourse ou em um plugin.

Por exemplo, uma lista padrão pode ser encontrada aqui:

Também é possível permitir uma tag apenas para a pré-visualização. Por exemplo, os controles de imagem têm várias combinações de tags/nomes de classe/atributos.

Você vê o botão na pré-visualização porque é um efeito colateral da tag que é permitida aqui.
No entanto, o atributo disabled é ignorado porque não está definido.

Não verifiquei como a lista permitida é analisada; me pergunto se é o comportamento esperado. :thinking:. Atualmente, parece que a tag é permitida independentemente dos atributos. Eu esperaria que o botão não fosse renderizado se você não estivesse usando exatamente, por exemplo, <button class="alt-text-edit-ok btn btn-primary">.

Você pode criar um plugin para permitir <button> após a renderização. Me avise se precisar de ajuda.

2 curtidas
3

@Arkshine, sou grato. No entanto, não sou um operador de instância. Eu apenas notei isso ao formular o conteúdo.

Este é um de muitos casos em que as representações HTML5 e CSS3 no previewer diferem da renderização eventual, o que significa que escrever conteúdo para o Discourse pode ser difícil. Isso é especialmente verdade quando as edições foram desabilitadas ou limitadas a um período muito curto, em toda a instância.

1 curtida
4

Entendo; faz sentido! Concordo que essa não é uma ótima experiência.

Se quiser, fiz este pequeno plugin para permitir <button> com o atributo disabled: GitHub - Arkshine/discourse-markdown-allowlist

Infelizmente, você não pode fazer configurações nesta situação, então se quiser adicionar outra tag, precisará fazer um fork do meu repositório e adicioná-la você mesmo aqui.

3 curtidas
5

@Arkshine, isso não pode ser enviado para a upstream? Pergunto porque isso afeta todas as instâncias que uso, e pedir a todas elas para incorporar um patch para algo tão trivial para elas provavelmente seria inviável.

Normalmente, eu criaria um problema para algo assim no repositório GitHub relevante, mas a seção de problemas está desativada para o Discourse.

6

Use Contribute > Feature aqui em vez do GitHub? Porque Contribute > Bug isso não é.

7

@Jagster, se essa tag estivesse apenas indisponível, eu o faria. No entanto, o visualizador não funcionar como tal é um Contribute > Bug.

Como você classificaria isso como um recurso – como você reescreveria o título para demonstrar isso?

1 curtida
8

Contribute > Feature é uma categoria para recursos ausentes. Contribute > Bug é para erros, e este não é um erro.

Talvez você queira usá-lo exatamente da mesma forma que usaria a seção de problemas no GitHub?

1 curtida
9

Acho que a inconsistência entre a visualização e as postagens renderizadas pode ser considerada um Contribute > Bug.

A solução provavelmente será bloqueá-la também na visualização, o que significa que “adicionar suporte a <button> nas postagens” seria um pedido de recurso válido Contribute > Feature no futuro :wink:

3 curtidas
10

De fato, @david. Eu deveria ter separado estas:

Desculpe, e obrigado.

3 curtidas