Custom Elements / Web Components with specific attributes cause the markdown renderer to break

[KonnorRogers]

Astro Info

~/projects/github-rfy1xs-ea1byz 5s
❯ npx astro info
Astro                    v4.1.3
Node                     v18.18.0
System                   Linux (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             @astrojs/starlight

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

When you use a custom element that looks like this:

<sl-input label="Playback Rate" min="1" step="0.25" max="3" value="1"  type="number"></sl-input>

EDIT: specifically this seems to be the problem:

<sl-input value="1" type="number"></sl-input>

inside of a .md file, the markdown rendering pipeline results in a unhandled rejection.

Stack Trace:

15:12:14 [ERROR] [UnhandledRejection] Astro detected an unhandled rejection. Here's the stack trace:
Error: Cannot compile unknown node `number`
    at Module.unknown (/home/projects/github-rfy1xs-ea1byz/node_modules/hast-util-to-html/lib/handle/index.js:63:9)
    at Module.one (/home/projects/github-rfy1xs-ea1byz/node_modules/zwitch/index.js:121:17)
    at Object.one (/home/projects/github-rfy1xs-ea1byz/node_modules/hast-util-to-html/lib/index.js:254:27)
    at Object.all (/home/projects/github-rfy1xs-ea1byz/node_modules/hast-util-to-html/lib/index.js:273:27)
    at Module.element (/home/projects/github-rfy1xs-ea1byz/node_modules/hast-util-to-html/lib/handle/element.js:96:25)
    at Module.one (/home/projects/github-rfy1xs-ea1byz/node_modules/zwitch/index.js:121:17)
    at Object.one (/home/projects/github-rfy1xs-ea1byz/node_modules/hast-util-to-html/lib/index.js:254:27)
    at Object.all (/home/projects/github-rfy1xs-ea1byz/node_modules/hast-util-to-html/lib/index.js:273:27)
    at Module.element (/home/projects/github-rfy1xs-ea1byz/node_modules/hast-util-to-html/lib/handle/element.js:96:25)
    at Module.one (/home/projects/github-rfy1xs-ea1byz/node_modules/zwitch/index.js:121:17)
  Hint:
    Make sure your promises all have an `await` or a `.catch()` handler.
  Error reference:
    https://docs.astro.build/en/reference/errors/unhandled-rejection/
  Stack trace:
    at /home/projects/github-rfy1xs-ea1byz/node_modules/hast-util-to-html/lib/handle/index.js:63:9
    [...] See full stack trace in the browser, or rerun with --verbose.

What's the expected result?

I expect Astro to handle custom elements and render them as normal HTML and not error.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-rfy1xs-ea1byz?file=src%2Fcontent%2Fdocs%2Findex.md

Participation

• I am willing to submit a pull request for this issue.

[matthewp]

Here's a minimal reproduction that doesn't require starlight: https://stackblitz.com/edit/github-qdnomy?file=src%2Fpages%2Findex.md

[matthewp]

Custom elements are not required here, was able to reduce down to just this:

<div type="number" value="1"></div>

[matthewp]

There's an underlying issue with the rehype stack: syntax-tree/hast-util-raw#22 Will need to see if I can fix this there.

[matthewp]

There's another discussion about this same bug here: syntax-tree/hastscript#21

[KonnorRogers]

@matthewp thanks for digging in! much appreciated. Are there any workarounds for this? Such as modifying the AST directly in a remark plugin or something?

EDIT: on second look, it appears I may just patch-package for now on this line to check for custom elements:

https://github.com/syntax-tree/hastscript/blob/2a7451dc1eb2adc6b07af6efed8a8bdcc8f13758/lib/create-h.js#L157

[matthewp]

Yeah, that's what i would do if it's urgent. Another would be to add a script to dynamically add the type in the browser.

[matthewp]

Underlying issue was fixed in syntax-tree/hastscript@8a5f97e

released as a major so I think we need to do some upgrading to see it here, in Astro.

[KonnorRogers]

@matthewp thanks for the help!

[matthewp]

hastscript has been updated, but the parent modules that depend on it have not, so we cannot yet upgrade. Since we have automation for upgrading packages I'm going to close this issue as its now out of our hands.