[AppStream] Additional markup support in descriptions

Richard Hughes hughsient at gmail.com
Fri Jul 26 12:10:15 UTC 2019


On Fri, 26 Jul 2019 at 05:32, Robert Ancell <robert.ancell at canonical.com> wrote:
> - emphasis <em>

On the assumption that emphasis is normally rendered as italic I
suppose. Fine for me, but see below.

> - strong emphasis <strong>

Works for me, but I suppose we'd need some kind of guidance about the
amount of text is appropriate to make either <strong> or <em> -- e.g.
you don't want app authors to make *everything* bold "just to make it
stand out from other apps".

> - code <code> or <pre> or <pre><code> (CommonMark uses options 1 and 3, but it's probably simpler to just only <code> or <pre> in AppStream. I'm not enough of an XML expert to work out the differences between these tags).

<code> is typically inline monospace, and I think that's very much the
one we want to use. <pre> is similar, but you have to respect the
whitespace (including newlines) which might be fraught with
difficulties between implementations, and also I don't really want to
see entire blocks of monospace text in an application description.

> I'm not proposing we add those at this time as the headers can be confusing with the information shown around descriptions

Agreed, I'd nak pretty heavily images/headers or the other stuff.

> but this is not something that needs to be explicitly tagged in the description data.

I'm not sure it's terribly good UX, but I've got no problem with
inline links like you suggest.

I also think it's probably a good idea to give implementations (such
as libappstream-glib, xmlb etc) some time to *ignore* the tags like
<em> that don't want to be rendered. Although you can do bold text on
a terminal (e.g. in the fwupdmgr get-details output) I don't think
it's a good idea, and bold/italic can just be ignored.

Richard.


More information about the AppStream mailing list