The "button" HTML5 tag renders in the editor previewer, but not rendered posts

Problem

After saving the content of the post, it renders for approximately 4 ms in the rendered post, before a loading circle appears for 2 ms, and it’s gone:

Solutions

If it rendering in the previewer is accidental, and it being cleansed from the rendered post is deliberate because of security concerns that I’m unaware of, could you not at least just replace <button> with <button disabled>?

I ask because I see frequent misuse of <code> and <kbd> where <button> would be semantic, especially in tutorials and reproduction steps.

1개의 좋아요

I’m not sure if it’s a bug per se. I understand your confusion.

To prevent HTML tags and attributes/classnames from being filtered out, this needs to be explicitly allowed in Discourse core or a plugin.

For example, a default list can be found here:
https://github.com/discourse/discourse/blob/main/app/assets/javascripts/pretty-text/addon/allow-lister.js#L115

It’s also possible to allow a tag for the preview only. For example, the image controls have several tag/class name/attribute combinations.

https://github.com/discourse/discourse/blob/main/app/assets/javascripts/discourse-markdown-it/src/features/image-controls.js#L198

You see the button in preview because it’s a side effect of the tag that is allowed here.
However, the disabled attribute is ignored because it is not defined.

https://github.com/discourse/discourse/blob/main/app/assets/javascripts/discourse-markdown-it/src/features/image-controls.js#L223

I did not check how the allowed list is parsed; I wonder if it’s the expected behavior. :thinking:. Currently, it seems the tag is allowed regardless of the attributes. I would have expected that the button is not rendered if you are not using exactly, for example, <button class="alt-text-edit-ok btn btn-primary">.

You can make a plugin to allow <button> on post render. Let me know if you need assistance.

2개의 좋아요

@Arkshine, I am thankful. However, I’m not an instance operator. I’ve merely noticed this when formulating content.

This is one of many instances in which the HTML5 and CSS3 representations in the previewer differ from the eventual render, which means that writing content for Discourse can be difficult. This is especially so when edits have been disabled or limited to a very small timeframe, instance-wide.

1개의 좋아요

I understand; that makes sense! I agree that’s not a great experience.

If you want, I made this tiny plugin to allow <button> with disabled attribute: GitHub - Arkshine/discourse-markdown-allowlist · GitHub

Unfortunately, you can’t make settings in this situation, so if you want to add another tag, you will need to fork my repository and add it yourself here.

3개의 좋아요

@Arkshine, can that not be upstreamed? I ask because this affects every instance I use, and asking all of them to incorporate a patch for something so trivial to them would probably be infeasible.

Usually, I’d make an issue for something like this on the relevant GitHub repository, but the issue section is disabled for Discourse’s.

여기서는 GitHub 대신 #contribute:feature를 사용해야 하나요? #contribute:bug는 이 경우에 해당하지 않으니까요.

@Jagster, 이 태그가 단순히 사용할 수 없는 상태라면 그렇게 했을 것입니다. 하지만 미리보기 기능이 미리보기 역할을 하지 못하는 것은 #contribute:bug입니다.

이를 기능 요청으로 분류하려면 제목을 어떻게 다시 작성해야 할까요?

1개의 좋아요

#contribute:feature는 누락된 기능에 대한 카테고리입니다. #contribute:bug는 오류를 위한 것이며, 이는 오류가 아닙니다.

GitHub의 이슈 섹션을 사용하는 것과 정확히 같은 방식으로 사용하면 어떨까요?

1개의 좋아요

미리보기와 렌더링된 게시물 간의 불일치를 Contribute > Bug 로 다루는 것이 합리적이라고 생각합니다.

해결책은 미리보기에서도 이를 차단하는 것이 될 가능성이 높으며, 이는 앞으로 "게시물에 <button> 지원을 추가"하는 것이 유효한 Contribute > Feature 요청이 될 수 있음을 의미합니다 :wink:

3개의 좋아요

Indeed, @david. I should have separated these:

Apologies, and thanks.

3개의 좋아요