How can sites access browser spellchecking?

[BenjamP]

There has been a request in http://lists.w3.org/Archives/Public/public-editing-tf/2014Dec/0134.html to have access to spelling suggestions, etc that the browser provides. We should consider making a new spec about this in the future.

[rniwa]

There is a significant privacy concern here. User defined keywords may reveal sensitive information such as the real name of the user.

[johanneswilm]

Here is one idea of how to do that. @rniwa could you explain how this reveals sensitive information? The way I understand it, it should only give access to the standard dictionaries that come preinstalled with the browser. Extra user dictionaries, etc. would be created and handled by the application in question in userspace:

Purpose:
-- Be able to override right-click menu without losing spellchecking
-- Control autocorrect and spellchecking individually
-- Have direct control over the language used for  spellchecking from
Javascript
-- Have a way to more specifically tell the browser what makes out a
sentence for something it is to spellcheck.  So for example an editor with
a citation plugin may have something like the following:

<div cE=true>
In the book <span cE=false class="citation-title>The World according to
me</span> the sociologist <span cE=false
class="citation-author-as-subject">Émile Durkheim (1902)</span> writes a
great deal about his early childhood.
</div>

It would be good to be able to tell the browser to please spell/grammar
check a sentence such as:  "In the book SOMETITLE the sociologist AUTHOR
writes a great deal about his early childhood." in English. And this is
assuming that some internal spellcheckers may be intelligent enough to try
to guess the meaning of a word in a sentence when spellchecking, which I am
not sure they are.

> An obvious one is knowing that a spellchecker *wants* to correct a word,
> and looking in a custom dictionary. For example in various Yandex services
> we use a russian/english input method, where ghbdtn can actually be
> recognised as привет and цувтуывфн as wednesday. (This saves switching
> keyboards for simple stuff). But my spellchecker doesn't pick that up, so
> it tries to do all kinds of odd and rather annoying things instead.
>

Indeed, custom dictionaries would also make a lot of sense

Possible way to make this possible:
A simple function accessible to Javascript that takes two arguments: text
to be checked and language and which return all the possible suggestions
listed by beginning and end character number of the original string., For
example:

> spellcheck("Who's kat iz dat?",'en_US');

[
  {
    start: 0,
    end: 4,
    suggestions: ["Whose"]
  },
  {
    start: 6,
    end: 8,
    suggestions: ["cat","hat","mat"]
  },
  {
    start: 10,
    end: 11,
    suggestions: ["is"]
  },
  {
    start: 13,
    end: 15,
    suggestions: ["that"]
  },
]

Then Javascript would need to need to be used to do everything else: draw
red lines under corresponding words, create selection menus, etc. .It seems
though that this would be something that should be specified somewhere else
than in contenteditable.

[rniwa]

There is no such a thing as the standard dictionary that comes with the browser at least in Safari. We use the system dictionary which includes all user defined words.

I don't think we want Web apps to explicitly support spellchecking, etc... This would prevent Web browsers from supporting different ways of correcting text. For example, OS X provides grammar checking as well as spellchecking. My point isn't that we need to add another API to support grammar checking but rather that the API should be flexible enough to support new modality of correction.

Furthermore, both spellchecking and IME require the contextual text inside which the corrected word/phrase appear. So it's better to provide some API that lets Web apps to serialize a DOM Range so that Web browser could query the content and provide sufficient information to the IME/autocorrection mechanisms provided by the system.

[johanneswilm]

Hey, I understand your concern, but imagine if someone wanted to create a desktop app, and the platform people would just tell that developer: "Sorry, but we won't let you access the spell or grammar checker or differentiate between the two." Would that be acceptable? Probably not. Now we are building web based apps and we kind of need similar type access to functionality. Of course we need to be able to differentiate between grammar and spellchecker within our apps ourselves. This is something we need to be able to control with our UI, and not something browser developers should hide from us.In case you don't give this to us, we will need to entirely turn of the builtin spell/grammar checker and instead use third party tools on other sites, as you can do with plugins for the webbased editors already.

[rniwa]

Unfortunately, the native platforms and the Web platform have significantly different security and privacy models.

What I would like to know is the use cases for which accessing UA's spellchecking is desirable.

[johanneswilm]

Yes, how about hiding the functions behind some kind of access control like that used for access to microphone and webcam?

The use case is that one will create a rich text editor with a custom GUI and custom elements in which the displayed HTML is too complex for the browser to "automagically" be able to figure out what language the text is written in or what parts of HTML are to be understood as a sentence or a paragraph and also we may want to combine the automatic part of the spell or grammar checking (and there needs to be a clear separation between the two for us on the Javascript side of things) with some custom things -- such as domain specific dictionaries that are used in addition to the available browser spell checker. This is therefore all something we need to be able to control ourselves. Check for example the CKeditor spell checker plugin: http://docs.ckeditor.com/#!/guide/dev_spellcheck .Why do you think they don't just let the browser native spell checker run instead of this third site tool? Wouldn't that be a lot easier for them? It would, but it wouldn't be as integrated to the editor and what the spell checker did would be rather out of control.

[rniwa]

If the page is too complex for web browsers to get text from, then we should simply provide API for websites to tell us which parts of the text could be spellchecked. In fact, we already a simple version of that: https://html.spec.whatwg.org/multipage/interaction.html#attr-spellcheck

If there are domain specific corrections to be applied or that some words should be considered spelled correctly, then that information should be communicated back to the Web browser so that they can be combined with the rest of correction candidates.

[johanneswilm]

Maybe we need some general understanding of some fundamental issues here. You guys seem to feel that the browser should basically control most things, whereas it seems like a lot of us Javascript developers feel we should have a basic platform upon which we can build various types of applications that are powerful enough to compete with native apps.

I am aware of the spell check attribute, and the cause for this proposal to start at all was that that is not enough. The reality for good browser based editors today is that they generally turn of the browser based spell (and grammar) check by default, because it interferes with their application and cannot be controlled well. If we stay with the current model in which the browser controls spell checking, the browser-native spell checker is largely irrelevant for well-built editors. It seems to me that it is this situation we want to get away from.

It is not always that an entire sentence that is to be spell checked is actually shown on the screen as a single sentence uninterrupted by other HTML elements. Check my first comment above. Also, many more complex editors may decide not to use contenteditable at all --- as is already the case with Codemirror, Aloha, etc. --- because they want to allow more complex things, such as multiple colors coded carets, etc. . Currently that means that they are also shut out from using the spell checker capabilities.

Another use case is that besides having the constant underline spell checking going on, one may have an option to go through spelling issues one by one (and then grammar issues and then go through issues of weird expressions, and other checks created only within a specific app). This is what you can do in word processors already and it is a common way for some people to go through their document.If the spell checking is only being done in the browser and the application has no access to any of this, then this is not possible (without using third party web services).

[NorbertLindenberg]

From an end user point of view, I like the idea of having the browser handle spelling and grammar checking so that I get the same user experience across applications and avoid monstrosities such as the WebSpellChecker dialog.

Maybe we should collect which API improvements would be necessary so that application developers don't feel the need to roll their own? I can think of: – Control over the language that's assumed, or just a way to request that the lang attribute takes precedence over the keyboard language. – Ability to provide a custom dictionary that's used in addition to or instead of the system dictionary.

[BenjamP]

I think 3rd party services are the answer for web developers if they don't want the browser to handle everything. Browsers should not be in the business of providing spelling suggestions to sites.

[johanneswilm]

But don't native apps have access to this? Why should webbased apps be excluded?

[rniwa]

Web-based apps and native apps have completely different security models and as such requires a different set of API.

[johanneswilm]

Ok, fine, I don't get what the security issue is about, but lets come to an agreement here.

So we agree that either there is no browser-supported spell-checking at all, or it is entirely handled by the browser with no way for the site to have any influence on it.

From our conference call I understand that the browser-based spell checker is needed for certain email clients.

Should we specify that the spell checker only ever can change the contents of a single text node?

Do we need an event for when a word is being exchanged with another?

I assume that deletion of part of a word (by ways of JavaScript) will be handled automatically and that we don't need to specify anything about that?

[johanneswilm]

Reviewing this again, it appears to be a Safari-only problem, and Safari's spell checking for contenteditable is already broken due to attempts as cross-element spellchecking ( https://github.com/w3c/editing-explainer/issues/50 ), so I don't see why this should hold everything else up. Including a standard spell checker is what other browsers do, so this should not be magic for Safari to implement as well. Such a spell checking APi could be part of a new spec so that it does not hold up Safari's implementation of contentEditableTyping.

This seems to be the only sane solution at fixing spell checking in a relatively secure manner.

[rniwa]

Well, the problem is that each browser vendor has its own requirements. For us, adding our own spellchecker is not an option just like having our own graphics layer as done in Gecko and Blink (e.g. Skia) isn't an option for us as we rely on the underlying system provide it (e.g. CoreGraphics).

[johanneswilm]

@rniwa No-one forces you to implement a spell checker api. But that doesn't mean that no-one should ever write a spell checker api if it is something that would be extremely useful for editor developers.It can be completely separate form all the other components here so that it's not something anything else depends on.

As you can see from the other link, what Safari currently has (as well as what other browsers have) is so broken that semi-complex editors such as TinyMCE disable it entirely.

[rniwa]

@johanneswilm I'm not saying that. However, it's unaccetable for new editing API to not support spellchecking without JavaScript manually calling out to the said spellchecking API.

[johanneswilm]

The APi does no such thing. Just look at the documents. IUt's says nothing about spellchecking being forbidden. It just contrains it to text nodes to avoid some of the worst issues. Yet still it will likely be something just about every editing app will have to turn off to work more or less properly.

[rniwa]

Ah, I misunderstood what you said. Why can't we just let browser issue a "replace" intent that spans across multiple elements in that case?

[johanneswilm]

See the examples starting in https://github.com/w3c/editing-explainer/issues/50#issuecomment-105339304 (and the following comment by TinyMCE developer).

Is it also an implementation requirement that the spell checker needs to go across element boundaries? It would seem to me that it would be easier for the spellchecker if it could just consider one text node individually.

[rniwa]

Since an end user can't even tell whether a given word spans across multiple elements or not, I don't see how we can justfiy such a constriant. Also, editors already need to support deletion across multiple elements when the user presses backspace or when a user pastes text by replacing multiple elements so I don't see how adding this constraint will make implementing an editor any easier.

[johanneswilm]

Since an end user can't even tell whether a given word spans across multiple elements or not

This is for the editor to make sure -- that things that should be spell checked together do not span across elements.

editors already need to support deletion across multiple elements when the user presses backspace

How the deletion key works can be configured to the last detail in the JavaScript. But the spell checker, when turned on, will simply add red lines and the editor has no more control over where those lines are put -- except through hacks. And sure, I cans till make it so that if the user selects that MexicoMaus shouldn't actually be changed to whatever the spell checker comes up with, it will just look wrong if it's underlined, yet the user's correction choice is not accepted.

[rniwa]

I think the way to solve that problem is by providing mechanism to explicitly mark boundaries of words/sentences/paragraphs so that the browser wouldn't do that instead of implying them by elements.

[kojiishi]

I'm not positive to bring this in to ce=typing level 1. We could do this in future levels, or as a separate module, but I'd like our efforts focused on the minimal set of requirements and to make it interoperable for now.

[johanneswilm]

@kojiishi : When you say "this" you mean access to spell checking API or a way to define word boundaries? The minimum common ground for spellchecking at this stage seems to be to only let words be within one text node. Otherwise most semi-complex editors have to turn spellchecking of entirely.

[kojiishi]

@johanneswilm

When you say "this" you mean access to spell checking API or a way to define word boundaries?

Primarily the former. But I wonder whether the latter is also such a high priority or not.

The minimum common ground for spellchecking at this stage seems to be to only let words be within one text node. Otherwise most semi-complex editors have to turn spellchecking of entirely.

I understand your bad example, but I wonder there'd be other bad cases if we limit to one text node. abspos creates a BFC, so it should probably split, but inline-block with margins...I really don't know, there should be both cases. What about letter-spacing:100px? And at least in your example, doesn't putting LF at the element boundary fix the issue?

I think this issue is not very common, has a workaround, hard to do it right, especially when i18n is involved. Important, but need more time to bake, so my opinion is that we can revisit and add in future levels.

[johanneswilm]

I think underestimate how common/uncommon this is. Things like this is what makes the editors all use third party solutions. I added quite a few properties as you can see in my example #2, yet none of that fixed it. It was broken in Chrome as well. I don't think there is a workaround really. LF?

As for a spellchecker api: I agree, that should be its own spec and not related to CE at all.

[johanneswilm]

I have updated the spec as requested by browser makers. I continue to think it isn't a good idea to give browsers full control over spellchecking and that it makes the feature unusable for even slightly complex richtext editors, but I accept that it is not something browser makers agree with and the most important is to get to a conclusion and as long as it can be turned off, it doesn't hinder editor developers from using contentEditable=Intentions.