[webkit-dev] New feature flag proposal: Joystick API

[Dimitri Glazkov]

We should do this right, you won't hear any arguments from me. But I
am also sure that "W3C time investment" is a code word for years of
soul-sucking bureaucratic drudgery. As such, I don't think you meant
we should be using W3C process as the measuring stick for doing things
"right" in WebKit. There would not be WebKit if we did.

What I hope you meant instead is:
* study the problem in the larger context of a Web platform
* come up with a set of use cases that cover the problem
* design a solution based on the use cases
* build consensus with browser vendors while prototyping it in WebKit
* write a spec and a test suite that makes sense
* submit this to W3C as time permits.

That's what we've always done, right?

:DG<

On Wed, Aug 24, 2011 at 10:21 AM, Simon Fraser <simon.fraser at apple.com> wrote:
> My main objection to adding this is that it's just one of many different types of input device, and if we add these piecemeal for each device that takes our fancy, we'll end up with a horrible mishmash of different input events.
>
> I'd prefer a more general strategy of thinking about all the various types of input events (e.g. joysticks, remote controls, assistive devices), and having an API that caters for all of them. This of course would require significant W3C time investment.
>
> Simon
>
> On Aug 24, 2011, at 9:43 AM, Dimitri Glazkov wrote:
>
>> On Wed, Aug 24, 2011 at 9:39 AM, Scott Graham <scottmg at chromium.org> wrote:
>>> On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser <simon.fraser at apple.com>
>>> wrote:
>>>>
>>>> I think it's too early to implement this. We should wait until it's a W3C
>>>> draft at least.
>>>
>>> There's certainly work to be done in improving the design. I'm not proposing
>>> to slavishly implement the API exactly as specified there.
>>> However, I would like to prototype and help with the design of this API by
>>> iterating an implementation in the Chromium port.
>>> Is a feature flag inappropriate for this? i.e. Should that sort of prototype
>>> work be kept downstream indefinitely or until we have a draft spec?
>>
>> FWIW, keeping implementation "downstream" (that is in Chromium) is
>> basically an equivalent of forking, and we should work hard to avoid
>> that. But certainly not by just rejecting prototyping outright --
>> because the only workaround for that is forking.
>>
>> :DG<
>
>