Imagine a fictional museum notice page with a visitor-message panel beside a fixed ticket link. A staff member needs to change “West room closes at 4” while seeing the panel's real width. Only the message panel should become editable. Turning its outer container into the editor could also pull the ticket link and surrounding layout into the editing surface.
Mount on the message region
Give the editable region its own element:
<section class="visitor-panel">
<div id="visitor-message">
<p>West room closes at 4.</p>
</div>
<a href="/tickets">Book a ticket</a>
</section>
For a current npm-based installation with its required styles and license configured, this follows the official inline initialization shape:
import { InlineEditor, Essentials, Paragraph, Bold, Italic }
from 'ckeditor5';
const messageEditor = await InlineEditor.create({
root: {
element: document.querySelector('#visitor-message')
},
licenseKey: '<YOUR_LICENSE_KEY>',
plugins: [Essentials, Paragraph, Bold, Italic],
toolbar: ['bold', 'italic']
});
Replace the license placeholder with the configuration appropriate to your installation. Keep packages compatible and follow the setup for the installed version; older snippets may pass the source element as a separate argument. The example provides basic paragraph formatting, not the full page's layout or a saving service.
The ticket link remains outside #visitor-message. That boundary is easier to maintain when the application gives each editable region an explicit purpose. Do not mount another editor on the same element while the first instance is active.
Capture the document before removing the page region
Read the content from the initialized instance when the author saves:
const currentMessageHtml = messageEditor.getData();
Send that value through the existing authenticated save path for this notice. Show saved status after the operation succeeds, and keep the message visibly unsaved when it fails. Reading the element's DOM is not the documented substitute for getData(); the editing surface can contain editor-specific markup. Getting and setting data
For this notice, change the closing time from 4 to 3. Save, leave the page, and reopen the same notice record. The message must say 3 while the fixed ticket link remains unchanged. The floating toolbar's appearance does not establish that either storage or reopening works.
Destroy the instance when its region leaves the page
When a router or component removes the message region, complete the application's save or discard decision and then destroy the editor:
await messageEditor.destroy();
CKEditor's lifecycle guide documents initialization and destruction as asynchronous operations. Await destruction before creating a replacement on the same region. Remove your own button listeners and references as part of the component's cleanup too.
If several notices appear on one page, associate each instance with its own record identifier. A shared variable that always points to the last-created editor can make one notice's Save button capture another notice's text.
Check the panel at its actual reading width
Focus the message and check that the floating toolbar remains reachable beside the panel, including within any scrolling or clipped container. Move focus to the ticket link and confirm the page still has a clear keyboard route. Test the real narrow layout; editing inside the page exposes the same width constraints that the author is trying to judge.
The decoupled document-editor guide covers a different layout, where the application places a separate toolbar beside a document surface. For this inline notice, finish by reading the saved closing time in the visitor page with authoring controls absent, then follow the unchanged ticket link.