Discrepency between preview of comment and actual comment

[XRFXLP]

Bug

HTML tags(except some self closing tags) and KaTeX shows the expected representation in the preview but not in the actual comment.

On using following snippet:

Headings:
<h1>H</h1>

Colored text:  <span style="color:red"> Red coloured text</span>

Image:

<img src="https://www.wikipedia.org/portal/wikipedia.org/assets/img/Wikipedia-logo-v2.png"/>

Line break:  
AAAAAAAA<br/>BBBBBBBB  

Horizontal line: 
<hr/>

KaTeX:
    ```math

            \displaystyle{\oint_L} \dfrac{dz}{z} = 2 \pi i

    ```While previewing::![image](https://user-images.githubusercontent.com/23459568/100134896-e7053f00-2eae-11eb-8020-d1fb8cda0bbf.png)But in the actual comment: ![image](https://user-images.githubusercontent.com/23459568/100135151-3ba8ba00-2eaf-11eb-9728-6e382a7bda36.png)

As you can see only self-closing tags have positive consistent behaviour.

Expected behaviour

There should consistency between actual comment and preview of the comment

Additional context

This behaviour has nothing to do with last UI update, I've seen this couple of months ago.

┆Issue is synchronized with this Clickup by Unito

[kazk]

It's been always different. Comment previews are done by the frontend and the actual comments are returned from the backend using different libraries, so it can be different depending on the features available. It's much better than few years ago because it's both based on CommonMark now.

I can try to minimize the difference where possible.

---

I can't reproduce the heading size in preview. The actual comment has <h1>H</h1> too. I think the headers in comments have smaller font because users who doesn't know markdown can accidentally post a comment with huge text and that became annoying. I can consider changing that after giving moderators the privilege to fix comments like that.

For the red text with style attribute, maybe the server side processor is configured to strip them. I'll need to check that.

For KaTeX, the server side processor simply doesn't know how to handle it. The preview shows it because it's using the same configuration as the kata description.

[hobovsky]

Possible related: is any of this a reason why description preview in translations works differently than description preview of kata?

Descriptions in translations are sometimes difficult to get right, because after you resolve all merge conflicts you cannot be sure if you got code blocks or KaTeX right. KaTeX does not seem to work, sequenced code blocks do not work either, be it in edit preview or in saved, rendered description. I think there's also an issue with previewing/rendering Markdown tables.

I would like to report this behavior because it's kind of a nuisance when resolving merge conflict in translations. Does it fit here or should I create new issue?

[kazk]

Yeah, the description of the translation (kumite) is also done by the backend.

Does it fit here or should I create new issue?

Can you open a new one? Mentioning this issue as related.

[XRFXLP]

I can't reproduce the heading size in preview.

Sorry, I thought the behaviour would be same in "normal preview mode" and "Edit in full-screen mode" .

The behaviour is only reproducible when you'll edit in full screen mode.

[kazk]

Sorry, I thought the behaviour would be same in "normal preview mode" and "Edit in full-screen mode"

No need to apologize, I thought so too!

This happens because the full-screen mode doesn't apply the special heading style for comments. The normal preview does because it's rendered within the comment UI.

[Blind4Basics]

not sure if it's old or new, but the renderer is litterally acting, here: all katex expressions are tripled.

the above is in a kumite (I'm forking a kata), but I got similar problem when I did a copy/paste from a description to the editor in a trainer.

Is that something new?

eidt: after publication, the description is rendered correctly.

[kazk]

@Blind4Basics Not sure what's going on there, but that should be a separate issue. Can you open a new issue?