Align HTML parsing with spec to support Vue Templates and Single File Components

bmeurer commented

2022-11-13 12:17:57 +01:00

(Migrated from github.com)

Vue Templates and Single File Components are basically valid HTML, so for the purpose of supporting them in Chrome DevTools, it's enough to ensure that we treat *.vue files as HTML documents and ensure that the HTML parser is sufficiently relaxed. These patches add support for relaxed attribute name parsing, and also adjust the parsing of self-closing tags to better support common components template syntax.

Vue Templates and Single File Components are basically valid HTML, so for the purpose of supporting them in Chrome DevTools, it's enough to ensure that we treat `*.vue` files as HTML documents and ensure that the HTML parser is sufficiently relaxed. These patches add support for relaxed attribute name parsing, and also adjust the parsing of self-closing tags to better support common components template syntax.

marijnh commented

2022-11-14 14:28:11 +01:00

(Migrated from github.com)

I do want to keep this parser aligned with how browsers parse stuff, and recognizing <p/> as a self-closing tag is definitely not what a browser does. What kind of template syntax parses HTML like that?

I do want to keep this parser aligned with how browsers parse stuff, and recognizing `<p/>` as a self-closing tag is definitely not what a browser does. What kind of template syntax parses HTML like that?

bmeurer commented

2022-11-14 15:06:06 +01:00

(Migrated from github.com)

Looking at the spec at least for foreign elements the / right before > marks the tag as self-closing. For <p/> it'd be a bit of an outlier indeed, but wouldn't hurt either, IMHO.

Looking at the [spec](https://html.spec.whatwg.org/multipage/syntax.html#start-tags) at least for _foreign elements_ the `/` right before `>` marks the tag as self-closing. For `<p/>` it'd be a bit of an outlier indeed, but wouldn't hurt either, IMHO.

marijnh commented

2022-11-14 15:18:13 +01:00

(Migrated from github.com)

The issue I'm trying to avoid is for the mode to encourage people to write broken HTML by treating things like self-closing elements, which are simply not something that exists in this context, as valid. <script/> is a very common mistake, and at least having odd indentation below it might tip people off that something is wrong.

The issue I'm trying to avoid is for the mode to encourage people to write broken HTML by treating things like self-closing elements, which are simply not something that exists in this context, as valid. `<script/>` is a *very* common mistake, and at least having odd indentation below it might tip people off that something is wrong.

bmeurer commented

2022-11-14 15:19:30 +01:00

(Migrated from github.com)

Makes sense. If you want to be 100% correct here, you would need to distinguish HTML element tag names from other names.

The primary case that I'd interested in, is for Web components and framework components, where you do indeed write stuff like

<Header foo="bar" />
<my-awesome-component icon="x" />

Makes sense. If you want to be 100% correct here, you would need to distinguish HTML element tag names from other names. The primary case that I'd interested in, is for Web components and framework components, where you do indeed write stuff like ```html <Header foo="bar" /> <my-awesome-component icon="x" /> ```

marijnh commented

2022-11-14 15:21:34 +01:00

(Migrated from github.com)

But that is not HTML... it may be inspired by it, but it really isn't the same language.

Maybe we could make this a dialect, and only enable the self-closing end-of-tag token for that dialect?

But that is not HTML... it may be inspired by it, but it really isn't the same language. Maybe we could make this a dialect, and only enable the self-closing end-of-tag token for that dialect?

bmeurer commented

2022-11-15 07:46:42 +01:00

(Migrated from github.com)

Alright. How do you feel about the attribute token syntax change? Shall I send that as a separate PR and then we figure out the self-closing tags story independently (as it's not really related and mostly an oddity in the AST)?

marijnh commented

2022-11-15 12:51:04 +01:00

(Migrated from github.com)

Attached patch adds a dialect "selfClosing" that enables this type of self-closing tag. It's not going to be turned on by default in the lang-html package, but you could reconfigure that language object to enable it. Does that work for you?

Attached patch adds a [dialect](https://lezer.codemirror.net/docs/ref/#lr.ParserConfig.dialect) `"selfClosing"` that enables this type of self-closing tag. It's not going to be turned on by default in the lang-html package, but you could reconfigure that language object to enable it. Does that work for you?

bmeurer commented

2022-11-15 14:36:47 +01:00

(Migrated from github.com)

Oh, that's a cool idea! I like it.

bmeurer commented

2022-11-16 06:50:35 +01:00

(Migrated from github.com)

Thanks! Can you mark a release with these fixes please?

marijnh commented

2022-11-16 07:27:10 +01:00

(Migrated from github.com)

I've tagged 1.1.0

bmeurer commented

2022-11-16 10:20:13 +01:00

(Migrated from github.com)

Thanks, here's the follow-up fix for lang-html: https://github.com/codemirror/lang-html/pull/3

Thanks, here's the follow-up fix for `lang-html`: https://github.com/codemirror/lang-html/pull/3

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Rows
Columns

Align HTML parsing with spec to support Vue Templates and Single File Components #4

Pull request closed