Prepare for markdown

[iamareebjamal]

Currently, the server stores raw HTML for description in various places, which is insecure and difficult to show on mobile devices. Also, rich content based on HTML is always a bad idea since supported things can change and not every HTML element is feasible.

The plan is to get rid of all HTML from the server and change it to markdown. This will be done on incremental basis starting with posts with no HTML content and content with HTML will be converted to restricted MarkDown, which will also make it easier for the frontend to make a rich text editor.

For markdown content, a special field is_markdown will be added for markdown content and is_raw_html for posts with raw HTML.

By default, is_markdown will be false and the latter will be true for all content. Later, is_raw_html will be deprecated, and frontend will have to show escaped text by default when all markdown conversion is complete.

This makes easier for us to not run into XSS problems. So, if the content returned from API is <p>Hello</p> with is_raw_html false, it should be shown with the tags, and not just hello

is_markdown will only be true for text with rich content. For example, bold, italics, etc. So, it will be disabled for all simple content. For frontend and mobile, a flag is_markdown needs to be sent while creating content so that it is optional and not necessary to implement rich text editor for the client, and this flag will be reflected in the fetched API making the consumers show/ not show it as markdown.

So, three scenarios are: is_mardown (default: false) -> render markdown is_raw_html (default: true) -> Show using inner HTML without scaping (To be deprecated) else -> Plain Text, show woth escaping (default in future)

This is a design proposal and discussion on it with suggestions and counter-arguments and welcome.

Same proposal to be shared in frontend, server and mobile

[kushthedude]

@iamareebjamal This is major change in our webApp and would require more time and work force , How are we planning to make it

[iamareebjamal]

This is literally the first step, a proposal. There is no guarantee that this will even go through or be accepted. And even after being accepted, depending on priority of other issues, may not be implemented completely this GSoC, we'll see. However, I don't see it that big of a change. Implementing a rich text editor is not mandatory for this issue, just handling non-html data from server is important, because it is most definitely going away soon. Many problems on mobile because of it.

[uds5501]

@iamareebjamal I wanted to see if I understood what you are proposing so I will be taking an example of Event Description. Kindly correct me anywhere when I am wrong.

As a user, if I enter: "This is going to be a great event" , then it will be regarded as a simple text and will be initialised with: is_raw_html=True and is_markdown=False and it will be handled by our API as such.

But if I enter "This is going to be a great event ", our server which currently stores it as : This is going to be a <strong>great</strong> event with is_raw_html=True will change to a parsed markdown format as This is going to be a **great** event with is_raw_html=False and is_markdown=True

And in the future, we shall be parsing all such data in rich text format in itself. Right?

[kushthedude]

@uds5501 , I think what you wrote is more or less correct as Raw HTML will be handled by is_raw_html and only rich text format is to be supported by an additional field added is_markdown

[iamareebjamal]

"This is going to be a great event", is_raw_html will be False