Thanks for the comment! We will look at this. On Wednesday, October 14, 2026 at 4:01:33 PM UTC+1 Philip Jägenstedt wrote:
> Hi, > > I see that https://github.com/whatwg/html/pull/12590 is a draft with > seemingly no review of the actual spec text. If > https://github.com/WebKit/standards-positions/issues/646 is going to be > resolved as positive (it's not yet) then maybe you can entice a WebKit > contributor to carefully review the spec? > > In other words, I'd like to see some more effort to progress the spec here. > > Best regards, > Philip > > On Wed, Oct 14, 2026 at 12:09 PM Chromestatus < > [email protected]> wrote: > >> *Contact emails* >> [email protected], [email protected] >> >> *Explainer* >> https://github.com/Igalia/explainers/tree/main/spell-check-dictionary >> >> *Specification* >> https://github.com/whatwg/html/pull/12590 >> >> *Design docs* >> >> https://github.com/Igalia/explainers/tree/main/spell-check-dictionary >> >> https://docs.google.com/document/d/1ND1a1Z4i6kXMHqMwEyRkHSj5VVTWgX5Ya0aNLgVQYGw/edit?tab=t.0#heading=h.kmfizh6cwyy4 >> >> *Summary* >> Adds document.spellCheckCustomDictionary, which lets a page add words to >> and remove words from a per-document dictionary that the browser's spell >> checker consults alongside its built-in dictionaries. Matching words are no >> longer flagged as misspelled in that document, so sites with >> domain-specific vocabulary, such as product names, technical terms or >> proper nouns, can suppress false positives without asking users to edit >> their browser dictionary. The words last only for the document's lifetime >> and cannot be read back. >> >> *Blink component* >> Blink>Editing>Spellcheck >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EEditing%3ESpellcheck%22> >> >> *Web Feature ID* >> spell-check-custom-dictionary >> <https://webstatus.dev/features/spell-check-custom-dictionary> >> >> *Motivation* >> Spell checkers routinely flag words that are correct within a particular >> site but unknown to general dictionaries. Examples include: - A Pokémon >> wiki containing names like Pikachu or Charmander. - A financial analysis >> dashboard referencing company‑specific product names or tickers. - A >> medical or scientific tool using specialized terminology. False positives >> in these contexts are distracting, misleading, and erode user trust. While >> browsers allow users to add custom words via browser settings panel, there >> is currently no way for pages to provide a custom dictionary >> programmatically that applies only within their own context in order to >> reduce those false positives. Authors need a way to treat domain‑specific >> words as “known” without requiring user intervention. >> >> *Initial public proposal* >> https://github.com/Igalia/explainers/tree/main/spell-check-dictionary >> >> *Search tags* >> spellcheck <http:///features#tags:spellcheck>, spelling >> <http:///features#tags:spelling>, custom dictionary >> <http:///features#tags:custom%20dictionary>, spellCheckCustomDictionary >> <http:///features#tags:spellCheckCustomDictionary>, addWords >> <http:///features#tags:addWords>, removeWords >> <http:///features#tags:removeWords> >> >> *TAG review* >> https://github.com/w3ctag/design-reviews/issues/1191 >> >> *TAG review status* >> Issues addressed >> >> *Goals for experimentation* >> None >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> This feature is purely additive. It doesn't change existing spell-check >> behaviour, so the compatibility risk to existing content is minimal. >> Interoperability risk is low severity - the only difference the user sees >> is red squiggles under the custom words if the feature is absent. >> >> *Gecko*: Neutral ( >> https://github.com/mozilla/standards-positions/issues/1384) >> https://github.com/mozilla/standards-positions/issues/1384#issuecomment-5997330337 >> >> *WebKit*: Positive ( >> https://github.com/WebKit/standards-positions/issues/646) >> https://github.com/WebKit/standards-positions/issues/646#issuecomment-6054915329 >> >> *Web developers*: Positive - Bloomberg requested this feature and >> sponsors Igalia's work on it. - Related demand elsewhere: * whatwg/dom#547: >> a developer with a canvas-based editor asks to add page-specific words to >> the browser spellchecker: >> https://github.com/whatwg/dom/issues/547#issuecomment-3969379684 * >> Electron added session.addWordToSpellCheckerDictionary() so apps can add >> custom words: >> https://www.electronjs.org/docs/latest/api/session#sesaddwordtospellcheckerdictionaryword >> >> >> *Other signals*: >> >> *Ergonomics* >> The API is a minimal write-only pair (addWords/removeWords) taking string >> sequences, batched to match caller intent. It composes cleanly with >> existing spellcheck; no interaction with other high-usage APIs. >> Deliberately no read API, to keep the dictionary unobservable. >> >> *Activation* >> The API should be easy to adopt: one call and no setup is needed. It is >> not polyfillable. >> >> *Security* >> The API holds transient per-document state. There is no network exposure, >> and it neither reads nor modifies OS or browser dictionaries. It is >> per-frame based. the word set is owned by a single Document. Every frame >> gets its own independent set. The set is discarded when the document goes >> away. Input is validated with empty/whitespace-padded/ill-formed-UTF-16 >> words rejected and size-capped to prevent resource abuse. The API is >> write-only by design. >> >> *WebView application risks* >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> None expected. This feature is purely additive. It adds a new interface >> and a new Document attribute, doesn't change or deprecate any existing API, >> and doesn't change spell-check behaviour for pages that don't call it. >> Existing WebView apps are unaffected. >> >> >> *Debuggability* >> The API is write-only to page script by design: JavaScript can't read the >> dictionary back, so it can't be used to probe the user's spell-check state. >> Developers and tests can still see what a page has added: - DevTools UI : >> Application > Frames > [frame] > Frame details has a "Spell check custom >> dictionary" section listing the words that frame's document has added. - >> CDP : the experimental command >> Page.getSpellCheckCustomDictionary({frameId}) returns a frame's words in >> sorted order. The DevTools UI uses it, and automation tools can call it >> directly. It isn't available to page script. - Automated testing: the web >> test mock spellchecker supports the API, so tests can check that added >> words are no longer marked as misspelled. Following the DevTools console >> policy, the API logs no console messages. >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> No >> Supported on Windows, macOS, Linux, ChromeOS, Android and Android >> WebView, with the known limitations on Android and WebView listed below. >> Not available on iOS. The API (document.spellCheckCustomDictionary, secure >> contexts only) and the word set are implemented entirely in Blink. Custom >> words are applied as a renderer-side filter over the spell-check results >> the renderer receives, so the same filter works with every spell-check >> backend: Hunspell on Linux and ChromeOS, NSSpellChecker on macOS, the >> Windows spell checker, and the Android platform spell checker. Any >> differences between platforms come only from what the underlying spell >> checker reports. Known limitations: - Android and Android WebView: >> misspellings surfaced by the IME/keyboard during composition are drawn as >> IME suggestion markers and never travel through the spell-check result >> path, so this API cannot suppress them. Misspellings reported through the >> browser's spell-check pipeline are suppressed correctly. - Android WebView: >> WebView disables spell checking by default (AwSettings), so there is >> nothing to check — and nothing to suppress — until the app or page opts in >> (e.g. spellcheck="true"). This is pre-existing WebView behaviour rather >> than a limitation of this API; with spell checking enabled, behaviour >> matches Android. - iOS: Chrome on iOS is built on WebKit and does not run >> Blink, so the API is not exposed. Windows, macOS, Linux and ChromeOS are >> fully supported. >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> No >> There are no WPTs yet. The tests for the API surface are currently in >> Chromium's wpt_internal, which is Chromium-only. We plan to upstream the >> API-surface tests to WPT alongside the spec PR. The API's only effect is >> whether a word gets a spelling marker. Spelling markers depend on the >> platform spellchecker and aren't observable from script, so there's no >> portable way for a WPT to assert them. Existing spellcheck features (e.g. >> the spellcheck attribute) have the same limitation. Chromium-side coverage >> of that effect: - Web tests that read spelling markers through the mock >> spellchecker. - Blink unit tests for input validation and word limits. - >> components/spellcheck for applying the filter to the hybrid, platform and >> spelling-service results, lifetime across navigation, and the UMA metric. - >> Manual tests in wpt_internal/spell-check-custom-dictionary/ for checking >> the squiggles visually on each platform, including WebView. >> >> *DevTrial instructions* >> >> https://github.com/Igalia/explainers/blob/main/spell-check-dictionary/DevTrial_instructions.md >> >> *Flag name on about://flags* >> *No information provided* >> >> *Finch feature name* >> SpellCheckCustomDictionaryAPI >> >> *Rollout plan* >> Will ship enabled for all users >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://issues.chromium.org/issues/428005649 >> >> *Availability expectation* >> At launch the API will be available in Chromium-based browsers on >> Windows, macOS, Linux, ChromeOS, Android and Android WebView. It will not >> be available in Chrome on iOS, which uses WebKit. Mozilla's position is >> neutral (https://github.com/mozilla/standards-positions/issues/1384). >> WebKit engineers have reviewed the proposal and reported no major issues( >> https://github.com/WebKit/standards-positions/issues/646). Neither >> engine has announced implementation plans. >> >> *Adoption expectation* >> This is a feature requested by a client. we'd expect it will be used >> pretty soon once launched. Use scenarios include sites and editors with >> domain-specific vocabulary, such as wikis, technical documentation, CMS and >> rich-text editors, and medical or financial tools, to suppress >> false-positive misspelling marks. Because the feature isn't needed for >> things to work (without it, users just see extra squiggles), we expect >> sites to adopt it gradually through feature detection rather than all at >> once. >> >> *Adoption plan* >> - MDN documentation (https://issuetracker.google.com/issues/568348294) - >> The explainer, DevTrial instructions, and a demo page. - Tooling: DevTools >> shows a frame's custom words in Application > Frames > Frame details, and >> the experimental CDP command Page.getSpellCheckCustomDictionary makes them >> available to automated tests. - Continuing the WHATWG and >> standards-position discussions with Mozilla and WebKit to improve >> availability across browsers >> >> *Non-OSS dependencies* >> >> Does the feature depend on any code or APIs outside the Chromium open >> source repository and its open-source dependencies to function? >> No. The word set and the suppression filter are entirely in >> Blink/Chromium. >> >> *Estimated milestones* >> Shipping on desktop 159 >> DevTrial on desktop 153 >> Shipping on Android 159 >> Shipping on WebView 159 >> >> *Anticipated spec changes* >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). >> The spec PR (https://github.com/whatwg/html/pull/12590) is under review >> at WHATWG and the proposal is at Stage 2 ( >> https://github.com/whatwg/html/issues/12388). We don't expect changes to >> the name or shape of the shipped API. The open feedback comes from the W3C >> i18n WG review (https://github.com/w3c/i18n-actions/issues/222). It >> raises two areas including language metadata and matching rules that may >> lead to later, backward-compatible changes. In both cases the compatibility >> risk is low: changes would be additive or would only reduce false-positive >> spelling marks. >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/6185007701557248?gate=4929988981424128 >> >> *Links to previous Intent discussions* >> Intent to Prototype: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/687a1d04.170a0220.2dad83.0168.GAE%40google.com >> >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6acf54ea.6e0b2b3a.151e33.12ef.GAE%40google.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6acf54ea.6e0b2b3a.151e33.12ef.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b947d811-c9a1-4a3a-b27d-188aced57ff7n%40chromium.org.
