[Mixed content]: Consolidate issues

[joshbruce]

Issues related to processing HTML with Markdown inside. See #956

[Feder1co5oave]

Todo list for html content (WIP)

toward next patch:

• marked 0.3.14 hangs on the attached file, worked in 0.3.9 #1058 catastrophic backtracking

toward 0.4.0 (no defects):

• .

[mapmeld]

(I've just noticed this more-or-less a duplicate of #488)

Can I add a new issue on to HTML parsing? I noticed that InlineLexer handles Markdown inside of HTML and supports a limited set of Markdown (links work, lists don't).

When I am writing Markdown for internationalization projects, I sometimes use a dir="rtl" div to hack around a presumed RTL layout, like this:

<div dir="rtl">

   * list item 1
   * list item 2

</div>

With careful use of whitespace, this markdown list appears correctly right-aligned on GitHub:

• list item 1
• list item 2

Ideally MarkedJS would either support Markdown lists inside of a div, or stop using two different parsers for the inside and outside of an HTML block

[joshbruce]

@mapmeld: Recommend creating a new issue entirely. Would also say that I'm not sure how CommonMark an GFM specifications actually handle this situation.

I believe the "careful use of whitespace" hack works because their parser looks at empty line separations as the indicator for parsing. So, the empty line tells the GitHub parser to go ahead and create the <ul>. See also #1047 and #985

[joshbruce]

@mapmeld: Having said that, I'm curious and would like to confirm...the letters aren't reversed because English is not an RTL language?? If so, do you change the language of the Markdown as well for the internationalization??

[mapmeld]

@joshbruce browsers are usually good at figuring out how to show a mix of LTR and RTL content. It's not a problem of showing English or Arabic letters or words in the wrong order, only issues with text layout. I'm using English in this issue as an Arabic example might make it confusing what I am trying to do.

If there were an option to parse markdown inside of HTML (#488) then my examples would be OK

The dir="rtl" attribute specifies an RTL layout which affects how the browser puts elements in order and formats lists. Not so important here, but it also affects how you see punctuation such as question marks, hashtags, and parentheses

1. This sentence ends with a question mark?
2. #startsWithAHashtag
3. Open paren (
4. Close paren )

[joshbruce]

@mapmeld: Thanks for the clarification. Think I'm trying to make sure we're not maybe trying to get Markdown and marked to do something they shouldn't...we got a lot of that already. :)

Why not use CSS (one for LTR languages, then override with a second for RTL languages), for example? https://css-tricks.com/almanac/properties/d/direction/ - cleans up the Markdown to make it less HTML specific.

Telling us how the specifications define and deal is usually the easiest way to make requests right now - we're really trying to not make up our own requirements when it comes to functionality right now.

CommonMark does specify HTML (div specifically) followed by an empty line is an end condition for ignoring HTML content (see 6 and 7); so, depends on what can be done with regex, I think: http://spec.commonmark.org/0.28/#html-blocks

Probably worth creating a new issue, which @Feder1co5oave or myself or one of the other contributors will then associate with this or something else.

[mapmeld]

@joshbruce agreed, I don't want to overcomplicate the library. I added a test and tried out dividing the html rule into htmlstart, htmlend, and htmlcomment rules - currently only one test is having issues with the change. I'd need help fixing the RegEx for paragraphs so it doesn't extend into the HTML tag on the same line mapmeld@a8df1aa