

Remarkable – a JavaScript Markdown and Commonmark parser - rayshan
https://github.com/jonschlinkert/remarkable

======
thristian
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.

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

~~~
hnarn
"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....](http://typographyforlawyers.com/paragraph-and-section-marks.html)

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

[http://remarkableapp.net/](http://remarkableapp.net/)

------
benatkin
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](https://github.com/jonschlinkert/remarkable/issues/34)

------
julianlam
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)

~~~
riffraff
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.

~~~
eksith
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.

~~~
riffraff
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.

~~~
eksith
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.

~~~
riffraff
> 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?

