Add support for rendering rich text

[tronical]

This task is derived from #2723 but with a focus solely on providing the APIs to feed attributed text into Slint and rendering, NOT to support the end-user editing said text.

The following feature set for attributes is in scope:

• Hyperlinks (including way of handling clicks)
• Text colors
• Style: Bold, Italic, Underline
• Unordered/ordered lists

List of things to do before this issue is done:

• better interpolation handling. The following should work: @markdown("# Foo {}", @markdown("*Bar*")) / @markdown("`{}`", "Some`Code`With`Quote"); (this may mean doing the interpolation as part of the parsing instead of escaping)
• Document the StyledText element in the language reference (including an inline example with screenshot, as well as what type of styling is supported)
• C++ Api needs a way of constructing a StyledText from markdown (including a unit test)
• Make sure the software renderer doesn't panic when rendering a StyledText element
• A test in tests/cases/elements that constructs a StyledText element in Slint and the styled-text is exposed to Rust and C++, and it can be read and written from Rust and C++. Verify that the preferred-height is greater than zero when a text is set, so that when the test is run, the entire parsing and layout code path as well as the code generator is covered.
• Produce compile errors when invalid markdown is used with @markdown(). (extend internal/compiler/tests/syntax/basic/markdown.slint)
• One last API review before the next release.
• Extend the widgets gallery example to show hyperlinks, text colours, styles (bold/italic/underline) and unordered/ordered lists.
• Add a test for the StyledText::link-clicked callback. Send a synthetic mouse click in a new or existing test under tests/cases and verify the callback was invoked.
• Add Slint.open-url(string) function #10513

[ogoffart]

We should also figure out how to define richtext in slint files and in the API.

• Do we want to re-use Text { }, or should we have a RichText { }, or just another rich-text: property to Text
• How to represent rich text in our slint markup. We probably want to use a @md(...) macro that would prevent "markdown" injection. Assuming we want markdown. See my comment in Rich text editor #2723 (comment)

I would think we would need a different type like rich-text which is not a string.
The internal representation of which is some data structure optimized for fast rendering.

In .slint rich-text could be constructed with @md or similar macro.
In Rust/C++, we could have api like slint::RichText::from_markdown

That said, we should not lock ourselves in to markdown and allow other representation such as HTML subset or something like that.
Whatever we do, we should document exactly what subset of markdown we support.

[U007D]

Is there any possibility of also including strikethrough text?

[expenses]

Is there any possibility of also including strikethrough text?

Yep, that should be possible!

[expenses]

I've started implementing this via markdown in #9733. This gets us some of the way there, with a few notes and TODOs:

• Indentation, bullet points and numbers for ordered/unordered lists are hardcoded
• Strikethroughs aren't actually rendered yet
• The internal API isn't ideal (See Very basic Rich Text Support #9733 (comment))
• At the very least, links aren't implemented. (Not sure if we want headers, horizontal lines, etc)

Furthermore, there are a few things that markdown is incapable of giving us (unless we use a custom fork or raw html):

• Text colors
• Underlines
• Changing the size of text outside of a header

[Aloso]

Markdown might just be the worst possible format for this purpose.

• It has a spec (CommonMark), but most implementations in the wild aren't fully conforming

• CommonMark allows raw HTML

• CommonMark has multiple ways to represent something (* or - for bullet lists, --- or *** for rulers, ``` or ~~~ or indentation for code blocks, ATX or setext headings, backslash or two spaces for hard line breaks, ...)

• CommonMark is notoriously difficult to parse correctly in all the edge cases, especially regarding indentation

• The most popular implementations have various extensions (strikethrough, tables, footnotes, autolinks, task lists, callouts, definition lists, subscript, superscript, ...) that aren't part of the CommonMark spec

By contrast, HTML is relatively straightforward to parse and does not have hundreds of edge cases. It is consistently parsed by all applications that support HTML. Supported features can be easily configured with an allowlist of HTML tags and attributes. If Slint adds a new feature at a later date (e.g. blockquotes), the corresponding tag can simply be added to the allowlist; no changes to the HTML parser are required.

[nicoburns]

To be fair, Markdown can be very easily compiled to HTML. There are at least two Rust crates (comrak and pulldown_cmark) that implement all the corner cases of the CommonMark specification and most of the extensions.

I do agree that implementing rich text rendering from a parsed HTML tree would likely be easier than doing it directly from markdown. But it would come with the cost of having to include an HTML parser.

[Aloso]

And if the rich text editor spits out Markdown, what are users going to do with it? Many will send it to a web server, I assume. There, it will likely be converted to HTML and stored in a DB, or the Markdown will be stored in a DB directly. If it's the latter, it probably has to be converted to HTML later, e.g. when displaying it in a browser using JavaScript.

If the web server is written in Python, they will probably use the markdown package, which is not CommonMark compliant and lacks sanitization.

If the web server is written in PHP, they'll likely use the parsedown package, but it is unmaintained and has serious bugs. Maybe they'll use php-markdown instead, which also has lots of bugs and isn't CommonMark compliant.

I could continue this list with other languages, but you get the point.

Markdown is not interoperable. It is a security nightmare – several packages don't offer sanitization, or their parser can exhibit exponential backtracking, which enables DoS attacks.

What even is the point of producing Markdown, if users are expected to convert it to HTML anyway?