Tab, We sympathize with the goal of creating a simple programming model for developers but we don’t believe that is what is currently specified on the device and screen orientation specs (as we stated in our earlier response to Jonas). Our proposal maps existing native implementations done by iOS, Android, and Windows. These native APIs provide capabilities to discover the native orientation of the device and to remap the coordinate system based on the user selected orientation.
We believe that mapping the coordinates to the current screen orientation would generate the following issues: - Changes the design of the API as defined by current draft of the device orientation spec and will break interoperability with current implementations - If the browser’s orientation is not locked, rotating the device would reset the coordinates back to 0 in the reference axis for each 90 degree rotation since the browser App UI would rotate as well - Does not provide flexibility. What happens if the developer is not interested in automatically re-mapping the coordinate system? They wouldn’t have an ability to change this behavior. In addition, changing the reference coordinate without providing the actual/native coordinate system will have the following impact: - the alpha value (+Z) for device orientation should always be aligned to the input from the compass (i.e. hardware sensors) unless the developer requests a re-mapping Thanks, Dhruv On Thursday, August 15, 2013 3:09 PM, Tab Atkins Jr. [mailto:[email protected]] > 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]. Ah, I did misunderstand - all the talk about "portrait" and "landscape" made me think that you were talking about Screen Orientation, not Device Orientation. In that case, Jonas is right - if the device is rotated such that Screen Orientation would change its value, the reported values from Device Orientation should change as well. That way authors don't have to do any additional work - the coordinates are always correct and pointing in the "right" direction. (This will also automatically pay attention to things like @viewport locking the orientation - Screen Orientation *shouldn't* change the value then, so you'll continue to get coordinates relative to the original direction even if the device is rotated.) ~TJ
