What (if any) HTML should we allow in posts?

especially if you choose an implementation which supports plugins

1 Like

I’d like to echo other here. The thing missing from stack exchange markdown that used html for was superscript (and math, of course, but we’re talking about that elsewhere).

2 Likes

IMO what’s more immediately important for this use case isn’t, “What can I do with HTML that I can’t already do with Markdown?”

What is more important, the chief reason for supporting some HTML, even if it’s no additional formatting than you already do with Markdown, is interop – interop with users who prefer to write (using that subset of) HTML; and interop with existing data (e.g. SE posts) some of which might already include some HTML.

Badly-scraped data looks horrible to me, very second-hand, so I find compelling the fact that SE supports HTML.

3 Likes

This isn’t in the default Markdown stuff, but was introduced by SO and GitHub (independently, IIRC, though around the same time). I think using one of the modern successors, such as Github Flavored Markdown, would be the best route to go, because having code fencing is a pretty basic requirement.

Oh! One thing to remember: make sure the editor (whatever’s chosen) supports easily displaying HTML, like for answering questions about HTML. I’ve seen editors where I had to jump through absurd hoops to get HTML to display (usually having to encode all of the tags myself). At the very least, tags within fencing should be auto-escaped on save/manipulation and allowed to be put in literally in the editor itself (so you don’t have all the escape codes if you go to edit the entry).

7 Likes

Discord currently shows a preview of words when they’re being formatted, e.g:

`code here`
**bold**
*italic*

I don’t know how hard this would be to implement, but it would be super cool to have.

2 Likes

SE’s markdown editor is open source, so in theory implementing “preview” is trivial (i.e. it’s copy-and-paste an existing implementation). However it might be the project’s policy to reinvent the wheel[s], or maybe there’s some issue around formal testing or something, I don’t know, or project management or building some consensus, that makes it non-trivial.

That (SE) open source includes the preview, HTML filtering, and the toolbar – I used it here for example, https://react-forum2.herokuapp.com/discussions/new – but it doesn’t include that tag selector component, nor the “drag and drop an image to upload it” which is currently present on SE.

Of course the HTML must be filtered on the server too. I suppose there are other open source markdown editors too.

1 Like

I wouldn’t consider using CommonMark as reinventing the wheel. Quite the opposite; AFAICT CommonMark is the closest to a Markdown standard that exists.

2 Likes

While that’s certainly true, I believe @cwellsx was referring to the implementation, not the choice of standard. There are at least two fairly up-to-date .NET implementations that might be useful, as well as half a dozen in JS.

4 Likes

Yes, implementation not spec – saying that if there’s a suitable implementation already, then that’s not so hard to implement.

1 Like