Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

markdown: explicitly say whether GFM is supported #361

Open
ee7 opened this issue Jun 30, 2022 · 6 comments
Open

markdown: explicitly say whether GFM is supported #361

ee7 opened this issue Jun 30, 2022 · 6 comments

Comments

@ee7
Copy link
Member

ee7 commented Jun 30, 2022

I believe that the website uses commonmarker (see here), which is the wrapper for libcmark-gfm. And therefore the website supports rendering a markdown file that uses GitHub Flavored Markdown features.

However, the Exercism Markdown spec does not state whether a Markdown file can use GFM features. We should state that explicitly, so that e.g. a track knows whether they can use a tables, task list items, or strikethroughs.

Configlet will soon learn to parse and render Markdown, but this will at least initially only support the CommonMark 0.30 spec (not GFM). If necessary, it should be straightforward for it to support GFM (by wrapping libcmark-gfm, rather than libcmark).

Somewhat related:
GitHub is thinking about adding a new admonition syntax. See https://talk.commonmark.org/t/4173

But even if the GFM spec is changed, I would suggest that we keep the current admonition syntax:

All blocks are written using 4 tildes, in the form of:

~~~~exercism/note 
Content goes here 
 
You can include code: 
```ruby 
str = "Hello, World" 
``` 
~~~~ 

(Note: You may also use backticks or other levels of tildes in exceptional circumstances)

@ErikSchierboom
Copy link
Member

FYI The additional rendering options that we support are footnotes and allowing unsafe HTML: https://github.com/gjtorikian/commonmarker#render-options

@ee7
Copy link
Member Author

ee7 commented Jul 4, 2022

@ErikSchierboom
Copy link
Member

Do we support tables and strikethrough too?

Yes.

What's the rationale behind using UNSAFE? And how does it interact with tagfilter?

@iHiD?

@iHiD
Copy link
Member

iHiD commented Jul 6, 2022

No idea. I guess we trust maintainers' code and allow them to do whatever?

@ErikSchierboom
Copy link
Member

🤷

@ee7
Copy link
Member Author

ee7 commented Oct 25, 2022

I'd probably lean towards:

  • If there's no real reasonable basis for rendering unsafe HTML in markdown from Exercism track repos, stop doing that. This helps minimize the extent to which the security of the website is dependent on reviewers catching potentially subtle security issues, right? Or do we see legitimate uses for things like <iframe> and <script>?
  • Regardless, we should have a markdownlint workflow in org-wide-files (tracked in consider adding org-wide markdownlint workflow org-wide-files#214) eventually anyway.
  • Then we can configure that workflow to produce an error for unsafe HTML. If we keep allowing it, perhaps that markdownlint error could be disabled on a repo-by-repo basis, with its configuration requiring @exercism/maintainers-admin approval.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants