I'm planning on including Markdown in a ing project. In the past, I've just used a pre-packaged server-side Markdown parser, re-sanitized the HTML output (an unnecessary step?) and shipped it off to the client.

I'm interested in offloading at least this portion of the view rendering to the client. I've used client-side Javascript Markdown parsers with great success in Rails applications before. I'd delegate the body object to watch for DOM insertions of class markdown-parseme or the like and then to parse it and replace the original text with the result.

But this is the first time I'm considering it for an in-the-wild production site. What are the gotchas and security concerns when letting the client handle Markdown rendering? Are there any specific libraries that take these issues into account?

EDIT: the obvious concern that springs to mind is "what about those without Javascript". It is perfectly within our capabilities to detect browsers that don't have Javascript enabled and to implement a mechanism that will allow clients to (perhaps manually) flag that they don't have JS and to move parsing to the server side. I would very much like to investigate if there are serious issues with offloading Markdown parsing to the client beyond this ordinary question of patibility. Rendering a decently-sized page without output caching is adding a non-negligible amount to the response time and through that, the server load, and it would be nice if we could be confident in moving that task off the server for 95% of users.

I'm planning on including Markdown in a ing project. In the past, I've just used a pre-packaged server-side Markdown parser, re-sanitized the HTML output (an unnecessary step?) and shipped it off to the client.

I'm interested in offloading at least this portion of the view rendering to the client. I've used client-side Javascript Markdown parsers with great success in Rails applications before. I'd delegate the body object to watch for DOM insertions of class markdown-parseme or the like and then to parse it and replace the original text with the result.

But this is the first time I'm considering it for an in-the-wild production site. What are the gotchas and security concerns when letting the client handle Markdown rendering? Are there any specific libraries that take these issues into account?

EDIT: the obvious concern that springs to mind is "what about those without Javascript". It is perfectly within our capabilities to detect browsers that don't have Javascript enabled and to implement a mechanism that will allow clients to (perhaps manually) flag that they don't have JS and to move parsing to the server side. I would very much like to investigate if there are serious issues with offloading Markdown parsing to the client beyond this ordinary question of patibility. Rendering a decently-sized page without output caching is adding a non-negligible amount to the response time and through that, the server load, and it would be nice if we could be confident in moving that task off the server for 95% of users.

• javascript
• ruby-on-rails
• markdown

• Why the move to the client? Just to save yourself the AJAX call? – sdleihssirhc Commented Jan 24, 2011 at 21:08
• An obvious problem is making it mandatory to have JavaScript enabled. – R. Martinho Fernandes Commented Jan 24, 2011 at 21:08
• 3 For a lot of web applications, lack of JavaScript means you're either not using the application in the first place, or else that you're using what amounts to a pletely different application. – Pointy Commented Jan 24, 2011 at 21:13
• I think that if you're using a Markdown solution that runs in the client while people enter the content, then a big advantage for doing the rendering in the client too is that you pretty much guarantee patibility between edit-time and view-time. – Pointy Commented Jan 24, 2011 at 21:15
• @Stephen: SOUF? My Google Fu fails me. – Steven Commented Jan 24, 2011 at 21:32

3 Answers 3

Nowadays, most people use javascript, so this shouldn't be a problem. The showdown library is great for client side rendering.

The assumption that the client is capable of parsing Markdown syntax might be incorrect (at least for some people and for search engines). If you provide theses groups with a server-parsed version, you duplicate code. The server usually has more powerful tools to prevent XSS and the like (because that is what servers do: generate HTML from user content in a safe way).

markdown-js isn't finished yet but it's a JavaScript library for a subset of markdown that uses an AST rather than different stages of HTML conversion. It should produce sane HTML right from the start. I think that this approach, if executed properly, will make rendering markdown on the client side practical.

It intentionally doesn't support embedded HTML.