[webkit-dev] Spellcheck API for WebKit

Hironori Bono (坊野 博典) hbono at chromium.org
Wed Jun 22 22:49:19 PDT 2011


Greetings Adam,

Thank you for reverting this change on my behalf. (I agree it is not so easy.)
I will re-implement this API to apply comments, wishing the next
change becomes the better one.

Regards,

Hironori Bono
E-mail: hbono at chromium.org

On Thu, Jun 23, 2011 at 2:43 AM, Adam Barth <abarth at webkit.org> wrote:
> The rollout is slightly complicated, but I'll take care of it.
>
> Adam
>
>
> 2011/6/21 Ryosuke Niwa <rniwa at webkit.org>:
>> 2011/6/21 Hironori Bono (坊野 博典) <hbono at chromium.org>
>>>
>>> On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser <simon.fraser at apple.com>
>>> wrote:
>>> > This new API got turn on inadvertently on Mac just now, and a few of us
>>> > spent
>>> > a wasted hour trying to get things to build. In this light, my comments
>>> > on the API
>>> > may not be as favorable as they would otherwise be.
>>> >
>>> > First, why is the API on HTMLDivElement?
>>>
>>> Unfortunately, I have just copied and pasted my code in
>>> HTMLTextAreaElement to support contenteditable elements and designMode
>>> ones because I did not have better ideas at that time. I should have
>>> asked about it in this ML before landing this change.
>>
>> contenteditable attribute can appear in any element so I don't think we
>> should restrict it to div.
>>>
>>> > Second, since this exposes to the web API in a non-final spec, the new
>>> > methods
>>> > should be prefixed with 'webkit' to avoid potential conflict if the API
>>> > changes later.
>>>
>>> This is totally my fault. (The sin of ignorance.) Sorry again for that.
>>>
>>> By the way, I wonder how I should treat my r88332 even though I
>>> understand this change was wrong. Even though there are several
>>> options: 1. re-design the API, 2. revert my r88332 and re-implement
>>> it, 3. send changes that apply these comments, etc. Would it be
>>> possible to give me your advice?
>>
>> Given that the original patch seems to have various issues and we're going
>> to make a lot of changes (i.e. move it to HTMLElement and prefix it with
>> webkit or chrome), option 2 seems most suitable approach here.
>> - Ryosuke
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>


More information about the webkit-dev mailing list