Isn’t that the beauty of Markdown though: that you can use it whether or not the client decides to render it prettily?

Reply to this note

Please Login to reply.

Discussion

Richly-formatted text could have lots of Markdown syntax, so any clients that don't support Markdown automatically give a worse user experience.

# `@rjk`'s thoughts on Markdown in kind 1

Admittedly, I'm not the greatest test case, as I live in a world where I see a lot of raw Markdown in plain text files and am quite accustomed to it. IMHO, "worse" is still a *graceful degradation*, with clients that supporting it providing a *progressive enhancement*. I'll point out Gruber's original intent, although perhaps we've collectively moved on:

> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

I agree, it's pretty readable as plain text *most of the time*. Links, tables, and the like get pretty messy, though.

Sure I can **use** it but it looks silly when it's not rendered properly.

what does the nip say about this in kind 1

It says markdown is not to be used, but some clients do it anyways. I don't want tables and other major things that can look messy. I just want bold, italics, and underline at minimum. Google+ had that and I've been missing it ever since Google+ shutdown.

Limited Markdown support like that would have to be defined in the Kind 1 spec.

Additional rich text formatting would be a perfect use case for a new event kind.

I don't think we need an entire new kind for it. Clients can choose to parse it and remove it or display it, like they do now.

Most interesting to me is that the markdown and HTML reference is only explicitly stated for kind 1.

Kind 0 in the same NIP may presumably have markdown or HTML or anything else needing parsed as long as its in the stringified JSON object. There are no restrictions on clients from parsing a kind 0 in this way.

Every other kind also allows HTML and Markdown and imposes no client restrictions

Rendered properly