[webkit-dev] Extra review requirement for web-facing API? (Was: Re: Spellcheck API for WebKit)

Simon Fraser simon.fraser at apple.com
Wed Jun 22 11:28:30 PDT 2011


Thank you, Adam.

Given this fiasco, I'm temped to propose that we require two levels of review for new web-facing API.

Simon

On Jun 22, 2011, at 10:43 AM, Adam Barth 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
>> 
>> 
> _______________________________________________
> 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