Re: [webkit-dev] New feature flag proposal: Joystick API
This proposal has matured somewhat, so an update is in order. FYI: http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html http://www.w3.org/2010/webevents/charter/2011/Overview.html We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is also building a prototype of this API. We are doing development on the trunk (disabled by default) so that we can more easily solicit game developers for feedback using our existing Chrome distribution channels. This feature should have a very light touch on existing cross platform code. We encourage folks to share feedback on the API design to webevents-pub...@w3.org. Regards, -Darin On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.comwrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
I share Simon's concern that that providing low level access to every possible controller creates fragmentation, with purportedly HTML content that only works on a few devices. There is no clear cut border here - it's been mentioned that even touch events can be seen as rare - and then I advocate that adding more mouse specific events is a bad idea for the same reason. As we add joystick/gamepad support, should steering wheels be next on the agenda? 3d mice? - WBR, Alexey Proskuryakov 06.10.2011, в 10:01, Darin Fisher написал(а): This proposal has matured somewhat, so an update is in order. FYI: http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html http://www.w3.org/2010/webevents/charter/2011/Overview.html We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is also building a prototype of this API. We are doing development on the trunk (disabled by default) so that we can more easily solicit game developers for feedback using our existing Chrome distribution channels. This feature should have a very light touch on existing cross platform code. We encourage folks to share feedback on the API design to webevents-pub...@w3.org. Regards, -Darin On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.com wrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 11:07 AM, Alexey Proskuryakov a...@webkit.org wrote: I share Simon's concern that that providing low level access to every possible controller creates fragmentation, with purportedly HTML content that only works on a few devices. There is no clear cut border here - it's been mentioned that even touch events can be seen as rare - and then I advocate that adding more mouse specific events is a bad idea for the same reason. As we add joystick/gamepad support, should steering wheels be next on the agenda? 3d mice? Would you mind raising this concern in the relevant standards body (in this case, webevents-pub...@w3.org seems to be relevant)? Debating issues with standards on webkit-dev is unproductive - it does not include all parties who have an interest, in particular other browser vendors and web developers, and it does include a lot of WebKit developers who probably aren't interested. - James - WBR, Alexey Proskuryakov 06.10.2011, в 10:01, Darin Fisher написал(а): This proposal has matured somewhat, so an update is in order. FYI: http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html http://www.w3.org/2010/webevents/charter/2011/Overview.html We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is also building a prototype of this API. We are doing development on the trunk (disabled by default) so that we can more easily solicit game developers for feedback using our existing Chrome distribution channels. This feature should have a very light touch on existing cross platform code. We encourage folks to share feedback on the API design to webevents-pub...@w3.org. Regards, -Darin On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.comwrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 11:07 AM, Alexey Proskuryakov a...@webkit.org wrote: I share Simon's concern that that providing low level access to every possible controller creates fragmentation, with purportedly HTML content that only works on a few devices. There is no clear cut border here - it's been mentioned that even touch events can be seen as rare - and then I advocate that adding more mouse specific events is a bad idea for the same reason. Isn't a balance of usefulness vs fragmentation vs trusting developers? When touch events are exposed, I'd expect that developers who care about having a board appeal will have alternatives for users without a touch interface but having a web page be able to respond to touch events seems useful for web pages to do to shine in that context. (In fact developers are inclined to provide this other interface to have the broad appeal.) Doesn't the same thing apply to these other cases? dave As we add joystick/gamepad support, should steering wheels be next on the agenda? 3d mice? - WBR, Alexey Proskuryakov 06.10.2011, в 10:01, Darin Fisher написал(а): This proposal has matured somewhat, so an update is in order. FYI: http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html http://www.w3.org/2010/webevents/charter/2011/Overview.html We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is also building a prototype of this API. We are doing development on the trunk (disabled by default) so that we can more easily solicit game developers for feedback using our existing Chrome distribution channels. This feature should have a very light touch on existing cross platform code. We encourage folks to share feedback on the API design to webevents-pub...@w3.org. Regards, -Darin On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.comwrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
06.10.2011, в 11:12, James Robinson написал(а): Would you mind raising this concern in the relevant standards body (in this case, webevents-pub...@w3.org seems to be relevant)? Debating issues with standards on webkit-dev is unproductive - it does not include all parties who have an interest, in particular other browser vendors and web developers, and it does include a lot of WebKit developers who probably aren't interested. My interest is in avoiding immature and/or harmful specs in WebKit. Investing work into improving specs is not the only possible outcome of discussing them on webkit-dev - for example, we can just decide to not take them, or to work with another W3C working group. 06.10.2011, в 11:14, David Levin написал(а): Isn't a balance of usefulness vs fragmentation vs trusting developers? Yes, certainly so. As I see it, the reasons for Web apps popularity and even continued existence are: - Opening Web apps is easy and safe, users and sysadmins don't need to take precautions associated with installing native applications. - One can access any Web app from any browser. As we all know, neither of these is achieved with anything close to absolute fidelity today, but these are nonetheless platform strengths. I don't want to take a particularly strong stance against Joystick/Gamepad specifically, but I see codifying input device fragmentation in Web specs and APIs as a move in a wrong direction. When touch events are exposed, I'd expect that developers who care about having a board appeal will have alternatives for users without a touch interface but having a web page be able to respond to touch events seems useful for web pages to do to shine in that context. (In fact developers are inclined to provide this other interface to have the broad appeal.) Myself, I've been annoyed a few times when visiting some phone specific sites using a desktop browser. It will likely become more common. That said, there is a difference. Touch events are fundamental and usable for many kinds of interfaces. Game oriented input devices are meant for much fewer uses, so there can be hope of getting a meaningful universal API for them. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 11:50 AM, Alexey Proskuryakov a...@webkit.org wrote: I don't want to take a particularly strong stance against Joystick/Gamepad specifically, but I see codifying input device fragmentation in Web specs and APIs as a move in a wrong direction. Why are you convinced there is input device fragmentation here? My understanding is that the spec as proposed already handles multi-axis digital and analog controls so things you mentioned earlier like wheels and 3d mice would all just work along with gamepads and joysticks. I could be misinformed, but it would be nice for you to be concrete about precisely what parts of the spec are currently problematic. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 1:42 PM, Alexey Proskuryakov a...@webkit.org wrote: 06.10.2011, в 13:23, Peter Kasting написал(а): Why are you convinced there is input device fragmentation here? My understanding is that the spec as proposed already handles multi-axis digital and analog controls so things you mentioned earlier like wheels and 3d mice would all just work along with gamepads and joysticks. If accurate, that could be a great resolution to the dispute. I do not know enough about these devices to say whether wheels and 3d mice (as an example) are covered. The spechttp://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html explicitly states that it's about gamepad devices (also known as joysticks). Spec section 3 states: This allows support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. It excludes support for more complex devices that do motion sensing, depth sensing, video analysis, gesture recognition, and so on. It seems to me that this is an appropriate line to draw. Devices like the Kinect seem categorically different from most classical game input devices and I think it's reasonable to exclude them from the first version of the spec, as long as it covers the other types of things fairly well. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
Hi Alexey, The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. This is based on a somewhat generic treatment of axes and buttons that are exposed as normalized floating point values. There has been some discussion of attempting to further generalize but in an attempt to limit to a tractable scope to start with, the WG felt it was best to push broader generalization to a potential v2 spec. Regards, Scott 2011/10/6 Alexey Proskuryakov a...@webkit.org 06.10.2011, в 13:23, Peter Kasting написал(а): Why are you convinced there is input device fragmentation here? My understanding is that the spec as proposed already handles multi-axis digital and analog controls so things you mentioned earlier like wheels and 3d mice would all just work along with gamepads and joysticks. If accurate, that could be a great resolution to the dispute. I do not know enough about these devices to say whether wheels and 3d mice (as an example) are covered. The spechttp://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html explicitly states that it's about gamepad devices (also known as joysticks). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
2011/10/6 Alexey Proskuryakov a...@webkit.org 06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? I think you should send these comments back on webevents-public@w3.orginstead as James pointed out. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 2:07 PM, Alexey Proskuryakov a...@webkit.org wrote: 06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? I hate to repeat myself but this feedback really should go to the working group defining the specification. - James - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
2011/10/6 Ryosuke Niwa rn...@webkit.org 2011/10/6 Alexey Proskuryakov a...@webkit.org 06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? I think you should send these comments back on webevents-public@w3.orginstead as James pointed out. I'll add that I completely agree with both of your points above but I don't feel motivated or knowledgeable enough to post it myself. Also I don't want to take credits for your feedback :) - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
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 scot...@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 dglaz...@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.fra...@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 scot...@chromium.org wrote: On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
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 dglaz...@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.fra...@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 scot...@chromium.org wrote: On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New feature flag proposal: Joystick API
Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.comwrote: 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? scott ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
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 scot...@chromium.org wrote: On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
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.fra...@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 scot...@chromium.org wrote: On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
If it's helpful, I can attempt to document these bits of methodology somewhere on our wiki. Another thing -- perhaps we could point newcomers like Scott to Whatwg as the forum for design discussions, rather than referring to W3C process? :DG On Wed, Aug 24, 2011 at 11:25 AM, Dimitri Glazkov dglaz...@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.fra...@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 scot...@chromium.org wrote: On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Aug 24, 2011, at 19:21 , Simon Fraser 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. You don't need to loop in W3C or any other organisation to make an API that universally caters to all possible input event types a massive time investment. There is such a thing as trying too hard for consistency; furthermore different input methods do tend to require (or at least benefit) from having their specificities exposed. I think that it makes sense to prototype as much as possible, and once prototypes are roughly usable look for areas of overlap with existing input methods. This isn't very different from a lot of what's been done with touch events. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Wed, Aug 24, 2011 at 8:36 AM, Scott Graham scot...@chromium.org wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. The API they're advocating for over in mozilla-land is strange. Why not an input type or other element with DOM events firing from it? Handling connection/disconnection seems like it shouldn't be necessary in the common case. Further API can be then hung off of the element, avoiding warts like permission prompts in most cases. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
