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

Unexpected behaviour of components when immediately prepended by GFMD #958

Closed
ang-zeyu opened this issue Dec 20, 2019 · 2 comments · Fixed by #1548
Closed

Unexpected behaviour of components when immediately prepended by GFMD #958

ang-zeyu opened this issue Dec 20, 2019 · 2 comments · Fixed by #1548

Comments

@ang-zeyu
Copy link
Contributor

ang-zeyu commented Dec 20, 2019

Tell us about your environment

  • MarkBind Version: 2.70
  • also tested on the latest master, briefly

What did you do? Please include the actual source code causing the issue.

In general, any markdown + html with the following format causes the issue

markdown pre text **immediately** prepending a component, without an empty line after
<box or panel>
line 1 which behaves as per normal ( empty line still counts )
--empty line--
lines 3 onward are 'placed' outside of the component
...
...
</box or panel>

Only tested with box and panels, since that is likely the only places multiple paragraphs would be used.

Exceptions for the markdown pre text ( as far as I have found, exhaustively tested from this list https://markbind.org/userGuide/formattingContents.html ):

  • markdown headings ( # ... )
  • code blocks ( ... )
  • markdown tables
  • video embeds ( but the video disappears, leaving the link remaining instead )
  • lists / blockquotes without content ( e.g. > does not produce the issue but > some text does. )

Example 1 (boxes):

example1

Example 2 (panels):

example2

What did you expect to happen?

The multiple paragraphs should be chucked into the component itself, like so

Example 2: ( result achieved by leaving an empty line between the pre text and component )
expected2

What actually happened? Please include the actual, raw output.

The subsequent paragraphs after the first are appended after the component

Example 1:
result1

Example 2:
result2

@ang-zeyu ang-zeyu changed the title Unexpected behaviour of components with multiple paragraphs when prepended by GFMD Components prepended by GFMD Dec 20, 2019
@ang-zeyu ang-zeyu changed the title Components prepended by GFMD Unexpected behaviour of components when immediately prepended by GFMD Dec 20, 2019
@wxwxwxwx9 wxwxwxwx9 mentioned this issue Apr 16, 2021
10 tasks
@wxwxwxwx9
Copy link
Contributor

wxwxwxwx9 commented Apr 16, 2021

@ang-zeyu I've looked into this issue and here's what I discovered so far.

From my investigation, the problem stems from markdown-it parsing.

Using your example, refer to here to see how it is parsed by markdown-it in MarkBind currently. Note that the html checkbox on the website is ticked because that's the setting we are using in MarkBind currently (as shown below).

Screen Shot 2021-04-16 at 4 19 30 PM

Due to the way markdown-it parses that block of code, you can see that the behaviour of lines 3 onward are 'placed' outside of the component occurs. You can use html beautifier on the markdown parsing output to see the outcome more clearly.

Now, if we were to change panel in the source code to div, we would see that we achieve the html structure outcome that we would expect for panel, that would not lead to the lines 3 onward are 'placed' outside of the component problem.

And that is because markdown-it automatically closes the first <p> tag as <div> tag cannot be nested within <p> tag. Since <panel> would not get the same treatment as <div> (as <panel> is a custom element), the problem of lines 3 onward are 'placed' outside of the component then occurs.

It seems like we will have to patch markdown-it somehow to get it to recognize some of our custom tags (e.g. box) as a block-level element so that this can be resolved.

Just wanted to share my findings with you before I go ahead with a patch, in case you have any ideas / advice.

What do you think? :-)

@ang-zeyu
Copy link
Contributor Author

yup, we might also reference vuepress' solution for this. (though, be careful with <panel>s in particular as mentioned #1534 (review))

ang-zeyu pushed a commit that referenced this issue Apr 21, 2021
We have never defined the behavior of our custom components as html
tags (whether block-level or inline) in markdown parsing. 
This causes some undesirable edge cases during markdown parsing, as
raised up in #958.

Let's adopt the way VuePress define the behaviour for custom components
and adapt it to fit our needs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants