Support HTML codes in RichTextLabel

[easypronunciation]

Background: Google Play and App Store require the published apps to have the Terms and Conditions and the Privacy Policy.
One can easily find generic versions of such documents online in HTML format. They look nice when published online: headings, lists, links, etc. All this nice formatting is lost when such document is pasted into the text field of a label.
RichTextLabel with BBCode enabled has the following downsides:

• no headings
• requires to rewrite the document in different markup language. The automatic plugins to convert html to BBCode don't give consistent results.

Adding the support for HTML-formatted documents would streamline creating these 2 documents (required for publishing the games).
The support for the following tags would be nice:
p, h1, h2, h3, h4, strong, a, ul, ol, li, u, i, b, em, br, hr

[AThousandShips]

To clarify, do you mean adding support for HTML highlighting to the script editor?

[AThousandShips]

Wouldn't the better option be to expand the formatting abilities of BBCode? Why should a new node be created that does more than the existing one?

[easypronunciation]

I updated the original post. The plugins give inconsistent results. For example, the list formatting (to create ordered and unordered list) is not standard (compare with https://www.phpbb.com/community/help/bbcode and https://en.wikipedia.org/wiki/BBCode ).
Instead of expanding something that is not standard, wouldn't it be nice to use the language that is already known by millions? And no additional steps/plugins would be required.

[AThousandShips]

This returns to the point of ensuring BBCode is standard, I'd say HTML is ill suited to cleanly formatting text in UI like this, it's not WYSIWYG (what you see is what you get) and can be hard to read cleanly in formatting, also if we add HTML then not having CSS seems weird

The RichTextLabel isn't designed to be a complete full typesetting or format tool, that would be best handled by custom text rendering etc., it's designed to be a versatile tool to do general formatting and for that it's generally sufficient.

We couldn't really add all of HTML so it'd be confusing where things aren't supported, and what subset of HTML to decide on using, and adding a whole new formatting language when we have a perfectly good one is a lot of work

[theraot]

@easypronunciation Note that those linked documents agree on how to make the lists. The difference you see in the output is in CSS. If you want to preserve the formatting of an HTML document ultimately you will want CSS support. While I can see it would be useful, having CSS only for RichTextLabel seems to me as too much effort of a niche usecase.

So converting html to BBCode sounds like a good solution. You don't need consistent results, you need a result that looks good enough for the legal documents in your game, or atleast that is not to hard to fix. And since we are not talking of supporting a large number of arbitrary documents, you can fix those and move on.

[easypronunciation]

@theraot Yes, the 2 links I shared agree on how to make the lists, but Godot uses different tags to create lists - [ul] and [ol] which are not supported by commonly available html-to-bbcode converters. https://docs.godotengine.org/en/stable/tutorials/ui/bbcode_in_richtextlabel.html

[theraot]

On desktop we can always launch the documents in a viewer... Now for smartphones, launching the documents in an external viewer is not an option. So, I believe that if there is a proposal/feature request it is along those lines: an API to open an HTML document either using a browser in desktop or an embedded viewer of smartphones, perhaps a frame or a new tab in the web... I don't know about consoles. It would have to be clear that it is for legal documents and there are no guaranties on the features it supports. Heck, it might not be HTML, it could be PDF or something else. Perhaps it can be document resource type that Godot builds into whatever is supported in the target platform, which would also disuade developers from trying to make it dynamic.