Further reference: #8923

I don't think we can do this for 5.0 - there's probably dozens of apps/libraries that use the self-closing behavior because it was the default in prettier-plugin-svelte for ages (the latest version doesn't care anymore, but will preserve <div /> if you wrote it like that).
Given how this was not a real issue (some may even prefer it / find the current behavior much more intuitive/consistent with component shorthands), do we really need to change this?
We also shouldn't error on <input />, because who really cares? At the very least this means adjusting prettier-plugin-svelte first, etc etc, so this is a multi-version game for very little gain IMO.

There's actually a third option which is to just warn when the behavior happens (for now) and then maybe do # 2 error out in the future.

As a side note, I was around during the transition to HTML5 and never knew this either. Opinionated, but HTML5 browser behavior here is completely non-sensical and I'd be perfectly happy to leave it as is.

Put another way, this seems one minor area where modern frameworks have improved on bad browser behavior, with likely no real drawbacks.

[I updated my comment above in bold since I originally misunderstood the proposal and agree with erroring out.]

The issue of self-closing tags has been brought up many times (1 (post), 2, 3...) in the WHATWG and has been continually closed for the reason "it's too late to change anything, as many tools are based on current HTML behavior". Even the WHATWG regulars recognize the problem.
In my opinion what Svelte / JSX does in this matter is a better solution than what HTML offers.

I actually thought that Svelte 5 intentionally tried to fix this problem with HTML, because it is a major source of bugs that are very difficult to spot (from my experience working in web dev). There are so many things wonky about HTML that I discover, to find some thread from a decade ago as to why it is the way it is, and generally it's because the benefit in fixing it isn't worth breaking the web.

I'd probably lean towards keeping the existing behaviour if I was being honest – and maybe back down on how much we set ourselves on being a true superset of HTML.

This isn't about whether or not Svelte's handling of these tags is preferable or correct or whatever. It's about eliminating a source of ambiguity.

Right now, if you copy-paste some HTML containing <div /> into a Svelte component or vice versa, you'll end up with a completely different element tree. That's just unacceptable. We've been saved by the fact that this situation is somewhat rare, but that doesn't change the basic fact.

And I'm not suggesting that we start treating <div /> the same way as HTML — that's clearly confusing and silly behaviour. I'm suggesting that we prevent the ambiguity from arising in the first place.

There's actually a third option which is to just warn when the behavior happens (for now) and then maybe do # 2 in the future.

This would be an acceptable compromise, if there's a lot of malformed markup in the wild because of Prettier.

(Actually, I just read the 'maybe do # 2 in the future' bit, which I disagree with — I meant that warning now and then erroring in 6+ would be an acceptable compromise)

It's about eliminating a source of ambiguity.

...by introducing a new source of confusion, because the average web dev (us all included, as seen by this issue appearing now, and not years before) things that <div />foo means <div></div>foo and not <div>foo</div>. I agree with others here, I just don't think this is worth it.

Right now, this code...

<div />hello

will be understood differently by different people.

Adding an error or a warning that says 'this is ambiguous, you must either do <div>hello</div> or <div></div>hello depending on which you meant' categorically does not introduce a new source of confusion. It takes something ambiguous and requires you to make it explicit.

You're right, like that it wouldn't.
I'm still against it, because for many people it's much more ergonomic (especially when using web components) to use self-closing in some situations - and they've got used to it now.
The fact that noone in 5 years (or more?) has opened an issue about this means that the "I copy-paste some HTML code using self-closing tags into a Svelte file and had an hour long debugging session" situations almost certainly never came up.

I get that it's more convenient, and in the absence of other considerations convenience is worth optimising for. But I think it's pretty weird that if you take this code from a Svelte component...

<div>
  <my-thing /> is this inside or outside my-thing?
</div>

...and paste it into an HTML file (or a CodePen or whatever), you get totally different behaviour. We're not doing our community any favours here, and we're not being good citizens of the web.

@Rich-Harris I mean you can only go so far anyway, you can't exactly copy and paste this:

<div>
  <button onclick={() => { console.log('clicked me') }} id="1">123</button>
</div>

Obviously you can't copy-paste Svelte features in the template, any more than you can copy-paste runes and expect them to work. But this is like saying that because you can't use runes outside Svelte, it'd be acceptable if array = [1, 2, 3,] created an array of length 4 in Svelte because we historically parsed JavaScript incorrectly.

I'm absolutely flabbergasted at the pushback here.

The fact that noone in 5 years (or more?) has opened an issue about this means that the "I copy-paste some HTML code using self-closing tags into a Svelte file and had an hour long debugging session" situations almost certainly never came up.

Or, people have had that experience only to realize their understanding of how these tags work was wrong (in HTML and Svelte), didn't see anyone else confused by it, and felt embarrassed that nobody is apparently struggling with the undocumented discrepancy but them, and didn't open an issue.

There are also plenty of situations where this may not manifest in a visible (or overly annoying) way. Maybe people just think their selector is wrong or they style the parent instead of the node they actually want to style because it doesn't work for some reason.

This seems like one of those insidious situations where it's obscure and confusing enough to make people think they're wrong. Or they work around it and think their understanding was incorrect.

If someone was using <div /> or <my-thing /> in plain HTML, they arguably already made a mistake.
This then being differently broken in Svelte does not feel like a real issue to me.

The issue is less that people will paste malformed HTML into Svelte and experience it working differently, it's the reverse — people taking valid Svelte snippets into an HTML context and experience breakage there. This needn't mean literally copying and pasting code — it also means people taking an understanding of how HTML works that came from using Svelte and discovering that things break in odd ways when they try to use other frameworks (or no framework at all).

We're literally training people to write broken code. This is very bad.

Right now, if you copy-paste some HTML containing

into a Svelte component or vice versa, you'll end up with a completely different element tree. That's just unacceptable.

Is the self-closing tag the only thing that makes Svelte output different from HTML?

A few examples

<div>
</div>

<style>
	div {
		width: 20px;
		height: 20px;
		background-color: red;
		&:empty {
			background-color: green;
		}
	}
</style>

• Svelte 5 will output a green square as the space character is deleted.
• HTML 5 will output a red square because whitespace will be preserved.

<div>Hello world!

• Svelte 5 will output Error compiling....
• HTML 5 will output <div>Hello world!</div> since the unclosed tag is not a problem for it.

If you dive into the error correction inherent in HTML, there are likely other examples.

I would class the first of those as a bug — we should probably preserve whitespace in that situation. The second is fine, because (as with this proposal) we're just eliminating a source of confusion, rather than actively producing the wrong output

The second is fine, because (as with this proposal) we're just eliminating a source of confusion, rather than actively producing the wrong output

Yep, but that doesn't apply to nested tags. <div><p>Hello world!</div> with an unclosed p tag works in Svelte 5.

In HTML 5, you can write <div></p>Hello world!</div> (will cause an error in Svelte 5) or <div>Hello world!</p> (which will also cause an error in Svelte 5) and, weird as it sounds, this is normal for HTML 5. At one time, the reason for abandoning XHTML was that HTML 5 just knows how to handle errors, while XHTML does not. Self-closing tags are in fact also an error and the HTML 5 standard describes how to handle it, as well as many other cases. But we use frameworks to make life easier, not the other way around.

I think we can add a warning for self closing elements that aren’t void. Doing a quick search and they’re used plenty in svelte components for non void elements.

I don’t think it should be an error in Svelte 5 though. You’ll cause so much friction in upgrading and people will get frustrated.

I’m still personally in the category that feels like Svelte shouldn’t strive for complete HTML compatibility. Being HTML-like, and ironically JSX-like in my eyes, is fine and it has a valid place in the ecosystem. It’s the Svelte way.

I think the compromise of showing a warning now and then maybe enforcing it down the line is a good move. It would make most codebases more explicit about this behavior and other people that don't like it, can just disable the warning globally, and go about their own codebases at their own discretion.

Also maybe svelte 5 migration script could have a optional option to basically choose the behavior and apply it to the whole codebase, so people's codebases are not filled with a lot of warnings when upgrading.

Obviously you can't copy-paste Svelte features in the template, any more than you can copy-paste runes and expect them to work. But this is like saying that because you can't use runes outside Svelte, it'd be acceptable if array = [1, 2, 3,] created an array of length 4 in Svelte because we historically parsed JavaScript incorrectly.

I'm absolutely flabbergasted at the pushback here.

The difference is that with the self-closing tags, the current "incorrect" behavior is the consensus among multiple framework (jsx expands self-closing tags as well), and is the preferred behavior for not only most devs, but the creators of the "correct" behavior as well.

As opposed to an example that would be filed as an issue within hours of being a thing

At some point correctness becomes less useful. A lot of http servers/clients are "incorrect" according to the spec, and that is by design, even cloudflare had to switch out to "incorrect" http parsers. More than that, the browser itself allows for incorrect HTML like unclosed non-void tags (which your example here actually has. I believe that's invalid HTML according to the spec), "weaved"/incorectly nested tags (

You can dive into all that hell in the name of correctness, or accept the consensus.

And don't forget that one issue where a guy was using an obscure feature of HTML by passing function names as strings to buttons or smth which wasnt a thing in svelte, and iirc was then closed (I'll try finding and linking the issue in a sec). Why diverge from HTML there but go for correctness here?

Edit: found the issue I was mentioning: #9437
And I guess relates #9477

Html/original authors right now: https://youtu.be/HMqZ2PPOLik?si=YYSwODD84uDUfOJ2

At most this is a linter issue, making this into a breaking change is genuinely not worth it. You should make a poll on Twitter to gather (albeit not entirely accurate) some numbers on how many developers would rather keep the current behavior. As you said Svelte isn't a framework - it's a language, a difference like this which improves DX is welcomed with open arms.

Considering the alternatives, Angular errors on <div/> while Vue and JSX doesn't.

Why diverge from HTML there but go for correctness here?

We're talking about two different forms of 'divergence':

1. disallowing certain things outside a strict subset of HTML (i.e. no string event handlers) to prevent footguns
2. accepting certain syntactical forms, but interpreting them completely differently 🤡

What I'm proposing here is that we diverge consistently — always 1, never 2.

You should make a poll on Twitter

It will be as useful as if you ask voters whether they want lower taxes or better public services — the answer will be 'yes'.

I'm heartened to see Angular doing the right thing here.

The spec on this is unintuitive and obviously wrong. This is one of the additions that JSX got right. When I started using svelte I was happy that self closing tags were present. I imagine that the vast majority of devs would rather ignore the spec on this one than have to deal with extra </div> everywhere.

It's also not intuitive that you can use self closing tags for SVG and components. You're going to have to document this somewhere anyways.

Finally, I imagine that the result of this change would be the immediate creation of something like svelte-preprocess-self-closing-tags which is just going to be installed in like 90% of all svelte projects. You're also going to have to deal with years of people wanting this back. I think changing this is great ideologically, but from a practical view it only has downsides.

I always thought this was a thought-out Svelte specific feature and I liked it so far. Why not simply keep it?

I think a warning and a migration script would suffice. As a developer I'd rather stick to HTML spec rather than framework specific specs.

Great catch spotting this!

Because if we did that every time we couldn't get 100% unanimous consensus on something, your svelte.config.js file would be 700 lines long. Every Svelte project would look and behave completely differently, and you wouldn't be able to use any library installed from npm that didn't use the same options as you.

Why not keep this option inside the svelte components themselves? It would solve this issue, and will help users define how they want this to behave without breaking it when sharing their components around.

Example:

<script lang="ts">
// behavior of some-component.svelte
// ...
</script>

<svelte:spec-compliant {true} />

<div />hello!

If we keep this option tucked in per svelte file, it would make it only relevant when the developer absolutely needs this behavior without applying it to the whole project.

Svelte exists to make our life as developers easier.

For me, this includes closing empty elements in "shorthand" with /> instead of a full closing tag. This isn't valid HTML, but most will expect the compiler to handle it and extend it to <div></div>. I can't imagine anyone intentionally writing <div />hello and expecting the output to be <div>hello</div>. Although I admire the desire to adhere to the specs, the Svelte example in the issue is exactly why I love Svelte: it just makes more intuitive sense. Allowing it for SVG and some HTML elements (and Svelte components) but not for other elements is not intuitive, even though it's the spec. The specs and differing browser implementations are often ambiguous and I believe Svelte, being an opinionated compiler, is in the perfect position to make webdev less enigmatic. Forcing users to adhere to specs does not achieve this goal, and definitely does not warrant a breaking change.

We're not "training people to write broken code". We're not writing HTML, we're writing Svelte; we're training people to appreciate Svelte.

What about just permanently making this a warning, while falling back on the XML behaviour when there is an ambiguity between XML and HTML and including a linter that automatically fixes it to be unambiguous regardless of whether it is parsed as HTML or as XML? For reference, Vue SFC templates also use XML, and so does JSX. Warnings would help people not struggle to figure out why the behavious change and the linter would give them a fix. Errors do have the advantage that you can't ignore them of course.

Imho the real way to fix this long term would be to have web browsers implement XML as an alternative content type to HTML and have an actual spec that strictly bans the HTML behaviour. Deprecating HTML fully is hard to do of course, but we're in a weird situation where every mainstream javascript framework uses XML to generate markup instead of dealing with HTML, and where the most commonly used linter uses XML semantics.

My summary from reading:

1. Broad agreement that being spec compliant on this is not desirable.
2. Large group wants to keeps things as is (be like jsx on this).
3. Large group wants to error out (like Angular). And if we error out then make it a warning in Svelte 5 and error in Svelte 6.

2. Large group wants to keeps things as is (be jsx compliant).

Sevlte's syntax isn't JSX. It handles whitespace differently (like HTML) for a start.

Demo

i always understood that svelte templates were HTML, in which case, self closing markers should be ignored/errored

as mentioned above, thats the question we should really answer IMO: is a svelte template HTML?

if it is, you already have your answer. though it would be a big change ofc to disallow such syntax

Another thing to consider is what is most beginner friendly.

Beginners get frustrated with errors. But silently doing something different than what was written (like jsx) can catch out beginners too...

Would beginners be the least frustrated/surprised if we replaced <div /> with <div></div> in the editor on save?

1. Broad agreement that being spec compliant on this is not desirable.

If you look at comments reactions, especially the OP, you'll see a broad agreement that being spec compliant on this is desirable.

If you look at comments reactions, especially the OP, you'll see a broad agreement that being spec compliant on this is desirable.

I interpreted that as support for erroring out.

Right, my interpretation is:

1. No one wants it to handle HTML vs XML ambiguity by defaulting to HTML behaviour.
2. A large camp wants to throw an error or a warning on such an ambiguity and not handle it silently.
3. Another large camp wants to keep XML semantics on conflict if we don't error out (but not necessarily silently).

So imho regardless of which path forward is taken in the end there should be a warning raised to prevent a silent ambiguity, but there's a few options for what to do after the warning has been raised.

Right now, if you copy-paste some HTML containing <div /> into a Svelte component

Um, just one question. Where can you get some HTML containing <div /> to paste it into your component (without editing or review)?

@kkarpeev you omitted the 'or vice versa' from your quote. That's the larger problem #11052 (comment)

Funnily enough, I've always written it <br /> anyways simply for aesthetics, because nothing's more vexing than an unclosed parenthesis (despite having known <br> is possible

Just a couple of thoughts.

1. I don't know if Svelte should explicitly disallow (i.e. error) self-closing void tags. It's allowed by the spec even if ignored.
2. It's at least worth considering how this extends to components. Is it a source of confusion if people can self-close components but not html elements? My only strong opinion here is that we disallow (for example) <MyHorizontalRule> being self-closing just because it doesn't accept children; after all, who knows if one day it'll be refactored to suddenly have children.

I think the framework should try to

1. make people aware of this discrepancy (I didn't know about it)
2. encourage people to avoid this issue (basically avoid using self-closing tags)
3. ultimately let people choose how to deal with it

So, by default, the compiler could issue a warning, explaining the issue and also explaining how to turn this warning into an error
and with that knowledge, using a general configuration, we should be able to decide to ignore this issue, or treat it as a warning or error.

in future versions the default could be an error instead of a warning, but I would still let users choose to simply ignore it, with no warning or error what so ever

I don't know if Svelte should explicitly disallow (i.e. error) self-closing void tags

Void tags will be left alone, at least for now, because otherwise we'd be fighting with Prettier. I think these are fairly harmless anyway, unlike the ambiguous non-void case

It's at least worth considering how this extends to components. Is it a source of confusion if people can self-close components but not html elements?

The goal here is to make HTML behave the same inside and outside Svelte. In other namespaces (i.e. SVG), self-closing tags are allowed. We can think of Svelte components as being one of those 'other namespaces', and pasting <MyHorizontalRule /> into HTML already wouldn't do anything useful so there's no problem there. Of course, if people opt to write <MyHorizontalRule></MyHorizontalRule> for the sake of consistency, that will work equivalently to the self-closing version.

ultimately let people choose how to deal with it

This is a different way of phrasing 'solve it with configuration', which is addressed in #11052 (comment). It becomes unwieldy as soon as your project has dependencies, who may choose to deal with it in a different fashion

Hi. I read this discussion and see a waste of time on an extremely insignificant problem. Svelt has many other serious problems, but what is being discussed now is something that is not encountered in normal HTML writing practice. Moreover, the standard validator considers a self-closing tag to be an error.

There is this article that provides more context (and to clear up some other corner cases).
https://jakearchibald.com/2023/against-self-closing-tags-in-html/

After seeing how JSX handles , I vote for getting rid of HTML whitespace and going the JSX route.

The goal here is to make HTML behave the same inside and outside Svelte. In other namespaces (i.e. SVG), self-closing tags are allowed. We can think of Svelte components as being one of those 'other namespaces', and pasting into HTML already wouldn't do anything useful so there's no problem there.

Why is this the goal? This isn't the case for the majority of Svelte components; loops, render tags, etc. already break this idea. Shouldn't Svelte strive to be as unambiguous as possible? Why should we allow some elements to be self-closing but not others? What about <svelte:... /> tags? The behavior right now is fine because it's consistent and intuitive. Forcing people to write the closing tag instead of accepting the shorthand /> has a fairly large DX impact, only because there might be a tiny amount of people confused that <div />hello is not the same in their HTML file. It's also subjectively more elegant and semantic: <div /> implies to me that the div will not have any children, while <div></div> looks unfinished.

Please don't make a breaking change for this. I like being able to write <div />. I'm well aware that's invalid html; I just don't care.

React accepts it. You'd be following in pretty good cowpaths if you continued to accept it.

Nothingburger bug that'd make life harder. Self closing tags are very useful and prevent duplication. Even an eslint warning would be more annoying than this.

At the end of the day, does the proposed change mean we can't use <div /> (or self-close any other non-void HTML element) and must write <div></div> instead? Is that all?

It seems to be a small trade-off to align more closely with how HTML functions, whether we like it or not, and to avoid complicating Svelte (even if just a bit) by adding new configurations, documentation, and potential issues.

This turned into a discussion on syntactic sugar, and I understand the resistance. Svelte users, myself included, are quite sensitive to syntax changes and reluctant to give up even the smallest bit of convenience. But is it worth the cost of shifting from "it's just HTML" to "it's just HTML, but we treat X differently"?

But is it worth the cost of shifting from "it's just HTML" to "it's just HTML, but we treat X differently"?

As said above, this syntax is used widely probably in no small part because React allows it. If anything I'd say drop the

"it's just HTML"

line. With Signals / Runes Svelte is finally gaining reactivity on par with (or really, better than) React. "It's just html" is honestly the least interesting, least important part of Svelte for the typical user.

The comments on this thread are getting progressively less useful and more off-topic, and a lot of people are straight-up missing the point (or misunderstanding the proposal), so I'm going to lock it at least for now.

As is often the case with these sorts of changes, a vocal minority opposes it, but the emoji reactions tell the true story — most people agree that this is something we should do.

The reason this took so long to surface is that self-closing tags are rare. By extension, this change will be a lot less disruptive than some of you seem to imagine. IDEs already tend to do the right thing anyway — it's pretty common that if you write <div>, a </div> will be automatically inserted. Hell, even the Svelte 5 preview works that way. In other words it's easier to do the right thing than the wrong thing!

Side-note, but if your markup contains empty <div> elements in the first place... well, that might be something to look at more closely.

To update your components en masse, you can use the following command:

npx svelte-migrate self-closing-tags

This will prevent Svelte 5 warning you to replace <div /> with <div></div> etc. If you're using Prettier with the Svelte plugin, you will need to update to the latest version or it may turn <div></div> back into <div />.