Skip to content

feat: in-tag comments#831

Open
KazariEX wants to merge 6 commits into
vuejs:masterfrom
KazariEX:codex/start-tag-comments-rfc
Open

feat: in-tag comments#831
KazariEX wants to merge 6 commits into
vuejs:masterfrom
KazariEX:codex/start-tag-comments-rfc

Conversation

@KazariEX

@KazariEX KazariEX commented Jun 17, 2026

Copy link
Copy Markdown
Member

Summary

  • propose in-tag comments in Vue template opening tag attribute lists
  • preserve in-tag comments as AST nodes for tooling such as line-level @vue-expect-error
  • keep runtime code generation unchanged

@lizhan12

lizhan12 commented Jun 17, 2026 via email

Copy link
Copy Markdown

@naitokosuke

Copy link
Copy Markdown

My first reaction was that this is a great feature — really nice to be able to comment inside the opening tag.

Just out of curiosity, not a strong opinion either way — the Template Syntax docs (https://vuejs.org/guide/essentials/template-syntax.html) currently promise:

All Vue templates are syntactically valid HTML that can be parsed by spec-compliant browsers and HTML parsers.

A <!-- --> inside an opening tag seems to break this, so it looks like this changes a long-standing invariant. I'm just curious how the team sees this.

@KazariEX

Copy link
Copy Markdown
Member Author

I don't have a strong preference regarding the comment style, but although JS-style comments like those in sveltejs/svelte#17671 can be parsed by spec-compliant HTML parsers when they don't contain certain special characters, they still change the semantics of the generated AST. I think that's hard to avoid, so we might as well add it as a complete feature from the start.

@ubugeeei

Copy link
Copy Markdown
Member

I think Vue's syntax should largely stay within the bounds of HTML.
We shouldn't break templates embedded in .html files.

In Html, <div <!-- commnet -->> means:

<body>
  <div <!--="" commnet="" --="">
    #text ">hello"

This is Invalid.

It's true that Svelte recently added support for this, but I don't think that, by itself, is a reason for Vue to do the same.

We can try via console
const d = new DOMParser().parseFromString(`
<div <!-- commnet -->>hello</div>
`, "text/html")

d.body.children[0].attributes

@KazariEX

Copy link
Copy Markdown
Member Author

This RFC was not intended to introduce syntax incompatible with HTML; it's merely a side effect of the current implementation. I sincerely hope the team can explore a more compatible solution.

@haoqunjiang

haoqunjiang commented Jun 17, 2026

Copy link
Copy Markdown
Member

We shouldn't break templates embedded in .html files.

I think a better way to frame this is as "an SFC-only syntax add-on", similar to the case-sensitive tag names.
Developer shouldn't use this syntax in in-DOM templates, just as they shouldn't write PascalCase component names in in-DOM templates.

And since this is a syntax add-on, I'd prefer the Svelte-like // syntax because it's easier to write, and, IMHO, more intuitive for this generation of web developers.

@pikax

pikax commented Jun 17, 2026

Copy link
Copy Markdown
Member

if the main issue is to ignore the attribute, why not proposing to extend <!-- vue-expect-error:myProp reasons --> <MyButton my-prop="... or something similar.

I also would prefer the // instead of HTML comment

@edison1105

Copy link
Copy Markdown
Member

I think the motivation is valid, especially for supporting line-level tooling directives such as @vue-expect-error on a specific prop or directive. But I’m concerned about using <!-- comment --> as the syntax here.

Vue already has the compile-time compilerOptions.comments option, which controls whether normal template comments are preserved in the AST / generated output. A normal <!-- --> comment is removed when comments: false and preserved when comments: true.

If in-tag comments use the same <!-- --> syntax, we would end up with two visually identical kinds of comments with different semantics: normal template comments are controlled by the comments option, while the in-tag comments proposed here are always preserved in ElementNode.props for tooling, but do not participate in runtime codegen.

So if this feature is essentially a Vue/SFC-specific compile-time annotation, I’d lean toward a non-HTML-comment-looking syntax such as // comment. It is still Vue-specific syntax, but it more clearly separates this feature from the existing compilerOptions.comments behavior and avoids giving <!-- --> two different sets of rules.

@KazariEX

Copy link
Copy Markdown
Member Author

Updated to use the JS style syntax.

@ubugeeei

Copy link
Copy Markdown
Member

Also, if we decide to support this, I think we’ll need to work closely with @johnsoncodehk and make sure we stay aligned with Language Tools support (especially tmLanguage support).

@orimay

orimay commented Jun 20, 2026

Copy link
Copy Markdown

My way is to add data- prefix to the prop. Perhaps, another prefix could disable the prop?

<MyComponent
  _="my comment"
  _some-prop="disabled now"
/>

It's HTML-compatible

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants