[AppStream] Additional markup support in descriptions

[Robert Ancell]

On Mon, Jul 29, 2019 at 11:07 AM Matthias Klumpp <matthias at tenstral.net>
wrote:

> Am So., 28. Juli 2019 um 20:29 Uhr schrieb Richard Hughes <
> hughsient at gmail.com>:
> >
> > On Sun, 28 Jul 2019 at 07:47, Robert Ancell <robert.ancell at canonical.com>
> wrote:
> > > I guess that would mean supporting both <code> and <pre>.
> >
> > I think various things would break trying to support <pre> -- a lot of
> > current and legacy tools that import and export AppStream assume that
> > XML whitespace isn't important. My vote would be to add <code>, <em>
> > and <strong> and leave it at that.
>
> The reason why I was asking about whether <code/> meant a code-block
> or a single-line markup was more about the intent of Robert for how
> this should be used. Diverging from HTML makes not much sense, as that
> would yield unexpected results. Aligning with Mallard or Docbook XML
> is the one thing that could also make sense (but not inventing our own
> stuff).
>
> +1 from me for <code/> and <em/> as they were discussed here (I
> already have a commit to add <em/>, but libappstream currently has a
> bunch of validator changes staged that I want to land first). I am
> unsure about <strong/> (wouldn't that just be visual clutter?) and
> especially about code blocks. The thing I want to avoid is the
> description texts becoming manual pages or detailed instructions with
> code examples, as README.md files often are. Allowing code blocks may
> make it more likely that descriptions will become instructions.
>
>
What's the next step here; should I make an MR for <code/> to be added to
the specification?

I figure this discussion would have worked better as a GitHub issue? It
might be worth opening issues for <strong/> and <pre/> so we have a better
record of the reasoning for/against.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/appstream/attachments/20190731/71c34f74/attachment.html>