🦋 Changeset detected

Latest commit: 44ac3a9

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Playground

pnpm add https://pkg.pr.new/svelte@16481

I think value act a bit differently than what defaultValue does on the client but I'll have to check...however this doesn't fix the reported bug. defaultValue and defaultChecked: even without spreading props defaultValue and defaultChecked doesn't get SSRd (which also make me think that it was a conscious decision to exclude them in the first place...so maybe the fix is to exclude them instead of converting them).

Also this should also be applied to textarea no? Thanks for taking a stab at this.

The defaultValue not getting SSR'd seems like an issue as well, since the SvelteKit docs recommend writing forms with support for no JavaScript. Since the value isn't SSR'd into the HTML template, users without JavaScript will have to fill out the entire form, which is especially annoying for update forms.

The defaultValue not getting SSR'd seems like an issue as well, since the SvelteKit docs recommend writing forms with support for no JavaScript. Since the value isn't SSR'd into the HTML template, users without JavaScript will have to fill out the entire form, which is especially annoying for update forms.

I agree...but you can also do that with a value directly...I don't think this is an unnecessary fix, was just pointing out that converting them to value and checked might not yield the desired result (I think there's some slight change in behaviour when you do so)

Unfortunately, value doesn't work if you use bind:value.

Also this should also be applied to textarea no?

I don't believe so - textarea doesn't support a value attribute in its markup.

According to specs we have:
prop defaultValue <-> attr value
prop value <-> input's current value with initial value of attr value

So, defaultValue should SSR into the value attribute. But into what should this SSR?:

<input value="foo" defaultValue="bar">

because they both set the same attribute value. I think value should take precedence in this case for better UX in no-JS case.

<input value="foo" defaultValue="bar">

I would expect this to SSR into <input value="bar"> and the value to be set to "foo" in JS.

But it can be done only if JS is enabled.
Plus, somebody can do

<input bind:value defaultValue="">

to allow resetting a pre-filled form into an empty one.

I've pushed the change, which will now ignore defaultValue/defaultChecked if the non-default equivalent is set.

It seems that this doesn't entirely work - the hydration emits remove_input_defaults, which removes the value/checked attributes. How should I pass in the information so as not to remove them?

But it is set back in the following attribute_effect, isn't it?

Only when the props update after the initial hydration.