list items without parents are allowed in new replies

[einkoro]

input:

123 
<li>test

output:

<p>123</p>
<li>test</li>

Editing the posts afterwards corrects it when converting to markdown.

To me this seems like it should be a bug upstream and handled by balanceTags but it only goes so far as to make sure the <li> is closed.

[stephenharris]

I get this too (Though my browser "correctly" renders it).

I'm not sure what the correct behaviour should be. Incomplete/erroneous HTML cannot be reflected in markdown so when the incorrect HTML is edited, something will change. I suppose ensuring that any HTML generated from the user's input is valid could be possible... A good comparison is the tinyMCE editor. Typing the above in the HTML tab and switching to Visual and back again, corrects the HTML. So perhaps some sort of equivalent function in php could be run after wpmarkdown_markdown_to_html()?

Do you know of an existing solution for this? I'd be wary about using one that isn't already well-tested because it may ending up mutilating people's content.

[einkoro]

Off hand I'm not familiar with any – the last time I had to address this problem I rolled my own xhtml parser / validator in perl. The TinyMCE comparison concerns me since that requires javascript – we could do something like that in the editor I'm sure (or use a different editor that does it) but performing the sanitization/validation on the backend is preferable. I was considering changing the markdown parser to parsedown in a pull request – I could look into that and see if it handles it correctly – main issue with that is I didn't find anything for going from html back to parse down.

[stephenharris]

I drew the comparison with TinyMCE only to as indicator of what would be "reasonable" (in terms of HTML validation) for wp-markdown to do. Of course any validation would be run server-side.

Feel free to test out parsedown. If it addresses issues that PHP Markdown doesn't (and doesn't create a new ones), then I'd be happy to swap it out. But I don't think either the markdown to HTML or HTML to markdown parser are doing anything in this case, I think its a fundamental limitation of swapping between the two.

main issue with that is I didn't find anything for going from html back to parse down.

Parsedown is just markdown (parser) right? In which this is a non-issue - markdownify would suffice.

[einkoro]

Parsedown inplements github markdown in addition to markdown extra.

Would you be against storing the markdown in addition to the HTML for posts? This would eliminate any need for a function to go between the two and as an upside make any chance of inconsistency go away. I think this is what jetpack's markdown module is doing.

On May 31, 2014, at 16:15, Stephen Harris notifications@github.com wrote:

I drew the comparison with TinyMCE only to as indicator of what would be "reasonable" (in terms of HTML validation) for wp-markdown to do. Of course any validation would be run server-side.

Feel free to test out parsedown. If it addresses issues that PHP Markdown doesn't (and doesn't create a new ones), then I'd be happy to swap it out. But I don't think either the markdown to HTML or HTML to markdown parser are doing anything in this case, I think its a fundamental limitation of swapping between the two.

main issue with that is I didn't find anything for going from html back to parse down.

Parsedown is just markdown (parser) right? In which this is a non-issue - markdownify would suffice.

—
Reply to this email directly or view it on GitHub.

[stephenharris]

Would you be against storing the markdown in addition to the HTML for posts?

In does provide better stability, but the reason I went down the route of passing between HTML and markdown is that this method is not possible with comments, and I wanted to have one consistent approach for posts (pages etc), bbPress and comments. Additionally, I quite like that it tidies up my markdown :). Finally it also means exists posts can be edited in markdown.

That said, if you want to create a constant which can be set in wp-config.php (and perhaps if there's demand a GUI option) which toggles this behaviour: i.e. convert HTML to markdown or store entered markdown, then I'd be open to that. In the case of the stored markdown not being found (for whatever reason) you could revert to the original method of converting the HTML to markdown.