`textarea_` function signature forces usage of controlled inputs

[mtamc]

Describe the bug

As of a4fcfe8, the function signature for textarea_ is now textarea_ :: [Attribute action] -> MisoString -> View model action, where the second parameter being used for the textarea's value attribute.

-- | [\<textarea\>](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/textarea)
--
-- @
-- textarea_ [ id_ "txt" ] 
--    """
--    text goes here
--    """
-- @
--
-- @since 1.9.0.0
textarea_ :: [Attribute action] -> MisoString -> View model action
#ifdef VANILLA
textarea_ attrs txt = nodeHtml "textarea" attrs [ text txt ] 
#else
textarea_ attrs txt = nodeHtml "textarea" (textProp "value" txt : attrs) []
#endif

Passing in e.g. the empty string "" as parameter causes input to be wiped every keystroke:

textarea_new_fn_signature_bug-2026-04-13_17.43.19.webm

This leaves us forced to use a controlled input (passing in this parameter as the value we hold in the component Model), which has the very problematic bug #272 - further repro steps in my comment, but I'll repost the video demo:

textarea_cursor_bug-2026-04-13_16.53.23.webm

Some useful leads on how Elm fixed their equivalent of #272 : elm/virtual-dom#138 (comment)

Other thread with potential fixes and workarounds: elm/html#105 (comment)

To Reproduce

• Insert a textarea_ with the empty string as its second argument
• Try typing, input gets wiped every character
• Insert a textarea_ with the Model field where you store user input as the textarea_'s second argument
• Try typing fast in the middle of existing input, the cursor gets teleported to the end of the textarea

Expected behavior

• Restore user choice between controlled and uncontrolled inputs

AND/OR

• Fix controlled input bug where typing fast in the middle of existing text causes the cursor to jump to the end of the textarea

Desktop (please complete the following information):

• OS: Ubuntu
• Browser: Chrome, Firefox, Vivaldi
• Version: Chrome 137.0.7151.119, Firefox 149.0.2, Vivaldi 7.3.3635.12

Smartphone (please complete the following information):
Not tested

[dmjio]

So, this isn't a bug per se, but it does differ from Elm. The way value_ (and checked_) work is a little bit different. We set .value on each diff to ensure the view state is always in sync with the UI element. So textarea_ [ onInput Changed, value_ "" ] setting its value to an empty string is by design (currently), even if no model changes have occurred.

We have helper functions like optionalAttrs and optionalVoidAttrs to conditionally set value_ and checked_.

Here is an example of its usage in miso-from-html to clear the textarea by setting value_ conditionally. Note, we could have also used setValue to clear the value from the update function.

Here is another example:

viewModel :: Model -> View Model Action
viewModel x = optionalVoidAttrs H.textarea_ [ H.onInput Changed ] (MS.length (x ^. val) == 4) [ P.value_ "" ]

^ the above code will reset the value_ to be an empty string if the input length exceeds length 4.

This requires this PR (which changes textarea_ to only have a child attribute list).

#1497

Regarding the race condition caused by setting the value in response to onchange events. That is described nicely here.

I don't think in general it is a good idea to set the value of the input or textarea to the result of onchange. It's unnecessary because the target.value is already set on the model, and the browser has already updated the UI element. So I'd recommend using optionalAttrs to set value in view, or setValue in update.