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

Prevent from parsing inside custom elements #1090

Closed
intcreator opened this issue Feb 27, 2018 · 6 comments · Fixed by #1135
Closed

Prevent from parsing inside custom elements #1090

intcreator opened this issue Feb 27, 2018 · 6 comments · Fixed by #1135

Comments

@intcreator
Copy link

Expectation

If I have a custom element in my Markdown, the contents should not be parsed:

<demo-el>
    <template>
        <script>
            let death = 'backticks';
            console.log(`backticks are ${death}`;
        </script>
    </template>
</demo-el>

Should produce backticks are backticks in the console and my custom element rendered as normal in the Markdown.

Result

The following code actually produces <code>backticks are ${death}</code> in the rendered Markdown and an error in the console (because it cannot recognize <).

What was attempted

I tried to find which elements are considered block elements in Marked.js to prevent this from happening, but it was not clear how this was decided.

@Feder1co5oave
Copy link
Contributor

Feder1co5oave commented Feb 27, 2018

I can see that this is annoying for you. The inside parsing of html elements was considered often a nice thing to have but it can mess up things.
It's definitely gonna be revisited this once everything is up to date with commonmark about html blocks.

#985

@Feder1co5oave Feder1co5oave added this to the 0.4.0 - No known defects milestone Feb 27, 2018
@intcreator
Copy link
Author

It looks like it's a violation of Example 156 in the Commonmark spec.

What do you mean by everything being up to date? How long do you think it will be? Can I help?

@joshbruce
Copy link
Member

@intcreator: My throwing copper on the "can I help?" - Yes. Absolutely. Always. There aren't a lot of us to go around who actually know marked well enough to contribute code (we're working on discussing how to get there in other issues); so, the more outside contributors who can fix issues with the core, the more the core team of committers, such as it is at the moment, can focus on making it easier to maintain and contribute to for others.

Please see updated readme and contributing pages.

Let me know if there's something you think could be helpful in the docs.

@joshbruce joshbruce removed this from the 0.4.0 - No known defects milestone Apr 4, 2018
@yzhang-gh
Copy link

Hi, sorry to disturb you. I have read the comments in the relevant issues (#985, #1135) but still cannot find the answer to the original question asked by @intcreator

I tried to find which elements are considered block elements in Marked.js to prevent this from happening, but it was not clear how this was decided.

As I found, text inside <div> is not parsed as Markdown but text inside <p> is. How is this behavior decided? Can I configure it?

Thanks in advance.

@UziTech
Copy link
Member

UziTech commented Aug 7, 2018

How is this behavior decided?

You can read the spec here. marked doesn't fully comply with the spec yet, but that is where we are heading.

Can I configure it?

You can extend the renderer or parser to change the behavior of marked.

@yzhang-gh
Copy link

Exactly the answer I need, thanks a lot!

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.

5 participants