Re: CfC Re: Charter addition proposal: screen orientation lock

Given the positive responses to this CfC, the Screen Orientation API has 
now been added to the Additions Agreed section of charter changes wiki 
<http://www.w3.org/2008/webapps/wiki/CharterChanges>.

On 1/30/12 8:26 AM, ext Charles McCathieNevile wrote:
> OK, since I was planning to have the charter up today, let's have a 
> quick call for consensus on this. Please reply by end of business 
> Wednesday if you support or object to this - silence will be taken as 
> not explicitly supporting it, and without support it isn't going to 
> get into the draft charter. If it does go there, there will still be 
> opportunities to object but it will be harder to squeeze in.
>
> cheers
>
> Chaals
>
> On Mon, 30 Jan 2012 12:22:30 +0100, Robin Berjon <robin@berjon.com> 
> wrote:
>
>> Hi all!
>>
>> Sorry for bringing this to the group this late, but it's a topic 
>> that's been discussed in other places and that I believe is both 
>> useful and mature enough to be ready for standardisation.
>>
>> Some applications are designed in such a way that they only make 
>> sense in one device orientation. The archetypical example would be a 
>> game that only works in landscape mode, but there are other examples. 
>> Right now native apps can support this rather easily, but web apps 
>> have been stuck with silly hacks such as detecting that the 
>> orientation is wrong and asking the user to rotate. This further 
>> leads to trouble when the device itself is used as a controller (e.g. 
>> in racing games) as this can sometimes trigger an undesired 
>> orientation change mid-game — hardly a user-friendly experience.
>>
>> Note that this is not about system-level orientation lock (which 
>> would be fodder for another group) but application-level orientation.
>>
>> Options to address this have been discussed (amongst other places) here:
>>
>> http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/f38bb05e66c01a77#
>>
>> There is discussion as to whether this ought to be only an API or if 
>> it should use a <meta> element (which would also give it an API since 
>> it could be changed dynamically), with an overall leaning towards the 
>> latter. I am rather confident that we should be able to agree on the 
>> best approach relatively quickly.
>>
>> I will let implementers speak for themselves, but my understanding is 
>> that there is interest in this feature. It is certainly a regular 
>> request from developers.
>>
>> In previous discussions we haven't hashed out who would stand up as 
>> editor and test facilitator, but I'm confident that we can find 
>> people. If no one else steps up, I'll take the testing hat.
>>
>> WDYT?
>>
>
>

Received on Monday, 6 February 2012 12:22:03 UTC