- From: Dhruv Chadha <Dhruv.Chadha@microsoft.com>
- Date: Thu, 15 Aug 2013 21:52:42 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
Consolidating email threads from Jonas and Tab: In response to Tab's comments: I think there is a slight miss-understanding of the issue that we are trying to address. It seems to me that you are referring to how a developer can know whether the user is currently holding the device in portrait vs landscape mode. We are trying to address the issue where a developer does not know which orientation aligns to the Y axis for device orientation. The height and width do not help in this context. The Y axis is always pointing to the top of the native orientation of the device. With your approach, a developer wouldn't be able to tell if a portrait device is held in the expected landscape position to play the game. In other words, the user can held their Portrait device in landscape primary or secondary modes which wouldn't provide any guidance on how to map coordinates. That is the reason we believe that we need to provide a mechanism to retrieve the native or default orientation of the device to provide the frame of reference needed for the mapping [1]. In response to Jonas' comments: Today, we don't believe there exists any dependencies between the Device Orientation and Screen Orientation specs. In other words, a developer could use device orientation information without having to set the screen orientation. If anything the Device Orientation spec says: the device coordinate frame (i.e. x,y,z) is defined relative to the screen (i.e. hardware screen [2]) in its standard orientation. The hardware sensors that provide device orientation data are aligned to the native/standard orientation. Therefore, for device orientation usage, the current screen orientation (e.g. Landscape-Secondary, Portrait-Primary, etc.) does not determine what is up. This is determined by the hardware. The spec would have to be changed if we want to have the current screen orientation automatically influence what is up. [1] http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/att-0296/Remapping_Table.PNG [2] http://dev.w3.org/geo/api/start.png Thanks, Dhruv -----Original Message----- From: Jonas Sicking [mailto:jonas@sicking.cc] Sent: Thursday, August 15, 2013 11:55 AM To: Dhruv Chadha Cc: public-webapps@w3.org Subject: Re: Supporting Portrait-First and Landscape-First devices in HTML5 Device Orientation Hi Dhruv, I think the idea of the Screen orientation spec is that when the screen reorients, so should the concept of DeviceOrientation-"up". This means that it's the current screen orientation that determines what is up, not the hardware-concept of up. This should take care of a lot of the author complexities, and they can simply think of portrait vs. landscape as two different screen sizes. / Jonas On Wed, Aug 14, 2013 at 5:22 AM, Dhruv Chadha <Dhruv.Chadha@microsoft.com> wrote: > Hi All, > > > > During our implementation of the Device Orientation API we uncovered > an issue which would could confuse web developers when building apps > using this API. The issue is caused by devices with different native > orientations (portrait vs. landscape). > > > > The problem this creates is the following: > > > > Imagine a game which requires the user to hold the device in landscape > orientation (e.g. car game). For a landscape-first devices the device > height would the Y axis (attachment: > GamePlay_Landscape_First_Device.PNG). But if the user has a > portrait-first device, she would have to rotate the device to > landscape to correctly play the game play. Because the Y axis of the > portrait-first device is still the device height, the user would > continue to get the wrong Y axis information after rotating the > device. At this point, the developer has to re-map the coordinate > system (Y to X and X to Y) to allow the game's logic to execute correctly since the Y axis is always relative to the device's native orientation. (attachment: > GamePlay_Portrait_First_Device.PNG). > > > > That is the reason we believe it is important for the developer to > know the device's native orientation so they could map their axis > respectively. The proposal is to expose this information using a new > Screen Orientation API and provide the developer with guidance on how > to re-map the device orientation coordinates if they require to do so (attachment: > Remapping_Table.PNG). Since Screen Orientation has to do with how the > physical device is being held (portrait or landscape), exposing the > native orientation made sense under the Screen Orientation API. > > > > The Interface for Screen Orientation would therefore be as follows: > > > > partial interface Screen { > > ... > > readonly attribute DOMString nativeorientation; }; > > > > The meaning and type of this new property would look something like this: > > > > nativeorientation of type DOMString, readonly > > > > The user agent MUST return the value representing the native > orientation of the screen. The returned orientation MUST be in the > current orientation list. > > > > The nativeorientation would be populated from the orientation using > the DisplayProperties.NativeOrientation on Windows devices. On Android > devices, the NativeOrientation has to be calculated using the > Display.getRotation() function and comparing it to the current orientation. > > > > I look forward to your feedback. > > > > Thanks, > > Dhruv Chadha > > Program Manager, Core Web Platform > > Windows Phone > >
Received on Thursday, 15 August 2013 21:56:04 UTC