add <em> to description markup

[hsitter]

Some upstreams would like to write a description with multiple paragraphs highlighting the key features instead of a simple feature list. To empahsis the features in the pargraphs it would be lovely if an <em> tag could be added to the supported markup for appdata descriptions.

e.g.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut nec highly-performant neque, a tempor enim. Sed at lacinia risus. Aliquam erat volutpat. Sed volutpat, lacus eu eleifend efficitur, purus nunc mattis ex, ut consequat leo turpis a orci. Donec tincidunt malesuada ultrices. Integer a commodo libero, eget feugiat nibh. Cras non dui varius, egestas nibh in, gravida odio. Praesent ultrices risus nec diam molestie fermentum. Suspendisse a condimentum elit. Suspendisse semper purus eget molestie rhoncus.

Praesent beautiful leo elementum sem mollis semper. Nunc convallis in quam at auctor. Aenean nec sagittis sem. Aenean egestas pharetra est rhoncus condimentum. Donec varius commodo libero quis vestibulum. Curabitur eget accumsan lectus. Maecenas sit amet nulla vestibulum, rutrum risus sit amet, placerat massa. Etiam facilisis, lectus in finibus auctor, erat arcu tristique massa, id tincidunt massa nunc vel tellus. Sed ac ultricies velit, dapibus tincidunt velit. Nullam tempor lorem in tellus sollicitudin, eu luctus neque auctor. Vestibulum interdum aliquam porttitor. Praesent urna arcu, cursus et purus posuere, maximus pellentesque lorem.

Duis rhoncus ligula rocketship, et pharetra diam ornare in. Quisque rhoncus, lorem non lacinia viverra, lorem arcu volutpat leo, ut ultrices magna nulla at ex. Maecenas pellentesque malesuada libero, vel semper eros cursus et. Proin vel luctus neque. Maecenas gravida elit a ex tincidunt, pulvinar rutrum quam ultrices. In ac nulla est. Suspendisse convallis augue in magna egestas, laoreet egestas nibh aliquam. Vestibulum consequat, nulla vel euismod egestas, eros turpis porta ligula, eu porta purus odio in risus. Suspendisse id orci in neque consequat venenatis. Duis et diam sit amet sem egestas tincidunt interdum vitae ipsum. Nulla sed quam nec orci luctus pretium.

[hughsie]

In the original specification this was deliberately left out to avoid upstreams just wrapping all the content in <strong> or <h1>.

[ximion]

Yeah, I must say I hate a wall of text with some fat-printed words - using bullet points for a list of key features that people want to highlight seems like a much better idea.
Having some italic text would be okay with me (and most Docbook converters also interpret the emphasis tag as italic), but even for that I think adding it just to highlight features isn't a great idea.

[hsitter]

Ultimately I think it matters little if it is bold or italic, which is why I'd go with an <em> tag to begin with. It makes no assertions about the actual style of emphasis (if any even)

As for description abuse, I hope I am not giving people bad ideas here but:

[hughsie]

UTF-8 is supported in every client that's currently parsing AppStream; to add a new XML tag is going to break validation (and possibly parsing!) on any older clients. Put bluntly: it's just not backwards compatible.

[hsitter]

The docs say "Do not assume the format is HTML. Only paragraph (p), ordered list (ol) and unordered list (ul) are supported at this time." which is surely to say that a parser implementation needs to be forward compatible by disqualifying unknown tags?

[hughsie]

What should an old parser do with:

<h1>Title</h1> -> ignore everything between h1's, rather than include the title as part of the para?
<b>important</b> -> just ignore the tags, include the text?
<a href="file://foo">See other software by the same author</a> -> ignore the entire line?

I know the description format is restrictive. It's deliberately restrictive, just like the file format of the icons, the aspect ratio of the screenshots and the text in the release notes. We designed it that way to have a cohesive software center where all apps follow the same visual style. The alternative is we let applications provide an HTML page with all their own styles, fonts, images, animations, and then we're in MySpace.

[hsitter]

I am not arguing against the restrictiveness or anything. All I am saying is that

a) the current documentation is either misleading or deliberately leaving wiggleroom
b) I know of at least one upstream who, as best I can understand basically, did <ol><li>Title</li></ol><p>...</p> so as to get a highlight of some sort (a silly looking one at that)

So considering a) either someone thought about this, or the 'at this time' ought to be dropped.
And considering b), I've made my suggestion. Do with that what you will. I am not particularly fuzzed either way.

[ximion]

@hughsie I do agree with @apachelogger on this one - new style descriptions won't validate with older AppStream versions and confuse older parsers, but that shouldn't stop us from adding them - otherwise we fall into a trap where we can not have the AppStream specification progress.

That said, if I add the <em/> tag now, it means people will only actually be able to use it properly in 6months or even a year.

[ximion]

AppStream now supports <code/> for inline code snippets and <em/> for an emphasis.
Support was added via 89d92c9, e774931 and fe2894b
These changes will be in the 0.12.8 AppStream release. Please don't use those new formatting options immediately though, because there will likely be issues with older AppStream parsers (fortunately anything that's based on libappstream will just have the formatting missing, but there may be other issues with other tools).
Thank you for your patience!