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

[Mixed content]: Consolidate issues #985

Closed
joshbruce opened this issue Dec 25, 2017 · 7 comments
Closed

[Mixed content]: Consolidate issues #985

joshbruce opened this issue Dec 25, 2017 · 7 comments
Labels
category: mixed content epic A large goal or objective for a major release.
Milestone

Comments

@joshbruce
Copy link
Member

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

@joshbruce joshbruce added the L2 - annoying Similar to L1 - broken but there is a known workaround available for the issue label Dec 25, 2017
@joshbruce joshbruce added this to the 0.4.0 - No known defects milestone Dec 25, 2017
@Feder1co5oave
Copy link
Contributor

Feder1co5oave commented Feb 23, 2018

Todo list for html content (WIP)

toward next patch:

toward 0.4.0 (no defects):

  • .

@mapmeld
Copy link

mapmeld commented Feb 25, 2018

(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
Copy link
Member Author

@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
Copy link
Member Author

@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
Copy link

mapmeld commented Feb 25, 2018

@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
Copy link
Member Author

joshbruce commented Feb 25, 2018

@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
Copy link

mapmeld commented Feb 25, 2018

@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

@joshbruce joshbruce added the good first issue Something easy to get started with label Feb 28, 2018
@joshbruce joshbruce removed this from the 0.4.0 - No known defects milestone Apr 4, 2018
@joshbruce joshbruce added epic A large goal or objective for a major release. and removed L2 - annoying Similar to L1 - broken but there is a known workaround available for the issue labels Apr 4, 2018
@joshbruce joshbruce added this to the v0.x milestone Apr 4, 2018
@joshbruce joshbruce removed the good first issue Something easy to get started with label Apr 9, 2018
@UziTech UziTech closed this as completed Dec 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: mixed content epic A large goal or objective for a major release.
Projects
None yet
Development

No branches or pull requests

4 participants