Scratch-blocks: Deleting the contents of a number field and clicking away leaves it empty

[rachel-fenichel]

Expected behaviour: it returns to "0"
Clicking on a block to run it after this acts as though there were a 0 there.

[tmickel]

Why is this the expected behavior - seems consistent with Scratch?

[rachel-fenichel]

Huh, I guess it is.

It feels super weird to me to have "move by " when we know that "move by 0" is the correct thing to coerce it to after validation. Feel free to close if the goal is purely consistency with current scratch for this.

[tmickel]

Hmm, yeah. no a strong preference from me, we can discuss

[PullJosh]

I'd agree that a zero makes more sense. I'm having a hard time envisioning a situation where "move by _" would make more sense than "move by 0" (seeing as a blank will be evaluated as a zero).

[towerofnix]

Yep.

The only place where I can only see empty number input slots being particularly useful is actually in Snap_!_, where "run { move (_) steps } with inputs (45)" behaves like "move (45) steps".. and that's obviously not applicable to Scratch 3.0!

[thisandagain]

In the case of numeric inputs this should act the same as the sprite info area: clicking outside of the block or confirming via "enter" should transform the empty value to the default value. We aren't sure if "default value" is correct or if it should be "0" but we'll try this for now.

/cc @carljbowman

[mrjacobbloom]

I'm not sure this discussion should end yet (even though nobody's touched it for a while)... sure scratch-blocks matches 2.0's functionality, but I think there's some value in exploring how to portray what value empty number (and boolean?) inputs return. This tripped Rachel up and I wouldn't be surprised if kids would be caught off-guard too (unless you've already tested this and they don't care 😛)

For whatever reason I keep thinking about grayed-out input placeholders as a solution to this. It doesn't look like there's a value in the input but there is some indication of what the block is doing