Lwc: Compile error on self closing void elements

[pozil]

Description

When compiling code that contains a self closing void element such as <hr/>, the compiler will throw an error.

Steps to Reproduce

Build a component with this template:

<template>
    <hr/>
</template>

https://developer.salesforce.com/docs/component-library/tools/playground/rE1bVtKyj/1/edit

Expected Results

This compiles without error.

Actual Results

Compiler throws:

LWC1058: Invalid HTML syntax: non-void-html-element-start-tag-with-trailing-solidus. For more information, please visit https://html.spec.whatwg.org/multipage/parsing.html#parse-error-non-void-html-element-start-tag-with-trailing-solidus

Note that the spec linked in the error does mention that void elements can have a trailing solidus without any effect.

Browsers Affected

n/a

Version

Found this on in 1.1.0-alpha4 in a LWC OSS project.
Playground is affected as of 2019-08-30.

Possible Solution
Ignore void elements when applying compile time check as suggested in the HTML spec.

Additional context/Screenshots
This is particularly problematic because Prettier forces self closing tags on void elements and there's no way to disable that.
See: https://github.com/prettier/prettier/issues/5246

[muenzpraeger]

It's a Prettier error.

From the spec.

It must have start tag, but must not have an end tag.

[pozil]

@muenzpraeger this is Mozilla documentation, not the spec.
This doc is wrong. The single source of truth is the WHATWG spec.

As linked in the compiler error:

This error occurs if the parser encounters a start tag for an element that is not in the list of void elements or is not a part of foreign content (i.e., not an SVG or MathML element) that has a U+002F (/) code point right before the closing U+003E (>) code point. The parser behaves as if the U+002F (/) is not present.

and in the notes:

It is also allowed for void elements, but doesn't have any effect in this case.

[muenzpraeger]

And for hr it says No end tag. ;-)

https://html.spec.whatwg.org/multipage/grouping-content.html#the-hr-element

[muenzpraeger]

I guess @diervo can judge best. He built the parser.

https://www.npmjs.com/package/parse5-with-errors

[pozil]

Adding HTML element general spec for reference:

1. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.

[pozil]

By the way, the No end tag info is "A non-normative description" as per Tag omission in text/html link on that page.

[caridy]

We rely on parse5 to parse the HTML files, that's why it is hard for us to fix this kind of issues.

[pozil]

Should anyone run into this issue where Prettier automatically adds a self-closing solidus/ character, the workaround is to manually exclude the problematic template file from Prettier processing.
To do that, add the path to the template file to a .prettierignore file at the root of the project.

[pozil]

Adding @pmdartus to the conversation since he 'owns' our private parse5-with-errors fork of parse5.

@caridy I looked into parse5 and I believe (correct me if I'm wrong) that we introduced the error in parse5-with-errors. The current public version of parse5 is ok with self closing void elements.

We're missing a check for void elements here:
p-dartus/parse5-with-errors/blob/master/lib/parser/index.js#L665

May I correct this with a PR?

As a separate note, @diervo the parse5-with-errors NPM package public listing is using a git soma URL as it's home page. We should probably fix that.

[caridy]

@pozil yes yes yes! go for it.

[pozil]

@pmdartus @caridy please review p-dartus/parse5-with-errors/pull/2 (I can't assign reviewers).

[diervo]

We should certainly move that package from Pierre's user account xD

[caridy]

approved! if @apapko is good with it, we can move on!

[pozil]

@apapko can we proceed?

[diervo]

@pozil yeah let's get @pmdartus to push a new version at lest roll.

[apapko]

approved! Thank you @pozil

[diervo]

Fix: https://github.com/salesforce/lwc/pull/1574

[apapko]

This has bee resolved with #1574 update of parse5-with-errors, which contains the self-closing tag change.