Custom 'void' or self-closing elements (HTML parser changes)

[pfrazee]

This was discussed in #113

It would be very nice to be able to declare Custom Elements as void or self-closing. Given that element names are already a little lengthy (from the required dash) there are times where avoiding the name repetition would preferable.

Presently, all custom elements must be used as:

<my-element></my-element>

And I'd like to be able to do self-closing:

<my-element />

Or void:

<my-element>

Perhaps by a static getter in the class definition

customElements.define('my-element', class extends HTMLElement {
  static get isVoid() { return true }
})

Any chance we can reopen this discussion?

[rniwa]

This would require a HTML parser change. We might be able to do this (self-closing) if we restricted to elements with - in its name.

[annevk]

Nobody wanted to change the HTML parser the last time around. What changed?

[rniwa]

Well, I didn't want a parser change to be part of v1 since that would have required a lot more compatibility checks. Now that v1 is out the door, I think it might be worth checking whether there is an actual Web compatibility issue or not.

[annevk]

@rniwa whatwg/html#919 (comment) has pretty good rationale for why we nevertheless probably shouldn't do it.

[pfrazee]

That's a credible reason, so the question is, how much do we care about self-closing tags? Enough to fight that battle?

App devs can work around this using custom templating engines, but that's a shame when you consider that part of the appeal of Custom Elements is getting away from non-native solutions.

[Jamesernator]

I would definitely like to see self-closing tags, a good amount of tags I've found useful can be often described from their attributes e.g. <x-markdown src="./some-info.md"></x-markdown> which would be a lot nicer as just <x-markdown src="./some-info.md" />.

[rniwa]

@annevk I don't agree with @hsivonen assertion that we should not make changes to the parser. There are many things that are security sensitive. In theory, the security of websites can rely on the absence of any Web feature and become vulnerable when any new feature is introduced. But we don't stop introducing new features just because of such a concern. I can be convinced if this turns out a be real security concern, but given the importance of the motivating use cases, I'm not at all convinced we can't make any changes here.

[Jamesernator]

@rniwa Yeah I don't think the argument is strong enough to suggest that we should never change the parser ever and stop adding features to html. By the html definition <x-markdown /> should be an error anyway even though browsers recover and wrap following content in it.

It's weird too because the html document even specifies that tags from other namespaces can be self-closing, it just seems weirdly inconsistent. Is there a particular reason every element can't be self-closed?

[annevk]

@rniwa I still don't see how minor changes here and there to the HTML parser actually accomplishes what folks want, which is custom elements that can take the place of arbitrary HTML elements, such as <li> or <td>. And what it does do is make the HTML parser less reliable and a source of bugs and problems across the ecosystem.

[Jamesernator]

@annevk Just speaking for myself but I'm sure others would like it too but I'd certainly find self-closing tags an improvement and assuming only <x-foo /> form is allowed (initially at least) it shouldn't conflict with <p> like behaviours which I feel should be a separate issue given that it's far more complicated.

And from what I'm aware isn't it the case that a correct parser should consider this an error anyway <x-markdown /> (assuming this still applies https://www.w3.org/wiki/Validating_your_HTML#Different_browsers_interpret_invalid_HTML_differently) so correct parsers shouldn't break (just fail) if given <x-markdown />, the thing is the addition of virtually anything to HTML could potentially make the HTML parser a source of bugs, e.g. simply adding another void tag or auto-closing (like <p>) (and plenty of other things I'm sure) would mean existing parsers would be invalid . For those reasons I'm definitely not happy with the argument that we can't extend HTML because some parsers might break.

[annevk]

@Jamesernator HTML parsers do not fail and that document seems out-of-date at best. The HTML parser we care about is defined at https://html.spec.whatwg.org/multipage/syntax.html#parsing and any change would have to be a change to that algorithm.

[annevk]

There's no interest in changing the HTML parser for void elements. The bar for changes is too high and the ergonomic benefit is too low.

[abitrolly]

Just to clarify - there are these two types of elements:

1. void - <my-element>
2. self-closing - <my-element/>

It seems logical that modifying parser to catch new void elements is not good, because nobody knows if custom element should be void or not just by looking at the tag. But what is the problem with self-closing tags?

[annevk]

I should have been more clear, my statement applies to self-closing tags too.

[abitrolly]

Then how high would be the bar for changes if we concentrate only on self-closing tags without touching void elements?

[annevk]

It's still too high. There's basically only interest in security fixes and non-normative changes.

[abitrolly]

So people are doomed to double their simple <custom-element></custom-element> names till the end of internet?

[annevk]

As far as the text/html format goes that's where we're at.

[amkuipers]

as a developer using custom elements I would really like self-closing custom elements. It makes no sense to me if I have a <custom-box color='RED' /> , that my browser even stops and ignores the remaining html code. I must specify a separate closing tag for the custom-box before it even works.

• Developer friendly: allow self-closing custom elements for custom element users

Another motivation is; when someone is using the custom element and that element has no nested content or elements, that developer wants to cleanup its code by changing it to a self closing element. It just looks ugly.

Another motivation is; when the custom element needs a separate closing element, the developer might assume that the custom element accepts content; which it might not.

• I would vote for the custom element IDE to issue a warning on ignored content for:

<custom-box color="RED">ignored text</custom-box>
<custom-box color="RED"><p>ignored child element with text</p></custom-box>

[ghost]

Since this is the second time this same statement has been brought up in this issue, I wanted to mention that no‐one seriously cares about that document, at least not since 2007, when the document was last updated.

It’s not an unreasonable statement, but over time, people have come to realize that it doesn’t actually work well (for the Web, at least). It doesn’t really matter if “authors really want it”, if implementors don’t implement it, either because they can’t or because they don’t want to, the specification becomes moot, as a series of problems arrive.

If the spec is implemented inaccurately in ways that leave discrepancies between it and implementations (in incompatible ways), new implementations won’t want to follow it and risk breaking existing websites. They will prefer to try to copy the behavior of existing implementations, and that opens the opportunity to the implementations themselves to differ. (Which is exactly what the spec is trying to avoid!)

Also note that whatever merit that the aforementioned “Priority of Constituencies” paragraph has is limited to making decisions, not changing them. In this case, the decision of “not allowing either void or self‐closing custom elements” was already made implicitly when custom elements were specified without it. Changing that now has different implications than when it was first specified.

[WaltzingPenguin]

Not being able to make custom elements self closing starts to introduce some serious room for error when dealing with slots.

This renders the default content of the slot:
<my-element></my-element>

This renders the slot as empty (replaced with whitespace):
<my-element> </my-element>

The difference between the two is easy to miss and is problematic, especially when distributing components to outside users. <my-element /> would be much clearer.

[rob2d]

It's mainly a matter of making things idiomatic for humans; Like any code, but especially a declarative templating system, HTML shouldn't be meant to just be written but to be read since it's basically a templating language (obviously there is more into that like reliance on DOM; but the XML semantics weren't just a coincidence/side effect of the functionality).

Been working with building components in a custom Web Component library for the past few months and in terms of interfaces it has been a little bit redundant with this aspect and it's hard to make an interface that is more pleasant as there has to be an extra level of consideration trading off the name specificity of a simple custom element ; with web components you need to repeat everything 2x even if it is a simple or self-contained. Issue is especially obvious with web components when you consider slotted vs not slotted elements, and matters where users might either need to nest content or not.

I can't make pretend personally that it would be painless for browser engines to do this, and I definitely respect the work of these developers, but semantic issues like this in 2021 should probably be a relative priority if web components are at least aiming to make things more idiomatic or succinct /jmho.

[besworks]

I came up with a technique to work around the behavior that @WaltzingPenguin mentioned a few comments up. Basically, just check if the element contains only text nodes that contain only whitespace and if so purge them all. Do this in connectedCallback and any time nodes are added to or removed from the host with a MutationObserver.

[taburetkin]

i found this thread because i tired to write in my html <my-component></my-component> again and again
so i started to look for solution for this.

imo the void elements by itself are evil and implies to know all the void elements.
If you are not aware of all void elements this <br><hr>... will be not self explanatory.

everything would be much simpler if there were no void elements at all, if all containers always looked like this <xxx></xxx>, and all elements without children like this <xxx />

[andyearnshaw]

@taburetkin, you could achieve that by writing your pages using XML syntax for HTML (formerly referred to as "XHTML"):

The second concrete syntax is XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax.

https://html.spec.whatwg.org/multipage/introduction.html#html-vs-xhtml

[abitrolly]

@andyearnshaw the advice to use XHTML looks like banana and gorilla to me.

[andyearnshaw]

@abitrolly, I'm not advising to use XHTML; I don't use it myself. I'm saying that, if a super-strict, no-void-elements parser is required, one already exists. Someone thinking about using XML syntaxt for HTML would need to consider the benefits/drawbacks for themselves.

While I agree with the sentiment that "everything would be much simpler if there were no void elements", that ship has sailed for HTML (it left the dock about 30 years ago).

[abitrolly]

@andyearnshaw I doubt that a person tells who tired of writing <my-component></my-component> wants to deal with additional limitations imposed by super-strict XHTML toolchain.

While I agree with the sentiment that "everything would be much simpler if there were no void elements", that ship has sailed for HTML (it left the dock about 30 years ago).

Can you remind me again, why it is impossible for ships to return to dock for retrofitting?

[Danny-Engelman]

HTML was and never will be retrofitted.
This discussion was closed 6 years ago in 2017
There will never be self-closing custom elements.
Period.

If you don't understand Why, you will find a better career flipping burgers at McDonalds.

[andyearnshaw]

@abitrolly I'm not looking for a lengthy debate that will end the same way as all the others before it, but I'll just point out there are plenty of people using TypeScript, despite the strictness and verbosity it adds to JavaScript.

Also, a ship that set off 30 years ago will take another 30 to come back for retrofitting. 😉

[abitrolly]

@andyearnshaw a man who is not allowed to flip burgers in McDonalds, because he is a leper from sanctioned Belarus says that making a FAQ with a short link that contains technical explanations that are based on evidence, will save you hours of debates and a dozen of insults. If you decide to be empathic to other people one day, you may also want to consider that such FAQ will also save them some precious time on rereading this thread.

[abitrolly]

I am unsubscribing. Thanks for all the fish.

[andyearnshaw]

@abitrolly it looks like you're conflating my comments with those of someone else in this thread. I have not used any insults and am fully empathetic towards the people requesting this feature. I do, however, understand why it is not possible to change how HTML is parsed at this point in time. I merely entered the discussion to offer an (potentially helpful) alternative to someone asking for self-closing tags.

[abitrolly]

@andyearnshaw I realize my mistake about attributing the insults to the wrong individual. That however, doesn't change my view that boasting about how big is your understanding does not add any value to the understanding of others. I don't find the explanation "because it is too late" or "because it will break things" sufficient. Let's just admit there are no people who can make those experiments and provide proof links. We are all busy with our lives, and no matter how awesome our big tech corporation is, it will never allow its minions to waste its resources to the research of "What needs to die for people to write short tags for custom elements?". Guess that's a final nail to my coffin of finding a job. Have to "enjoy" my freedom.

[turboborsuk]

Also, a ship that set off 30 years ago will take another 30 to come back for retrofitting. 😉

@andyearnshaw C'mon, that ship's been adrift with the crew paddling sideways most of the time. 😉

[sashafirsov]

@Danny-Engelman

There will never be self-closing custom elements.

You already wrong. The mix of HTML and XML is in place and in XML island like SVG or MathML closing tags are valid case.
Have to experiment on XHTML island cross-browser with hope to dump dumb HTML in favor of strict XML.

Perhaps the future would leave HTML behind, along with JS. The AST binary tree proposal seems doing slow but progress. In this tree it does not matter how parser would close the "tag", whether implicitly as in this proposal or XML, or by 1000+ weird rules as in HTML.

[alshdavid]

What's wrong with a self closing custom element? Seems useful in reducing verbosity in cases like custom input fields or icon wrappers where a closing tag is not necessary or misleading as to the behaviour of the element.

For instance:

<custom-date-input format="iso" />
<fa-icon name="github" />

vs

<custom-date-input format="iso"></custom-date-input>
<fa-icon name="github"></fa-icon>

Where the closing tag is unnecessary and implies to consumers that the element could contain children.

[ngdangtu-vn]

I don't understand why xml can self-closing tags freely and html cannot? What's the problem?