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

[bugzilla-daemon at webkit.org]

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





--- Comment #48 from Hironori Bono <hbono at chromium.org>  2011-07-31 20:22:29 PST ---
Greetings Alexey, et al,

Thank you for your comments.
It seems I moved too fast without deep consideration about shadow DOMs and DOM mutation. (My proposal is always incomplete since I'm an incomplete man.)
To what it's worth, I just would like to have a method that applies a style to a certain range of text in <input> and <textarea> elements. So, I do not have any intention to stick to the incomplete approach of mine. (This API just stems from the fact that we cannot access to the Text nodes (in terms of WebKit) in an <input> element or a <textarea> element as we can do for contenteditable elements.) If a shadow DOM provides scripting access to the Text nodes in these elements, I'm sure it becomes a better solution. (If we can use DOM nodes, we can use DOM ranges to specify text and it solves difficulties about 'start' and 'length' variables.) Nevertheless, I'm not sure if it is a scope of shadow DOMs. (As far as I read through the discussions in the public-webapps ML, I cannot find it.) I would like to start with sending an e-mail to the public-webapps ML about it.

Regards,

Hironori Bono

(In reply to comment #47)
> 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.