Re: [WICG/webcomponents] Custom 'void' or self-closing elements (HTML parser changes) (#624)

> As I alluded to above, that seems unlikely to happen, but you're welcome to try again.

@annevk Perhaps the issue should be re-opened so we can continue trying.

Can someone link to the XSS vulnerabilities?

Is it possible to have a new space to work in, with new parsing rules without the error-guessing semantics or special tree mangling rules? ⚡

```html
<html ⚡></html>
```

The following would be valid:

```html
<html ⚡>
  <script src="foo.js" />
  <div class="single-div-challenge" />
  <gltf-model src="path/to/helmet.gltf" />
</html>
```

There would be _no void elements_. Only `<foo></foo>` and `<foo />`. But I suppose this means stuff can not appear on screen as soon as possible, because closing tags need to be found. We can make an exception: The closing `</html>` tag is inserted after the first piece of incorrect markup is removed, and no more markup is loaded, and an error is output to console.

Based on this idea, if we write

```html
<html ⚡>
  <script src="foo.js" />
  <div>
    <gltf-model src="path/to/helmet.gltf">
  </div> <!-- error thrown at this point -->
  <img src="..." />
</html>
```

The result may be the same as the following HTML from today:

```html
<html>
  <script src="foo.js"></script>
  <div> </div>
  <img src="..." />
</html>
```

If we write

```html
<html ⚡>
  <script src="foo.js" />
  <div>
    <div>
    <gltf-model src="path/to/helmet.gltf">
  </div> <!-- error thrown at this point -->
  <img src="..." />
</html> <!-- error thrown at this point -->
```

The result may be as if we wrote

```html
<html>
  <script src="foo.js"></script>
</html>
```

The only special mangling rules would be the automatic addition of `<body>`. Beyond that, all else would be what-you-write-is-what-you-get.

So this,

```html
<html ⚡>
  <p><div /></p>
</html>
```

would have to result in an `HTMLParagraphElement` having an `HTMLDivElement` child, which is something we can do when we create a tree with imperative JavaScript, or it would throw a parser error (instead of mangling), or we update `HTMLParagraphElement`'s implementation so that it actually calls `removeChild` on any element at runtime (triggering MutationObserver and custom element life cycles) rather than it being parser magic.

If `<p><div /></p>` would make a parser error and stop the parsing, then


```html
<html ⚡>
  <div>
    <p><div /></p>
  </div>
  <img />
</html>
```

would be like writing

```html
<html>
</html>
```

Or, maybe we can decide that parsing errors are localized to the know error area. In that case the last result would instead be

```html
<html>
  <div> </div>
  <img />
</html>
```

and after removing the bad `<p><div /></p>` and throwing an error to devtools console, it would continue to see if it can continue without that known-bad piece (as if we never wrote it).


Some elements should always be self closing, and the parser should error on those. For Custom Elements to enforce self closing or not, it should be doable with statics perhaps:

```js
class CoolElement extends HTMLElement {
  static selfClosing = true // only enforced if provided (optional)
  // ...
}
```

This would require that custom element definitions happen in a script tag before any custom elements are encountered (which by the way would eliminate all the problems with upgrade ordering).


---

We need self-closing abilities for all elements, and void elements are just a source of ambiguity (elements either have children, or they don't). 

## Be gone void elements! :ghost:



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/624#issuecomment-770156602

Received on Saturday, 30 January 2021 04:44:49 UTC