Re: Screen Orientation Status
On 4/3/14 11:24 PM, ext Marcos Caceres wrote: On April 3, 2014 at 4:38:41 PM, Mounir Lamouri (mou...@lamouri.fr) wrote: Test suite: None yet. No test suite coordinator at the moment. I can create the test suite. Thanks Marcos! (I just added you as the Test Facilitator for this spec.)
Re: Pointer Lock Status
On 4/3/14 4:38 PM, ext Vincent Scheib wrote: Thanks for this information Vincent! Additional specification discussion: Artillery started a discussion Problems with mouse-edge scrolling and games in public-webapps Feb 21 2014 raising the topic of limiting pointer movement to a rectangular area. This is addressed in the spec FAQ for why it is postponed from the initial version, and in the recent thread the result was a call for prototype. I don't have resources to build it out, though would accept others doing so. If this was done rapidly and Mozilla was interested in incorporating changes as well there's the possibility that Pointer Lock spec should be updated to include clipping. Otherwise, I believe a follow up specification at a later time is more appropriate, keeping Pointer Lock narrow and moving to complete the specification. Given the spec's implementation status today, perhaps it would be best to postpone new features and to plan for a potential followup spec. Regardless, I think it is important to document new and/or additional features and requirements beyond what is now specified. The IDB people document their feature requests for IDB.Next in [IDB-Features]. Perhaps it would be useful to have a similar document for PointerLock. If you want to document new features/requirements [and I recommend it ;-)], besides using a wiki (f.ex. https://www.w3.org/wiki/Webapps/PointerLockFeatures), other options include using Bugzilla (I think WebIDL uses a v2 value for the `whiteboard` field) or a document in the spec's repo. (If you want to use a wiki, I'm willing to bootstrap it.) -Thanks, AB [IDB-Features] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
Re: [April2014Meeting] Seeking status and plans from Editors not attending meeting; deadline April 9
On 4/3/14 11:29 AM, ext Ted Mielczarek wrote: Implementation status: Thanks for this information Ted! Re testing, are you and/or Scott going to submit tests? If not, is there someone else that can help/lead the testing effort? Plan for last call status: I think we'd consider the spec primarily feature complete at this point. It seems to meet the use cases we intended. There's a lot more that could be added to a future version, but we have two compatible implementations shipping right now so it seems like a good place to stop. Yes, I think that makes sense. The only compelling thing I've seen mentioned that we should address soon is the interaction with systems where the gamepad is also used for controlling the browser UI, such as on consoles, which was discussed recently on the list[2]. By soon, do you mean in v1 or a subsequent version of the spec. There is one spec bug filed that I know describes an incompatibility between the Chrome and Firefox implementations[3]. It's not terrible for content authors to work around (if their code works in Chrome it will work in Firefox), but we should tighten the spec language to make the expected behavior there clear. I think that's the only thing that absolutely needs doing before we could get to last call status. Given this, perhaps the best way forward is to address this high priority bug before a LCWD is published. I also think it would be helpful if new features and requirements beyond what is already specified were documented. As I mentioned to Vincent re PointerLock, such features can be documented in a wiki (such as [IDB-Features], Bugzilla, etc. (If you want to use a wiki for v.next tracking, I'm willing to bootstrap it.) -Thanks, Art [IDB-Features] (If you want to use a wiki, I'm willing to bootstrap it.)
[DOM-PS] Please review latest ED vis-à-vis LC#2 by April 11
[ Bcc: public-webapps; please Reply-to: www-dom ] On 4/3/14 5:50 PM, ext Travis Leithead wrote: * DOM PS: Travis; plan and expectations to get the spec back to LC I finished the last of the bugs today. It's now ready to head back to LC and then on to CR! Anne, All - Travis has now closed all of the DOM PS [Bugs] and he proposes a new LC be published. As such, I would appreciate it, if people would please review the latest ED and submit all comments/bugs by April 11: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html In the absence of any non-resolvable issues, on or about April 14, I'll plan to start a CfC to publish a new LC. -Thanks, AB [Bugs] http://tinyurl.com/Bugz-DOM-Parsing
Re: [gamepad] Haptic Feedback/Controller Vibration
On 4/3/14 2:07 PM, ext Ted Mielczarek wrote: Trying to design an API that's everything to everyone is extremely hard and likely to produce unsatisfactory results. We chose to focus on the most useful subset of things that are common to all controllers. I believe the API we've spec'ed is useful in spite of not covering everything that exists in the world. FWIW, I agree with and support this view. I am not opposed to the idea of extending it to cover other common features of game controllers, but I do think we'll stick to concepts that are widely accepted (like vibration) and not bleeding-edge things supported by a single device (touchpads, colored LED). If these things gain traction then it makes sense to discuss spec'ing them. Otherwise you run the risk of spec'ing something that has only one hardware example, thus making the API hard to generalize to other devices that introduce similar (but not identical) features in the future. As I mentioned in a the status thread earlier today, I think it would be helpful to document potential new features like this. -AB
Re: [April2014Meeting] Seeking status and plans from Editors not attending meeting; deadline April 9
On 4/4/2014 8:40 AM, Arthur Barstow wrote: Re testing, are you and/or Scott going to submit tests? If not, is there someone else that can help/lead the testing effort? I don't have any non-Mozilla-specific tests currently, and the Mozilla-specific ones I have are not feasible to use cross-browser. If I get the other spec work (and implementation work) out of the way I can write some tests. The only compelling thing I've seen mentioned that we should address soon is the interaction with systems where the gamepad is also used for controlling the browser UI, such as on consoles, which was discussed recently on the list[2]. By soon, do you mean in v1 or a subsequent version of the spec. Given that it's still a vague idea I am fine with punting that to a subsequent version of the spec. There is one spec bug filed that I know describes an incompatibility between the Chrome and Firefox implementations[3]. It's not terrible for content authors to work around (if their code works in Chrome it will work in Firefox), but we should tighten the spec language to make the expected behavior there clear. I think that's the only thing that absolutely needs doing before we could get to last call status. Given this, perhaps the best way forward is to address this high priority bug before a LCWD is published. I agree. I'll keep this on my radar and try to get it done in the next few weeks. I also think it would be helpful if new features and requirements beyond what is already specified were documented. As I mentioned to Vincent re PointerLock, such features can be documented in a wiki (such as [IDB-Features], Bugzilla, etc. (If you want to use a wiki for v.next tracking, I'm willing to bootstrap it.) Having a wiki to document v.next work would be great, I know we have a few things to put on there right away. If you can put up a skeleton page I'd be happy to fill it out with what I see as topics for v.next. -Ted
Re: [gamepad] Haptic Feedback/Controller Vibration
On 4/4/2014 10:06 AM, Florian Bösch wrote: On Fri, Apr 4, 2014 at 3:45 PM, Kostiainen, Anssi anssi.kostiai...@intel.com mailto:anssi.kostiai...@intel.com wrote: In the initial versions of the spec we indeed considered such reuse. Here's my recent summary: http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0002.html If you have a navigator.gamepads and a navigator.vibrator how do you know which vibrator belongs to which gamepad? And do you want to end up with a navigator.forcefeedback, navigator.flightPedals, navigator.spacemice, navigator.hapticdevice, navigator.hotas, navigator.thrustquadrant, navigator.artificialHorizons, navigator.radioPanels, navigator.touchscreens, navigator.trimPanel, navigator.missileControl, navigator.steeringWheel, navigator.carPedals, navigator.racingWheel, navigator.gearStick, navigator.joyStick, navigator.etc? And how would you know which of those belong together into one device? This is my last reply to you, because I don't think you're being constructive. Anssi's posts were discussing the possibility of reusing the Vibration *interface* in the Gamepad spec, such that we could declare that Gamepad implements Vibration, and wind up with a Gamepad.vibrate method that works like navigator.vibrate. I don't know if this is what we want to do, but it's worth investigating so we don't reinvent the wheel if we don't have to. -Ted
Re: [gamepad] Haptic Feedback/Controller Vibration
On 04 Apr 2014, at 17:06, Florian Bösch pya...@gmail.com wrote:
On Fri, Apr 4, 2014 at 3:45 PM, Kostiainen, Anssi
anssi.kostiai...@intel.com wrote:
In the initial versions of the spec we indeed considered such reuse. Here’s
my recent summary:
http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0002.html
If you have a navigator.gamepads and a navigator.vibrator how do you know
which vibrator belongs to which gamepad? And do you want to end up with a
navigator.forcefeedback, navigator.flightPedals, navigator.spacemice,
navigator.hapticdevice, navigator.hotas, navigator.thrustquadrant,
navigator.artificialHorizons, navigator.radioPanels, navigator.touchscreens,
navigator.trimPanel, navigator.missileControl, navigator.steeringWheel,
navigator.carPedals, navigator.racingWheel, navigator.gearStick,
navigator.joyStick, navigator.etc? And how would you know which of those
belong together into one device?
One way to spec that would be to make Vibration its own interface, and say
GamePad implements Vibration. For more advanced use cases (borrowing one from
your list):
interface SteeringWheel {
readonly attribute Vibration[] vibras;
};
Based on what I hear, it sounds like we’d likely need its own interface that is
more capable than the current Vibration.
Thanks,
-Anssi
Re: [April2014Meeting] Seeking status and plans from Editors not attending meeting; deadline April 9
On 4/4/14 10:19 AM, ext Ted Mielczarek wrote: Having a wiki to document v.next work would be great, I know we have a few things to put on there right away. If you can put up a skeleton page I'd be happy to fill it out with what I see as topics for v.next. I just created the skeleton doc https://www.w3.org/wiki/Webapps/GamepadFeatures. -Thanks, AB
Re: [gamepad] Haptic Feedback/Controller Vibration
(note that when I list an inconceivable amount of ridiculous device APIs to
add, it's meant as satire of the idea that you should make a specialized
API for every assemblage of sensors, motors and displays)
On Fri, Apr 4, 2014 at 4:45 PM, Florian Bösch pya...@gmail.com wrote:
On Fri, Apr 4, 2014 at 4:35 PM, Kostiainen, Anssi
anssi.kostiai...@intel.com wrote:
One way to spec that would be to make Vibration its own interface, and
say GamePad implements Vibration. For more advanced use cases (borrowing
one from your list):
interface SteeringWheel {
readonly attribute Vibration[] vibras;
};
I think that the idea of a list of vibrators is fine. I'm explicitely
against adding a specific device interface for every conceivable device
configuration (of which there are probably thousands). I'd like the API to
be simple and non monolythic*** and to concentrate on the components,
of which there are about half a dozen, 2 being already covered (buttons and
axes) and a 3rd being what this thread is about (vibrators), such that more
could be added in the future.
Based on what I hear, it sounds like we'd likely need its own interface
that is more capable than the current Vibration.
I don't know what the vibrators specification specifies, long as it's got
speed that seems fine.
Re: Screen Orientation Status
Hi, It looks better that we now finally have angles in the spec - but I still don't see any direct link to how the X and Y axis should be mapped against devices with portrait primary and landscape primary as their natural up (terms that I as a web application developer still don't find very useful - sorry). Again - what happened to the initiative to take a holistic view on DeviceOrientation, Media Queries and orientation lock all together? Not addressing these things will give real everyday issues when manufacturers and developers both will mess up the mappings - what works on one device will work opposite on the next. As late as today, when trying out the crosswalk framework, we realized that the mappings for landscape vs XY-axis directions were opposite of what we have on the N9 and iPhone and again differently mapped when running the exact same thing on a tablet with landscape primary as up ... seriously... how many real developers have been involved in making this spec? (I know I am starting to sound a bit rude - but I am also tired of being ignored for 3 years on the topic). Keep it simple: portrait up = global up = (x,y,z) = (0,1,0) and everything else can be mapped by even the worst app developer by trial and error .. if that's what it takes. No magic - no need to buy a range of devices to test on. br Lars (ex-Nokian/part of MeeGo N9/WK2 team) On Fri, Apr 4, 2014 at 1:01 PM, Arthur Barstow art.bars...@nokia.comwrote: On 4/3/14 11:24 PM, ext Marcos Caceres wrote: On April 3, 2014 at 4:38:41 PM, Mounir Lamouri (mou...@lamouri.fr) wrote: Test suite: None yet. No test suite coordinator at the moment. I can create the test suite. Thanks Marcos! (I just added you as the Test Facilitator for this spec.)
