Welcome to Vanilla Breeze
This bell pulls live notifications from /go/notify/messages — the same contract documented at /docs/concepts/service-contracts/. Static articles like this one are the no-JS / no-backend fallback.
spellcheck
Enable or disable browser spell-checking on editable content. Disable it for code editors, technical identifiers, and fields where red underlines create noise.
Overview
The spellcheck attribute controls whether the browser runs its built-in spell-checker on editable content. When enabled, misspelled words are underlined (typically with a red wavy line), and the user can right-click to see suggestions.
Applies to: <input> (text types), <textarea>, and any element with contenteditable
Values
| Value | Behavior |
|---|---|
true | Spell-checking is enabled. Misspelled words are underlined. |
false | Spell-checking is disabled. No underlines appear. |
| (not set) | Inherits from the parent element. If no ancestor sets it, the browser uses its default (typically enabled for textareas and contenteditable, varies for inputs). |
Basic usage
<!-- Enable spell-checking (the default for most text inputs) --><textarea spellcheck="true" rows="4">Check my speling here.</textarea> <!-- Disable spell-checking --><textarea spellcheck="false" rows="4">const x = myFunc();</textarea>When to Disable Spell-Checking
The default spell-checker works well for prose, but it creates visual noise on content that is not natural language. Disable it for:
- Code editors: Programming syntax triggers false positives on nearly every line
- Username and handle fields: User-created names are not dictionary words
- Product codes and SKUs: Alphanumeric identifiers like
WX-4829-BLK - Technical identifiers: API keys, serial numbers, license keys
- URL and path fields: File paths and URLs are not prose
- Email address fields: Addresses like
[email protected]trigger underlines
Disabling for technical fields
<!-- Code input: disable spellcheck to avoid red underlines on syntax --><label for="css-input">Custom CSS</label><textarea id="css-input" spellcheck="false" rows="6" placeholder=".my-class { color: rebeccapurple; }"></textarea> <!-- Username field: proper nouns and handles are not dictionary words --><label for="handle">Username</label><input type="text" id="handle" spellcheck="false" autocomplete="username" />Inheritance
The spellcheck attribute inherits from parent elements. Set it on a container to control all editable descendants at once, then override on individual fields as needed.
Inheritance and overrides
<!-- Parent sets spellcheck="false", children inherit it --><form spellcheck="false"> <label for="sku">Product SKU</label> <input type="text" id="sku" /> <label for="serial">Serial Number</label> <input type="text" id="serial" /> <!-- Override: enable spellcheck on just the description --> <label for="desc">Description</label> <textarea id="desc" spellcheck="true" rows="3"></textarea></form>Contenteditable Elements
Spell-checking also works on elements with contenteditable. This is particularly useful for rich text editors where you want spell-checking on prose but not on embedded code blocks.
Contenteditable with spellcheck
<!-- Spellcheck on a contenteditable region --><div contenteditable="true" spellcheck="true"> Type here and misspelled wrods will be underlined.</div> <!-- Code block: no spell-checking --><pre contenteditable="true" spellcheck="false"><code>function greet(name) { return `Hello, ${name}!`;}</code></pre>Accessibility
- Leave it enabled for prose fields. Spell-checking helps all users, including those with dyslexia, catch errors before submission.
- Screen readers do not announce spell-check underlines. Users relying on assistive technology will not know a word is flagged unless they use the context menu.
- Avoid disabling globally. Only disable on fields where the content is inherently non-prose. A blanket
spellcheck="false"on the entire page removes a useful writing aid.
Limitations
- Browser dictionaries vary: Each browser ships its own dictionary. A word flagged in Chrome may be accepted in Firefox and vice versa.
- No custom dictionary API: There is no standard way to add domain-specific terms (medical, legal, technical) to the browser dictionary. Users must add words one at a time via the context menu.
- Timing varies: Some browsers check on focus, others on blur, and others continuously while typing. The attribute controls whether checking happens, not when.
- Suggestion UI is browser-controlled: You cannot customize the appearance of underlines or the suggestion popup.
- No programmatic access: JavaScript cannot read which words are flagged or trigger a spell-check pass.
See Also
contenteditable— make any element editableautocorrect— control automatic text correction on mobileautocapitalize— control automatic capitalization on mobile keyboardslang— declare the language so the browser uses the correct dictionary