Considering detailed description text

[fluffy-critter]

Simon Repp raised some valid concerns regarding detailed descriptions over on Mastodon and it's worth tracking the conversation here.

[fluffy-critter]

Here is my attempt at summarizing the main points Simon made in the thread (forgive me if I missed something):

• Specifying description as being "just HTML" and leaving it up to the implementation for what to allow is problematic
• It's unclear to him what the purpose of including rich descriptions is to begin with, and he's concerned about both presentational aspects and perceived data bloat, particularly for mobile clients

My thoughts on this:

• Detailed description text is nice to provide for clients which are able to present it, but it's also not a requirement that clients are able to present it
• Including some sort of rich formatting is super important, as just doing text-with-paragraphs isn't sufficient when it comes to things like detailed liner notes for a song
• The bandwidth requirements of even a huge description are much lesser than even a small audio track
• This format isn't meant for live browsing of musical content directly from a player device, it's for syndication of library content that's to be made available in some pre-digested way to the end player, and this can (and IMO should) include whatever "liner notes" or other detailed description text are made available as part of the library

I'm waffling between whether a Markdown subset or an HTML subset is the better way to go. I feel like Markdown is easier to specify but more complicated to actually support, especially with content publishing platforms that only handle HTML or which cannot easily provide the underlying Markdown.

But I do feel that this is something that should be made available to clients that want to present it. Maybe it's out of misplaced nostalgia for picking up a vinyl record or a CD and having stuff to read and look at while listening to it on my hifi system, but IMO it's better to allow for this rich presentation, and if such a thing exists, it should be specified well enough that there aren't major disagreements about how the data should be formatted.

And, being that this is a specification, it should err on the side of being specific.

[fluffy-critter]

A point against having a detailed description is that there's already a url field which is meant to be the web-native representation of the content, and rich display could be in the form of the client presenting a webview or a "reader mode" display of that URL.

There's also having an appropriate link rel of notes or something, which would probably be a cleaner way of handling this.

[fluffy-critter]

I think for now I'll remove description from the draft spec and defer until later.