Remarkable – a JavaScript Markdown and Commonmark parser | Hacker News Reader

Remarkable – a JavaScript Markdown and Commonmark parser

github.com

50 pointsrayshan11 comments

A minor nitpick: under the heading "Typographer", apparently setting "paragraph: true" causes "(p)" to be replaced with "§". That's Unicode U+00A7 SECTION SIGN (and it represents a stylised pair of "S" characters), the traditional character for marking a paragraph break is "¶" U+00B6 PILCROW SIGN.

In Danish (and probably others) "paragraph" ("paragraf") usually refers to a section of a law text and uses the "§" symbol.

"The paragraph mark ( ¶ ) is used when citing documents with sequentially numbered paragraphs (e.g., declarations or complaints). The section mark ( § ) is used when citing documents with numbered or lettered sections (e.g., statutes)."

http://typographyforlawyers.com/paragraph-and-section-marks....

Awesome project! Just an FYI, your project shares a name with Linux Desktop Markdown Editor

http://remarkableapp.net/

Looks great! This project shows why we need CommonMark. I want a CommonMark vim syntax. :)

Upvoted to help with this issue: https://github.com/jonschlinkert/remarkable/issues/34

Well done :) | Just a note that NodeBB recently switched away from chjj/marked to jonschlinkert/remarkable due to its more robust API and better security (at least from the limited tests we've run)

how is the security better? Is there a "safe markdown" test suite?

EDIT: a ton of projects allow users to write markdown, but markdown allows, for example, raw html, which means letting a user input "full markdown" means leaving a gaping security hole. The CommonMark spec does not seem to consider the issue at all, but it seems like it should.

All user input should go through some manner of filter regardless of the presented form. After all, it doesn't take too much effort to send raw post data without loading the page at all.

I disagree, but maybe I am not understanding what you mean.

If the presented form is "plain text" then encoding all html tags is an effective choice, if the presented form is "rich text" than tag/attribute whitelisting is necessary and you need to strip "bad stuff".

The choice of presentation, combined with the choice of who is inputting the data, also poses problems in the UX, i.e. if you use a JS markdown editor in the browser and process data in python on the server stripping HTML than the user sees something going in and something else going out.

A common standard of how to do safe markdown would help.

By filter, I meant server-side sanitization. Stripping "bad stuff" as you put it should be mandatory regardless. Someone can simply craft a raw post to the "action" URL of the form (the handler) without loading the page at all.

As for client-side, the user has an expectation that what was entered into the form will be the end result, but this expectation is easy to meet for a vast majority of users. The edge cases tend to be solved most of the time with a live preview that also closely matches the server-side stripping of invalid/malformed content.

When no JS is available/enabled, a preview button before final submission (a la Slashdot) is usually a good idea.

> Stripping "bad stuff" as you put it should be mandatory regardless. Someone can simply craft a raw post to the "action" URL of the form (the handler) without loading the page at all.

The second sentence is irrelevant, I am not assuming javascript checks, I already know user input is untrusted.

But the first is, AFAICT, wrong: If I escape correctly all user input before using it, I don't need to strip anything (unless I want to let some HTML through). If you think escaping input is not enough, could you give me an example?

Reply on news.ycombinator.com