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

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
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.

2 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 Feature aqui em vez de GitHub? Porque Bug isto não é.

7

@Jagster, se esta tag estivesse meramente indisponível, eu o faria. No entanto, o previewer não funcionar como um previewer é um Bug.

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

1 curtida
8

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

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

1 curtida
9

Acho que a inconsistência entre a visualização e as postagens renderizadas é razoável de se considerar um Bug.
A solução provavelmente será bloqueá-la também na visualização, o que significa que “adicionar suporte a <button> às postagens” seria uma Feature válida no futuro :wink:

3 curtidas
10

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

Desculpe, e obrigado.

3 curtidas