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

Snippits containing self-closing angle bracket components break markdown parsing #360

Closed
jrowlingson opened this issue Apr 22, 2019 · 5 comments · Fixed by #384
Closed

Comments

@jrowlingson
Copy link
Contributor

No description provided.

@kpatelsecondst
Copy link

Does this workaround render self-closing brackets too?

@crixx
Copy link

crixx commented Aug 12, 2019

Any news on this or other ideas apart from using hbs?

Actually the rendering is only broken if the "custom tag" is NOT in lowercase. As soon as the tag is in lowercase, it works. Ember templates with angle-brackets ar per default camel-case, this seems to be a quite reasonable scenario 😬

@kpatelsecondst : Nope, the work around doesn't fix this.
The problem is, that after the code-block, markdown doesn't get rendered anymore - it's rendered inside the code block.

Here some examples that break the markdown parsing.

<X />

## Header
--
<X class="foo" />

## Header
--
<X class="foo" 
/>

## Header
-- 
<X
@something="something"
/>

## Header

@kpatelsecondst
Copy link

@crixx : My mistake, markdown does indeed break. The only temporary workaround would probably be to use html header tags until markdown parsing is fixed.

@barryofguilder
Copy link
Contributor

barryofguilder commented Aug 29, 2019

I think this might still be an issue. We are still seeing this for our self closing components in the demo.example component.

{{#docs-demo as |demo|}}
  {{#demo.example name="docs-icon-basic.hbs"}}
    <UiIcon @icon="rocket" />
  {{/demo.example}}

  {{demo.snippet "docs-icon-basic.hbs"}}
{{/docs-demo}}

The above code will cause any markdown headers below it to not work.

@samselikoff
Copy link
Contributor

@barryofguilder I haven't been working on this lately but best bet is probably to open a new issue.

If someone wants to help this project the most important thing is probably to triage/prioritize issues. We should prioritize bug fixes first. Octane stability I would deprioritize until it's stable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants