Dom: Proposal: Spellcheck API

[Ginden]

Purpose: allow websites to check spelling according to browser rules by JavaScript API with results similar to spellcheck.
Concerns: user defined words allows fingerprinting, raising privacy issues.

API:

navigator.spellchecker(language: DOMString) => Promise.<Spellchecker>;

Valid implementation can always return rejected promise (eg. no in-browser dictionary).

Valid implementation can (should?) ask user to allow access to user-defined dictionary.

class Spellchecker {
    isValidWord(word: DOMString) => Promise.<Boolean>;
    isGramaticallyValid(text: DOMString) => Promise.<Boolean>;
    validateText(text: DOMString) => Promise.<Array.<SpellcheckingRangeResult>>
}

class SpellcheckingRangeResult {
    int start; // Codepoint or character number?
    int end; // Codepoint or character number?
    enum('ortography', 'grammar', 'other') type; 
    dictionary details; // Implementation-specific details. 
}

isValidWord returns if word is valid. If user didn't allow to access user-defined dictionary, it should return promise resolving to false. It should return promise resolving to null if not-a-word is given (eg. emoji, whitespaces, whole sentence).

isGramaticallyValid checks text for presence of grammar errors. Implementations not supporting grammar-checking should return promise resolving to true.

validateText checks text for presence of all errors. It should return Promise resolving to array of SpellcheckingRangeResults.

SpellcheckingRangeResult is a simple object with read-only properties start and end, coresponding to start and end of "suspicious" text fragment. type property describes issue with selected fragment. Implementation-specific issues (eg. hypothetical plugin checking for formal language) should set type to string "other". SpellcheckingRangeResult should be used mainly to display feedback to user.

[annevk]

Heya, thanks for your proposal.

I suspect this is probably better proposed at https://github.com/whatwg/html or https://github.com/w3c/editing as the DOM Standard is fairly low-level and UI-agnostic (at least thus far). @domenic?

Also, https://whatwg.org/faq#adding-new-features and https://whatwg.org/working-mode might be of interest.

[domenic]

HTML or Editing make a bit more sense, although I don't think this proposal involves UI per se.

FWIW I like the idea of exposing the browser's built-in spellchecking mechanisms in this way. I'm less clear about grammar-checking since I don't think any (?) browsers ship with a grammar checker.

[Ginden]

@domenic

since I don't think any (?) browsers ship with a grammar checker.

Safari on OS X use grammar checking provided by OS.

[js-choi]

I would find a spellchecking API pretty useful, whether it ends up in HTML or Editing. However, it might have unique privacy issues, even with user permission. Exposing dictionaries through a web API might expose to third parties both new information about the user’s locale and any user-added custom words.

In particular, custom words could greatly facilitate user fingerprinting and even inadvertently publicize secret information that a user may reasonably expect to be kept private to their device, such as acquaintences’ personal names or politically sensitive terms. On the other hand, custom words are very useful; a website can download a language’s dictionary, but it cannot replace the custom words stored in the user’s system. I’m reminded of the warnings that accompany custom-keyboard apps in iOS and Android, e.g., this section on user trust for iOS custom keyboards.

Even with those caveats, I eagerly await seeing where this proposal goes. An autocorrection / autocompletion / autosuggestion API may also be a relevant consideration…