Because it could be improperly tagged, or be combined with other tags that change the context to something the viewer doesn't mind seeing.

Disclaimer: I don't view cub porn at all. I have no interest in it.

That said, lLet me give this argument: Why ban it when the entire topic can be blacklisted on a user level? Why force such rules on everyone when users can opt into not seeing any of it, perhaps by enforcing that cub porn be tagged with very specific tags?

From a purely objective point of view, this problem was handled quite well by SoFurry, Weasyl, and InkBunny. They make it trivial to block any unwanted content, and also do so here as well.

This is honestly a purely subjective argument, but it wouldn't surprise me if FN eventually banned cub porn due to overwhelming requests to do so.

Okay, first of all, how did FN admins allow for that username to be registered here? O_o;

Second, while I'm not defending it, I will ask you to explain why it should be banned. Not "it is wrong" or "it's immoral", as that's a highly subjective topic that'll cause an eternal back-and-forth. Give good reasons with explanations to back them up.

You're wanting fine-tuned word processing tools to display potentially hard-coded font sizes on a medium which has to adapt to multiple screen resolutions, including mobile phones. Even without Markdown, that's an absolute nightmare for readers on mobile--a complaint I raised multiple times on SoFurry in the past.

At most, what would make it better is a set of defined tools and stylesheets using something like BBCode (even though I despise BBCode), or a subset of HTML, allowing for limited rich text capabilities. Giving too much to the writer either makes for a horrible reading experience outside of larger devices, or can make stories unreadable as a whole (see also: many stories on SoFurry).

Another option would be to give full formatting to the writer, then make it so that stories can be reported as "unreadable on mobile" to alert the writer to problems. At that point, it would be all on the writer to make sure their stories are formatted properly for their readers.

As someone who's tried dealing with this exact issue on a web design level, it's not easy making something typed in Word/Scrivener/et. al. readable on a mobile device, especially if it's rendered exactly like it would be on a larger screen. Not without scaling issues that make you pull your hair out.

Typography in a fluid digital medium is a massive pain.

That's not Markdown's fault. The fault is with the rendering settings and resulting stylesheet.

Personally, I'd like to see journals separated from social update posts. It would definitely benefit a lot of people if they could have both, since social updates can be a quick message, while a journal takes a lot more thought before posting.

Unfortunately, that is a problem. There are dozens of flavors of Markdown, some with their own exclusive features. There are also some general Markdown features that are slightly broken here, such as the use of @ and # in mentions and hashtags respectively, and HTML parsing is disabled as I recall (which breaks the MD standard). There really needs to be a solidified reference for FN's flavor of Markdown.

http://support.furrynetwork.com/topics/86-let-us-have-animated-icons/

It's planned as a feature after the official launch. :)

I'll copy/paste what I mentioned elsewhere as to why I would be against inline HTML for stories, and add a bit more.

I can definitely understand why inline HTML is disallowed, though. On an the actual site, allowing it could easily open up security vulnerabilities, which is the last thing that the site needs. Even with sanitation, something can slip through.

Using tables to try and replicate typesetting for hectic conversations is also very poor form for the web, as it has the chance to derail accessibility for anyone who uses a screen reader for text-to-speech. For edge cases like this, I'd rather see something like PDF support for the site, or perhaps even LaTeX support, and just have the user handle it outside of the more vulnerable embedded code of the site.

As far as actual tables, I would definitely back having MultiMarkdown for stories, but that would make it awkward for the site itself. I'm fairly certain that having the more advanced features of MMD--like tables and footnotes--suddenly find their way into the normal posts would cause a bit of havoc. The backend might need both the current system and MMD for that sort of issue, and that could complicate things.

(Disclaimer: I'm an amateur web designer, and web standards evangelist, so this sort of topic is something I keep myself immersed in.)

I can definitely understand why inline HTML is disallowed, though. On an actual site, allowing it could easily open up security vulnerabilities, which is the last thing that the site needs. Even with sanitation, something can slip through.