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

Bug
1

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 Like
2

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:

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

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.

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.

1 Like
3

@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 Like
4

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

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.

1 Like
5

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

6

Use Feature here instead of GitHub? Because Bug this isn’t.

7

@Jagster, were this tag merely unavailable, I would. However, the previewer not functioning as a previewer is a Bug.

How would you classify this as a feature – how would you rewrite the title to demonstrate this?

1 Like
8

Feature is a category for missing features. Bug is for errors, and this is not an error.

Perhaps you would like to use it exacly same way you would use an issue section in GitHub?

1 Like
9

I think the inconsistency between preview and rendered posts is reasonable to consider as a Bug.

The solution will probably be to block it in the preview too, which means that “adding <button> support to posts” would be a valid Feature request in future :wink:

3 Likes
10

Indeed, @david. I should have separated these:

Apologies, and thanks.

2 Likes