- From: Lars Knudsen <larsgk@gmail.com>
- Date: Mon, 10 Jun 2013 10:58:33 +0200
- To: Kenneth Rohde Christiansen <kenneth.r.christiansen@intel.com>
- Cc: Tobie Langel <tobie@w3.org>, public-webapps <public-webapps@w3.org>, Mounir Lamouri <mounir@lamouri.fr>, David Bruant <bruant.d@gmail.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- Message-ID: <CA+jkkcjYw5UpyKRJhhshjqbgbSb_VKTi6YFbUpqoPNU3SAJjjg@mail.gmail.com>
On Wed, Apr 24, 2013 at 1:00 PM, Kenneth Rohde Christiansen < kenneth.r.christiansen@intel.com> wrote: > Hi there, > > CSS Device Adaptation should hopefully be enabled on all browsers (desktop > and mobile) unlike the viewport meta tag, which cannot be enabled on > desktop browsers easily as many desktop sites actually comes with a > viewport meta tag which is ignored. Having that not being ignored breaks > the sites. > > MS already enabled a subset of the CSS Device Adaptation spec in IE10 > desktop. > > I support adding some CSSOM API's for CSS Device Adaptation, but I would > not do so for the viewport meta tag, which has its share of issues. I would > also like the CSS Device Adaptation, orientation lock and Fullscreen to > integrate. Especially it would be nice to click on an element in portrait > and have it go fullscreen in landscape mode and lock, all with a nice > animation. > IMO, this would be a much more clean and easy to understand solution than providing a separate API for orientation lock. It would also remove 1 "unknown" element when game developers try to juggle mappings between xyz-accelerometer data vs media query orientation vs "device normal orientation" (as some propose to have "natural landscape" and "natural portrait" devices - something I really think would just add to the confusion). Allow me to quote myself from an earlier other thread on a proposed orientation lock API: " As long as both MediaQueries, xyz-accelerometer data, orientation lock and more *all* are aligned, this could work. However, we need to have this tested with a bunch of developers - to see where they make mistakes caused by possible confusion. My own opinion on this is still to keep it in a specific orientation also (e.g. "portrait up") as 0 degrees, as it makes everything more easy to handle when the basics are kept static. I can tell you that even inside the same company (mobile phone manufacturer), I have seen mistakes in the mapping of the xyz-accelerometer values *alone* between units coming from slightly different branches. This was because some were "landscape" devices and some were "portrait" and everything have to match from the low level HW to the high level javascript API. If we make sure that a device - no matter how the rest of the UI is turning - is always considered "0 degrees" when held - e.g. "portrait up", (x,y,z) = (0,1,0), then: 1. non-game developers can be happy with "lock to landscape" and never need to worry about the inner workings and 2. game developers (using the accelerometer) won't have to reinvent strange mappings when juggling media queries, accelerometer and orientation lock. If we allow "natural landscape" units and "natural portrait" units - then in some cases, when in a landscape locked game, the gravity goes in the direction of "negative X" - and in some cases it goes in the direction of "negative Y". And it gets worse if you don't even know which landscape (left or right up) you got. If we enforce that the device always has "0 degrees" when held portrait up (Y positive pointing at 90 degrees) - then "lock to landscape right up" always gives gravity in "negative X". " The problem might sound like a small one - but as a web game developer, I would MUCH rather develop for devices, where I know that "in my landscape-left game, natural UP is X+" than being forced to buy and test on all thinkable devices out there because the spec allows for manufacturers to have "natural landscape" units, where "full screen portrait" could be anything (really) when mapping the xyz accelerometer data to my game. br Lars > > Cheers > Kenneth > > > > On Wed, Apr 24, 2013 at 12:13 PM, Tobie Langel <tobie@w3.org> wrote: > >> Hi, >> >> Screen orientation lock is critical to a whole set of mobile games >> (especially those which rely on the accelerometer to control the gameplay). >> It's great that it is now considered for specification and implementation. >> >> I had collected some use cases a while back[1], some of which led to >> use-cases[2], requirements[3] and suggestions[4] in the Coremob report. >> >> While some of the original use cases required dynamically modifying >> orientation lock (e.g. the Game within a game experience[5]), key use cases >> simply require a declarative, page-wide setting, as described by David >> Bruant on the WHAT WG mailing list[6]. >> >> The current proposal[7] only targets the dynamic setting through a JS API >> and leaves the more declarative approach to other specs[8]. It mentions the >> Web Application Manifest Format and Management APIs[9] and CSS Device >> Adaptation[10]. >> >> Now, CSS Device Adaptation, as used in the Viewport META element[11] is >> ubiquitous on mobile. It seems like a natural fit for a declarative >> orientation lock, so much so that it's already specified in the spec[12]. >> >> However, the syntax to dynamically read or modify the Viewport META >> element is cumbersome and error prone (you're talking document.cookie-like >> string splitting/concatenation with unspecified separators, etc.[12]). >> >> Instead of providing a dedicated API to cater strictly for the screen >> orientation lock use case, wouldn't it make more sense and be more >> consistent to provide a CSSOM[14] API for the whole Viewport META element, >> and use matchMedia listeners[15] instead of orientationchange events? >> >> This would allow declarative setting through the Viewport META element, >> dynamic modification through the CSSOM API, and event handling through the >> matchMedia interface, all of which are well known and commonly used by >> developers. >> >> Thanks for your time. >> >> --tobie >> --- >> [1]: http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html >> [2]: >> http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#play-a-2d-game >> [3]: >> http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#req-orientation-lock >> [4]: >> http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#screen-orientation >> [5]: >> http://tobie.github.io/ORIENTATIONLOCK-UCR/index.html#game-within-a-game-experience >> [6]: >> http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Apr/0078.html >> [7]: https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html >> [8]: >> https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html#declarative-orientation-locking >> [9]: https://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html >> [10]: http://dev.w3.org/csswg/css-device-adapt/ >> [11]: http://dev.w3.org/csswg/css-device-adapt/#viewport-meta >> [12]: >> http://dev.w3.org/csswg/css-device-adapt/#the-lsquoorientationrsquo-descriptor >> [13]: >> https://developer.mozilla.org/en-US/docs/Mobile/Viewport_meta_tag#Background >> [14]: http://dev.w3.org/csswg/cssom/ >> [15]: http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface >> >> >> >> >> >> > > > -- > --------------------------------------------------------------------- > Intel Denmark Aps > Langelinie Alle 35, DK-2100 Copenhagen > CVR No. 76716919 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. >
Received on Monday, 10 June 2013 08:59:02 UTC