[whatwg] Forcing orientation in content

Thu Apr 18 01:59:47 PDT 2013

On Thursday, April 18, 2013 at 10:08 AM, David Bruant wrote:
> Le 18/04/2013 01:03, Charles McCathie Nevile a écrit :
> > Hi,
> >  
> > On Thu, 18 Apr 2013 01:52:47 +0300, David Bruant <bruant.d at gmail.com (mailto:bruant.d at gmail.com)>  
> > wrote:
> >  
> > > Hi,
> > >  
> > > Currently working on a web project where tablet support (iPad  
> > > especially) is important, I'm facing a need which apparently the  
> > > platform doesn't support.
> > > I would need to lock the screen in landscape mode.
> >  
> >  
> >  
> > Not sure if WHATWG is doing anything, but in the W3C there is  
> > https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html  
> > in the Web Apps group (by Mounir, who works on Firefox OS as a day job)
>  
>  
> Thanks for the pointer! But as said very explicitly in the screen  
> orientation draft:
> " This specification doesn't intend to specify a declarative orientation  
> locking. However, other specifications specify ways to do that.
>  
> The Web Application Manifest Format and Management APIs  
> [WEBAPPS-MANIFEST-API] specifies a way to declare a default orientation  
> for a web application inside the manifest file."
>  
> And I really wished it was a declarative thing.
>  
> I understand the value of locking dynamically in some cases, but both in  
> my use case and the Romanian guy use case, we want to lock the screen  
> once and for all at the beginning. The web browser shouldn't have to  
> wait for JS execution to know how to render things. I'm afraid it will  
> result in a graphic glitch at application startup if a first frame is  
> rendered *before* the JS saying "lockOrientation" is executed.
> If the locking is expressed declaratively in the <head>, no such glitch  
> is possible, resulting in a better user experience.
>  
> I feel an inline <style> inside <head> with @viewport{orientation: xxx}  
> [1] could work though. It's declarative and is read before the <body>,  
> so before any useful frame can be rendered, so no glitch.

Similar thinking[2] from the Coremob CG, which, for the same kind of use case[3] advocates exploring other solutions such as a JavaScript API for css-adaptation which already has an orientation property[4] and a mapping[5] to the viewport meta tag, which is ubiquitous on mobile. This gives you both a declarative and imperative API, which fits all use cases.

--tobie (who is getting a kick out of quoting himself not once, but twice.)

---
[2]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#screen-orientation

[3]: http://coremob.github.io/coremob-2012/FR-coremob-20130131.html#play-a-2d-game
[4]: http://dev.w3.org/csswg/css-device-adapt/#orientation
[5]: http://dev.w3.org/csswg/css-device-adapt/#viewport-meta