Misc. bug: Web UI displays raw html tags (e.g. `<br>`) instead of rendering them in markdown tables

[TFWol]

Name and Version

version: 7139 (923ae3c)
built with clang version 19.1.5 for x86_64-pc-windows-msvc

Operating systems

Windows

Which llama.cpp modules do you know to be affected?

llama-server

Command line

Problem description & steps to reproduce

An easy way to reproduce:

• Enable "Render user content as Markdown" and then paste this into the Web UI chat (without the triple backticks):

| **Item** | **Description** | **Notes** |
|----------|-----------------|-----------|
| Item 1   | Simple single line | - Point A<br>- Point B<br>- Point C |
| Item 2   | Multi‑line text using plain line breaks (supported by some renderers) | Line 1<br>Line 2<br>Line 3 |
| Item 3   | Embedded list with HTML tags | <ul><li>First</li><li>Second</li><li>Third</li></ul> |
| Item 4   | Mixed content (text + list) | Text before list:<br>- Alpha<br>- Beta<br>End of list. |

Expected Output:

Item	Description	Notes
Item 1	Simple single line	- Point A - Point B - Point C
Item 2	Multi‑line text using plain line breaks (supported by some renderers)	Line 1 Line 2 Line 3
Item 3	Embedded list with HTML tags	First Second Third
Item 4	Mixed content (text + list)	Text before list: - Alpha - Beta End of list.

What gets rendered:

It's mostly a pain for generation when using GPT-OSS since it really loves using <br> in its tables.

First Bad Commit

No response

Relevant log output

[ServeurpersoCom]

I noticed the same behavior when I refactored the AST rendering pipeline. I also tested it with output from one of my navigation tools that uses “html-to-markdown”. This was a deliberate design choice for simplicity. The “html-to-markdown” library (which is unrelated to the llama.cpp frontend) counts HTML tags as part of the text length, which means the cell widths shift as soon as HTML appears. Rendering it properly would require recalculating the entire table layout so that the Markdown remains structurally valid. Because of this, the current implementation does not attempt to interpret HTML inside table cells.

[ServeurpersoCom]

It would also be possible to add a small post-processing step at the end of the AST pipeline, just before converting to HTML, that restores visual line breaks from <br> while keeping the raw Markdown intact, as long as this happens only inside tables, and with care not to render or hide any other XML-style tags.

I can experiment with rendering <br> inside table cells, but the use of inline HTML in Markdown is ambiguous across specifications, so any HTML rendering needs to be handled with extra caution.
By the way, in this comment my <br> tags are actually rendered correctly when I don’t escape them.
If the Markdown-only rendering filter is strict enough, I could even extend it to safely handle lists inside table cells as well.

I also noticed that in many industry standard WebUIs, the user’s Markdown renderer is not the same as the agent’s; it’s much more limited and strict, which avoids unwanted formatting when pasting source code. Here we only have one.

[ServeurpersoCom]

This doesn’t introduce any regressions since the post-processing targets only table cells. Now that this part is stable, I can also start working on handling lists inside tables next.

[ServeurpersoCom]

When Markdown is enabled for the user, the colors are really ugly, the links are white on white, and the table cells turn completely black when you hover over them -> I'll make a note of that for another pull request...

[ServeurpersoCom]