Failed to use Vue component in markdown

[ProsperBao]

I think the case conversion of plug-in V14 is incorrect when converting markdown to Vue components, which leads to the problem.

When I change the plug-in version to V13, it can be loaded successfully

Even ClientOnly cannot render successfully

↓↓↓↓↓↓↓↓↓↓↓You can see examples here↓↓↓↓↓↓↓↓↓↓↓ demo ↑↑↑↑↑↑↑↑↑↑↑You can see examples here↑↑↑↑↑↑↑↑↑↑↑

Please change the package Dependency in JSON "vite-plugin-md": "^0.14.0" -> "vite-plugin-md": "0.13.1"

[yankeeinlondon]

I will look a bit more into this but I believe this is because we're using DOM operations and officially uppercase characters are not valid HTML and are probably lost in one of the DOM transforms. In general I would always recommend that you use the dasherized form for component names as this is true to the specificiation.

[yankeeinlondon]

it definitely does work if you use formal HTML syntax: example

[yankeeinlondon]

I have been surprised for years that there hasn't been a greater push to move toward the standard. It's true there's no inherient advantage to either approach -- it's just another tabs vs spaces debate -- but the exception in this case is one is a a standard and the other is not (actually from a human cognition standpoint kebab-case is also known to create lower load on the human brain). It would appear that Markdown It as a parser doesn't care but happy-dom does and losses the capitalization in its representation of the DOM API.

Let me look at the code a bit more after my meetings but I suspect that we may have to create a simple MarkdownIt plugin to convert all PascalCase tags to kebab-case to force things to be standards compliant. In the mean time, however, there is an easy work-around ... switch to kebab notation ... the Internet will thank you.

[ProsperBao]

Thank you for your answer. I habitually use the way Vue is written. At the same time, I see that antfu is used in this way, so I think this is correct.

I will correct the use method in my project.

I will look a bit more into this but I believe this is because we're using DOM operations and officially uppercase characters are not valid HTML and are probably lost in one of the DOM transforms. In general I would always recommend that you use the dasherized form for component names as this is true to the specificiation.

[yankeeinlondon]

@FuBaooo components are very commonly written in PascalCase and typically the first parser to receive that HTML is VueJS (or whatever framework the author is using). For this reason, so long as VueJS is happy with PascalCase it works (and VueJS definitely is happy with either format). However, when it goes further down the stack ,the HTML specification for "custom components" states that non-standard components must be dasherized. That means not only is PascalCase incorrect but single word components are also incorrect.

I presume the reason that PascalCase is so common is that kebab-case is language incompatible with Javascript so people like the consistency in naming. That still doesn't change the fact that when it comes to the official HTML specification that this is indeed non-standard. It may be a long road before HTML custom components rule the world but by then either the HTML specification will have to have been changed or parsers like VueJS will have to have incorporated the conversion before it arrives in the browser. I'm actually interested to see what VueJS does when you turn on the "custom component" flag on it's parser.

Anyway, because PascalCase is so common I think we need to support it ... and I think the easiest way to do so is just to convert it to kebab-case in this component. It should then work through the remainder of the transformatiion pipeline.

[ProsperBao]

@FuBaooo components are very commonly written in PascalCase and typically the first parser to receive that HTML is VueJS (or whatever framework the author is using). For this reason, so long as VueJS is happy with PascalCase it works (and VueJS definitely is happy with either format). However, when it goes further down the stack ,the HTML specification for "custom components" states that non-standard components must be dasherized. That means not only is PascalCase incorrect but single word components are also incorrect.

I presume the reason that PascalCase is so common is that kebab-case is language incompatible with Javascript so people like the consistency in naming. That still doesn't change the fact that when it comes to the official HTML specification that this is indeed non-standard. It may be a long road before HTML custom components rule the world but by then either the HTML specification will have to have been changed or parsers like VueJS will have to have incorporated the conversion before it arrives in the browser. I'm actually interested to see what VueJS does when you turn on the "custom component" flag on it's parser.

Anyway, because PascalCase is so common I think we need to support it ... and I think the easiest way to do so is just to convert it to kebab-case in this component. It should then work through the remainder of the transformatiion pipeline.

I think it should be added #95

[yankeeinlondon]

this will now convert your PacalCase components to kebab-case automatically when detected in v0.16.0