Svelte 5: Undocumented breaking changes

[Conduitry]

Describe the bug

There are a number of breaking changes that have not made their way into the official list of breaking changes yet. I'm creating this issue to track them. Maintainers: Edit this post as we come across new ones, and check them off as we have PRs documenting them.

• breaking: preserve slots inside templates with a shadowrootmode attribute #10721
• breaking: don't allow children in svelte:options #11250
• Svelte 5: Nested form control bindings causes runtime error #11941

Reproduction

https://svelte-5-preview.vercel.app/docs/breaking-changes

Logs

No response

System Info

-

Severity

annoyance

[frederikhors]

@Conduitry I would add what I mentioned here: #11431.

[Conduitry]

Changes that only occur in runes mode are not the sort of changes we're concerned with here. Breaking changes are instances where a user upgrades from Svelte 4 to Svelte 5 and their existing component starts to behave differently.

[Conduitry]

Again, no, not for the purposes of documenting what the breaking changes are for people who try to use their components as-is when upgrading from Svelte 4 to Svelte 5.

[Serator]

https://svelte.dev/docs/element-directives#bind-property

Order doesn't matter now, which is a good thing!

• Svelte 5 (runes) - if a field is changed once, we will see the new value in the console
• Svelte 5 (no runes) - if a field is changed once, we will see the old value in the console

[theetrain]

A follow up to #11400 (comment):

I see that :where is only applied to Nested CSS, and not all scoped CSS. Current documentation reads (emphasis mine):

To avoid issues caused by unpredictable specificity changes, scoped CSS selectors now use :where(.svelte-xyz123) selector modifiers alongside .svelte-xyz123 (where xyz123 is, as previously, a hash of the <style> contents). You can read more detail here.

And the linked PR's phrasing strongly implies :where() is applied everywhere. Should the documentation be rephrased to account for this?

Right now this:

<style>
  button {
    color: red;
  }
  button {
    & span {
      color: green;
    }
  }
</style>

compiles to this:

button.svelte-1ya7ade {
  color: red;
}
button.svelte-1ya7ade {
  & span:where(.svelte-1ya7ade) {
    color: green;
  }
}

Demo.

[dummdidumm]

I don't fully understand what you're asking for. Could you give an example about how you want to rephrase this?

[theetrain]

Perhaps like this:

-To avoid issues caused by unpredictable specificity changes, scoped CSS selectors
+To avoid issues caused by unpredictable specificity changes, nested CSS selectors
now use `:where(.svelte-xyz123)` selector modifiers alongside `.svelte-xyz123`
(where `xyz123` is, as previously, a hash of the `<style>` contents).
+Top-level selectors will continue to be scoped without the use of `:where()`.

Key difference is nested versus only scoped.

[TehBrian]

https://svelte.dev/docs/element-directives#bind-property

Order doesn't matter now, which is a good thing!

• Svelte 5 (runes) - if a field is changed once, we will see the new value in the console

• Svelte 5 (no runes) - if a field is changed once, we will see the old value in the console

Out of curiosity, how would one emulate that behavior (using both the old value and the new value) in Svelte 5? Storing the old value as a variable?

[dummdidumm]

Closing since there hasn't come anything in a while

[TehBrian]

Just to throw it out there, I'm still waiting on a response to my curiosity about the recommended "best practice" to using the previous input value, found here.

[Rich-Harris]

bind:value is just syntactic sugar for {value} oninput={(e) => value = e.currentTarget.value}. So your example becomes this

<script>
  let name = $state('world');
</script>

<h1>Hello {name}!</h1>

<input
  value={name}
  oninput={(e) => {
    console.log('Old value:', name);
    name = e.currentTarget.value;
    console.log('New value:', name);
  }}
>

[TehBrian]

Very reasonable, thank you!