[Webkit-unassigned] [Bug 59693] [Feature Request] Need SpellCheck API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=59693





--- Comment #47 from Alexey Proskuryakov <ap at webkit.org>  2011-07-27 15:57:27 PST ---
So, here are some questions from the top of my head.

1. As mentioned in the e-mail, the reason for this proposal is that it's difficult to provide custom spell checking in <input> or <textarea>.
    1a. Shouldn't we be providing better building blocks instead of custom APIы, so that the same techniques that are used for content editable would work?
    1b. A site advanced enough to have its own spellchecking will likely build its own inputs anyway, perhaps using a shadow DOM, so is there a place where the API will be used? 
2. Is this use case important enough to introduce an API? It seems to be an exceptionally rare desire to use a spellchecker other than one provided by the OS.
3. The proposal is quite incomplete. 
   3a. hat happens with attached underlines if the DOM is mutated?
   3b. The proposal talks about elements and offsets without much detail. We know that there is a lot of difficulty associated with canonicalizing range endpoints - are these supposed to be somehow canonical? This is important because renderer needs to know if it's a real end of an underline, or it will be connected to an underline below an adjacent element.
   3c. What happens if a user actually chooses a suggestion from a list? I don't see a way for UA to communicate this choice back.
4. Who performed security review? I definitely don't see anything sensitive here myself, but security professionals often find surprising attack vectors, and sometimes they do it during API review.
5. Providing a list of suggestions as a string list may not be forward looking enough. What if I want to pass brief explanations, too?
6. Should it be SpellcheckRange or SpellCheckRange? Or SpellingUnderlineRange?
7. How does grammar checking fit in the API?

As much as most software engineers hate process, there is a place for it. Accepting a feature shouldn't depend on who was reading a mailing list, or who noticed a patch in flight to ask questions like this (and there are certainly more questions that I didn't think of). It also shouldn't depend as much on that random individual's ability to steer a discussion as it does in WebKit Bugzilla.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.