SpellCheckCustomDictionary

[bkardell]

WebKittens

@annevk @marcoscaceres

Title of the proposal

SpellCheckCustomDictionary

URL to the spec

https://github.com/Igalia/explainers/blob/main/spell-check-dictionary/README.md

URL to the spec's repository

https://github.com/Igalia/explainers/

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

w3ctag/design-reviews#1191

Mozilla standards-positions issue URL

mozilla/standards-positions#1384

WebKit Bugzilla URL

No response

Radar URL

No response

Description

@ziransun has a prototype in chromium for Igalia, work sponsored by Bloomberg Tech. We want to get a good sense of positions from WebKit and Mozilla.

[marcoscaceres]

Quick personal feedback: the explainer seems to be missing discussion on third-party iframes access to this API. It seems to be short on abuse mitigation (e.g. what if the site tries to add 10 million words, while simultaneously removing 1 million words?). How are collisions with OS dictionary words managed?

Give the TAG’s feedback, and the relative simplicity of what’s being proposed, it might be good to outline a rough spec based on the Chrome prototype, specifically if you’ve gathered some experience integrating with at least macOS (though experience gained on other platforms would also help).

From an accessibility perspective, the spec seems to lack guidance on distinguishing between OS provided vs site provided suggestions. Like, what if a site floods the dictionary with “a buy product”, “b buy product”, … “z buy product”.

What’s the use case for removing words? I can see the obvious one, but does the ability to remove words incentivize too much flexibility? A strong use case is not presented in the explainer.

[ziransun]

Quick personal feedback: the explainer seems to be missing discussion on third-party iframes access to this API.

In the design doc we have a couple of paragraphs ( final two in the first page) talking about the iframes case. Does it answer the question?

It seems to be short on abuse mitigation (e.g. what if the site tries to add 10 million words, while simultaneously removing 1 million words?).

Thanks for bringing this up. Sorry that I missed this point from the TAG review comments.
Since we can add/remove a bulk of words in one go, we probably do need to set a maximum word limit. It's hard to specify a number though. In Chromium, I noticed that the we have a maximum syncable word limit for custom dictionary (around 10,000 words) - I wonder if this sounds reasonable?

How are collisions with OS dictionary words managed?

This dictionary is an addition to the existing dictionaries. "duplicate entries" is possible. The main use scenario is to suppress misspelling errors - I would assume that most entries for the dictionaries are the words that are not in the existing dictionaries?

[ziransun]

From an accessibility perspective, the spec seems to lack guidance on distinguishing between OS provided vs site provided suggestions. Like, what if a site floods the dictionary with “a buy product”, “b buy product”, … “z buy product”.

The explainer stated that the API does not aim to cover spell-check suggestions. However, the dictionary could end up being used to provide suggestions. The suggested word list is invoked for a misspelled word after spelling check of the whole word against dictionaries. Normally there is a up-limit for the number of suggested words (normally 3-5 etc..). The custom dictionary is designed to store individual, single word so it doesn't support words with spaces.

What’s the use case for removing words? I can see the obvious one, but does the ability to remove words incentivize too much flexibility? A strong use case is not presented in the explainer.

Use case for removing words has also been discussed at mozilla/standards-positions#1384 (comment).

[marcoscaceres]

Speaking in my personal capacity:

The explainer says entries "may include spaces or special characters, to accommodate multi-word proper nouns and hyphenated terms." Your response says it's "single word" and "doesn't support words with spaces." Which is authoritative?

If the intent is to restrict to single words, the spec also needs to define what counts as "whitespace." ASCII space (U+0020) is one of many Unicode whitespace characters — including invisible ones like U+200B ZERO WIDTH SPACE — and different OS tokenizers disagree on word boundaries. Without a definition (and Unicode normalization), the "single word" constraint isn't enforceable.

On implementability: in WebKit's current iOS implementation, both learnWord and ignoreWord are notImplemented(). On macOS, learnWord routes to NSSpellChecker learnWord:, which adds to the shared spell checker dictionary. The document-scoped alternative, ignoreWord:inSpellDocumentWithTag:, only suppresses misspellings — it doesn't add words for suggestions. On Linux (WebKitGTK/WPE), learnWord calls enchant_dict_add() which writes to the persistent personal word list; ignoreWord calls enchant_dict_add_to_session(), which is transient.

The per-document lifecycle guarantee requires a teardown step — the browser must track added words and undo them on document unload. The spec doesn't define that algorithm. What happens on crash or bfcache restore? On platforms where the only available API writes to a persistent dictionary, is "per-document" achievable at all, or is cleanup best-effort?

One more thing: this is still in the Igalia personal repo rather than a formal standards or incubation group. Has there been any thought about venue?

[ziransun]

Speaking in my personal capacity:

The explainer says entries "may include spaces or special characters, to accommodate multi-word proper nouns and hyphenated terms." Your response says it's "single word" and "doesn't support words with spaces." Which is authoritative?

If the intent is to restrict to single words, the spec also needs to define what counts as "whitespace." ASCII space (U+0020) is one of many Unicode whitespace characters — including invisible ones like U+200B ZERO WIDTH SPACE — and different OS tokenizers disagree on word boundaries. Without a definition (and Unicode normalization), the "single word" constraint isn't enforceable

Brian and I were just discussing about about updating the explainer - the custom dictionary behaves just as the user custom dictionary. Sorry about the confusion.

[marcoscaceres]

Right, but how does the custom dictionary work when OS-level widgets end up presenting/suppressing the suggestions, and those dictionaries are system global? That means that words added by a site would end up in other apps on the OS, not just the website's inputs. That seems confusing if random sites can just add words to the system dictionary. Have you thought about restricting this to only installed web applications?

[bkardell]

@marcoscaceres

I have created a draft PR demonstrating our thinking in WebKit WebKit/WebKit#62820 for discussion

Here's a test file which contains a box of Vogon poetry from HHGG and a dictionary of words to say "these aren't spelling errors" - none of them are, but they aren't added to the system dictionary (via testing in the minibrowser)

test.html