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

[Scott Graham]

Hello,

Work has started on a Gamepad (Joystick) spec in the W3C WebEvents WG.

If you're interested in commenting or participating, the mailing list
can be found at http://lists.w3.org/Archives/Public/public-webevents/

For reference, the draft in-progress can be found at
http://dvcs.w3.org/hg/webevents/raw-file/tip/gamepad.html

scott

On Thu, Aug 25, 2011 at 8:44 AM, Scott Graham <scottmg at chromium.org> wrote:
> Thanks Simon and Dimitri, I wasn't familiar with the procedure for
> attacking these sorts of things.
>
> I've started a discussion on public-webapps, which will hopefully help
> to clarify a sensible API. Please add your voice if you have the time
> and inclination:
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1019.html
>
> If the discussion proves fruitful, I will re-approach the WebKit
> community to figure out the best way to work on a prototype
> implementation. I've closed the previously mentioned bug for now.
>
> scott
>
> On Wed, Aug 24, 2011 at 11:25 AM, Dimitri Glazkov <dglazkov at chromium.org> wrote:
>> 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<
>>>
>>>
>>
>