Rich text editor form examples. Three ways to post it

Every rich text editor form example below rests on one fact, and it is the fact that makes this editor easy to integrate rather than merely possible. The textarea never stops being the form field. The editor is progressive enhancement over it, not a replacement for it.

So whatever your existing code does with that field keeps working. Nothing is submitted differently, nothing is serialized differently, and no server-side handler changes.

The value is written back on every keystroke

This is the detail that decides whether an integration is straightforward or fiddly. The textarea's value is updated as the visitor types rather than when the form is submitted.

That matters because most real integrations never submit the form at all. An autosave, a preview pane, a character counter and a framework binding all read the field long before anyone presses a button. If the value only appeared at submit time, every one of those would need a special case.

A rich text editor form with no JavaScript

A plain HTML form needs nothing added. Mark up the textarea, and the field posts what it always posted.

<script src="https://cdn.enterrahost.com/enterraedit/v1/enterraedit.min.js"></script>

<form method="post" action="/contact">
  <input name="email">
  <textarea name="message" data-enterraedit data-mode="comment"></textarea>
  <button>Send</button>
</form>

On the server, $_POST['message'] arrives as <p>Hello <strong>there</strong></p>. If your handler already stores the field, it stores HTML now, and that is the only change to think about.

When the field is plain text

A contact form textarea usually holds text rather than markup, and the editor handles that rather than mangling it. If the source has no block-level HTML, newlines become paragraphs and angle brackets are escaped instead of being parsed as tags.

So a message reading Hi there, on one line and This is a <tag> on the next becomes two paragraphs, with the brackets preserved as text. Nothing a visitor typed is swallowed as markup, which is the failure mode that makes people distrust rich text editors on contact forms.

Posting without submitting the form

For an autosave or an AJAX submit, read the field like any other input. It is a real textarea and a real form, so FormData works without a shim.

fetch('/api/ticket', { method: 'POST', body: new FormData(form) });

No editor API appears in that line, which is the point. Anything that already reads the form keeps reading the form.

HTML for one destination, text for another

Support and ticketing systems are the case where you need both forms of the content. The field holds HTML, and some destinations want plain text.

const html = ta.value;      // <p>Hello <strong>there</strong></p>
const text = ed.getText();  // "Hello there", for plain destinations

Use the field when the receiving system accepts markup and the plain-text method when it does not. Sending HTML to a mail relay that insists on text is the mistake this avoids.

Frameworks, and writes that come from outside

Sync runs in both directions, which is what makes the editor safe to use inside a reactive framework.

Typing updates the textarea's value. Assigning to that value updates the editor in return, because the prototype setter is patched once and dispatches a normal input event. That is the event frameworks already listen for, so a component that sets the value to clear or load a draft sees the editor follow rather than drift.

ta.value = '<p>Loaded from the draft</p>';   // the editor shows this
ta.value = '';                                    // so does clearing it

A framework binding that never touched an editor API therefore works, which is the difference between a drop-in and a component you have to wire up.

Two edge cases worth knowing about

A form reset restores the default value rather than emptying the field. That is what a reset does, and a lot of editors get it wrong by clearing the content instead. The editor follows the field, so it shows the default it was rendered with.

Validation still applies. The element keeps its name, stays a real textarea in the DOM, and a required attribute is enforced by the browser exactly as before.

Building a toolbar picker at runtime

If you want to offer a configuration interface rather than choosing a mode yourself, the key map is available as data.

EnterraEdit.ALL_KEYS;      // every key, in toolbar order
EnterraEdit.BUTTONS;       // { bold: { label, group, icon }, ... }
EnterraEdit.keysByGroup(); // grouped, ready for a picker
EnterraEdit.MODES;         // what each named mode includes

That means a settings screen can build itself from the editor's own map rather than hardcoding a list that goes stale the next time a button is added.

All of these examples use the same options as any other route, so the CDN tag and a bundled copy behave identically here.