I understand that the HTML 5 spellcheck attribute works on any input, textareas, and editable divs. I want to get spellcheck to work with our wysiwyg editor, which uses a non-editable div with a hidden input field (for backwards compatability). Is there any trick to get the spellcheck attribute to work on a non-editable div?

Dani AI

Generated

Short answer: you can’t reliably force the browser’s built‑in spellchecker to mark text inside an element the browser does not treat as editable. The HTML spec and browser docs only consider editable text (form controls or nodes in an editing host) as checkable, and the spellcheck attribute is only a hint to the user agent. (html.spec.whatwg.org)

Practical approaches that actually work in the wild:

  • Prefer migrating the visible editor surface to a real editable host (contenteditable or a textarea). That lets the browser do underlines, language/dictionary selection, and native context-menu corrections without shipping dictionaries yourself.
  • If you must keep the current non‑editable surface, a common hack is to make it focusable (tabindex) and toggle contentEditable (and spellcheck=true) on focus, then optionally set it back on blur. That triggers the native checker in many browsers. Example pattern:
const el = document.querySelector('.editor-surface');
el.tabIndex = 0;
el.addEventListener('focus', () => { el.contentEditable = 'true'; el.spellcheck = true; });
el.addEventListener('blur',  () => { el.contentEditable = 'false'; /* or leave editable in some UAs */ });

This workaround is widely used but behaves inconsistently between engines (Chrome vs Firefox) and sometimes needs a user interaction to trigger the underlines. (stackoverflow.com)

If a refactor is impossible, the reliable alternatives are: mirror the text into a (possibly offscreen) contenteditable element that gets checked and render overlays for suggestions, or run a server/JS spellchecker (Hunspell/LanguageTool or a cloud service) and surface corrections in your own UI. There is no standardized JS API to call the browser’s native spelling engine or to embed its suggestion UI into a custom menu, so editor-level integration will require either using the browser UI or implementing your own suggestion flow. ’s caution about heavy third‑party client dictionaries is valid — server checking or lightweight integrations are usually preferable. (drupal.org)

Recommended Answers

All 6 Replies

Code rum, thank you for the link, it seems like it has potential, but there are a few things I don't like about it:

  • I would never implement someone else's obfuscated, third-party code, regardless of whether it's serverside or clientside
  • It's very, very heavy, as it implements its own clientside dictionary

Isn't a non-editable div read only?

Maybe put the spellchek attribute on the hidden input field?

The hidden input field is only 1 pixel in size.

Yes, non-editable divs are read only.

I think that with few adaptations of the existing code, the spellchecker can be made to reflect errors on any other content; editable or non-editable.

In fact, ever since DHTML introduction or the day that Gen-4 browsers came out, there's nothing non-editable in HTML. HTML is alive ever since Live Script came to existence, and now that we have DOM we have almost everything we need to be truly productive.

Of course, the dynamic changes will not affect the source - but they'll be clearly visible to the client.

I think that with few adaptations of the existing...
...

sorry, my bad read.

for the real question -it turns out as if
its practically impossible to reuse the browser spell-checker plugin from a page.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.