Using overtype as a progressive enhancement.

[rouilj]

I am looking at using overtype to enhance an existing textarea in a form. My intended markup would look like (using the web component version):

<form>
[other inputs/checkboxes etc. for the form]

<overtype-editor
  value="# Hello OverType!"
  theme="solar"
  height="300px"
  toolbar>
<textarea name="@note" id="changenote" class="..." wrap="hard" rows="20" cols="80"></textarea>
</overtype-editor>
</form>

where the textarea is in the light dom. If the overtype-editor fails to load or initialize
I get the fallback textarea.

Ideally the web component would inherit the textarea into a (named??) slot and use
it directly. The developer may need to unset/reset any css textarea styles using:

textarea {...}

overtype-editor:defined textarea {
all: initial; /* or maybe revert with optional !important */
}

or guard them using (not sure the syntax is correct):

overtype-editor:not(:defined) textarea.someclass { ...}

This way the overtype editor doesn't need to worry about how the form is
constructed and the textarea just submits like expected.

The only way I can see to actually submit the result of the overtype editor
with a form is to add a change event handler for the web component and
copy the value into a hidden textarea. Alternatively add a blur handler and
copy on blur.

Is this the only way to get the textarea used by overtype to be submitted by
a wrapping form? I don't see a name property supported by the web component
that would be assigned to the textarea. Am I missing some part of the doc that
describes how to incorporate overtype in a form? Having to execute a copy on every
change seems to duplicate the work of overtype needlessly.

Thanks.

-- rouilj

[panphora]

Closing this for now, but the use case is real and the door isn't locked.

What you're asking for is form-associated custom element semantics: `` participates in form submission like a native input would, and the slotted `<textarea>` either gets adopted as the underlying input or serves as a no-JS fallback.

Why this is a substantial change rather than a small option:

• Web components need `static formAssociated = true` plus `ElementInternals` plumbing (`setFormValue()`, `setValidity()`, restore/clear callbacks)
• The component would need to either adopt the slotted `<textarea>` (replacing the one it currently creates internally) or mirror its value/name onto a hidden input — each path has visible behavior tradeoffs
• Validation, `required`, `maxlength`, `form` attribute, `disabled`, `readonly` all need to behave the way native textareas do
• Server-side form fallback when JS fails is a separate concern that touches the SSR/rendering story too

Today's workaround (mirror to a hidden `<textarea name="note">` on `onChange`) is two lines and works in production. Not elegant, but unblocks form integration:

```html

<textarea name="note" hidden></textarea> <script> const ed = document.querySelector('#editor'); const hidden = document.querySelector('textarea[name="note"]'); ed.addEventListener('change', () => { hidden.value = ed.value; }); </script> \`\`\`

If someone wants to draft a proposal that scopes specifically to form-associated custom element support — slot adoption strategy, value/name mirroring, validation passthrough — please open a fresh issue with that proposal and reference this thread. We'd reconsider.

Thanks @rouilj for the detailed write-up.