Open Ginden opened 6 years ago
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.
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.
@domenic
since I don't think any (?) browsers ship with a grammar checker.
Safari on OS X use grammar checking provided by OS.
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…
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:
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.
isValidWord
returns if word is valid. If user didn't allow to access user-defined dictionary, it should return promise resolving tofalse
. It should return promise resolving tonull
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 totrue
.validateText
checks text for presence of all errors. It should return Promise resolving to array ofSpellcheckingRangeResult
s.SpellcheckingRangeResult
is a simple object with read-only propertiesstart
andend
, 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 settype
to string"other"
.SpellcheckingRangeResult
should be used mainly to display feedback to user.