Re: add "orientation" to Widgets: P&C

On 6/20/12 8:34 AM, "Scott Wilson" <scott.bradley.wilson@gmail.com> wrote:

>Expressing a preferred starting orientation is a common use case for web
>apps; the Mozilla proposal includes this[1], as does the PhoneGap
>implementation of Widgets:P&C (using Preferences)[2].

This is also something the Coremob CG feels strongly about. Being able
express a preference for a given orientation is critical for building
HTML5 games on mobile devices.

>Outside of mobile, we also have a use case for portal applications built
>with Apache Rave, where we may want to place a widget into a page region
>depending on whether it would better suit a wide or narrow region in the
>layout.
>
>Orientation also already exists as a Media Feature[3]; there are two
>valid values of the orientation media feature, 'portrait' and 'landscape':
>
>"The Œorientation¹ media feature is Œportrait¹ when the value of the
>Œheight¹ media feature is greater than or equal to the value of the
>Œwidth¹ media feature. Otherwise Œorientation¹ is Œlandscape¹."
>
>PhoneGap also has "default", however this doesn't actually mean "default"
>but " enable both":
>
>"please note that default means both landscape and portrait are enabled.
>If you want to use each platform's default settings (usually
>portrait-only), just remove this tag from your config.xml"
>
>So orientation can refer to either or both of the preferred starting
>orientation of the web app, and the orientations enabled for the web app.

Worth looking at the work going on in [Device Adaptation]. I like auto
much more than "both" + "default" which is extremely confusing for authors
and the end users alike.

>I suggest an orientation property with the following semantics:
>
>orientation = "portrait" // enable portrait only
>orientation = "landscape" // enable landscape only
>orientation = "portrait landscape" // enable both, start in portrait by
>default
>orientation = "landscape portrait" // enable both, start in landscape by
>default
>orientation = "both" // enable both portrait and landscape orientation,
>start in current user agent orientation
>[no value] // use user agent defaults

Needing to mix app life-cycle into this calls for finer-grained control,
i.e. being able to modify this setting on a document level (via Device
Adaptation?) or via scripting (using Mozilla's [Screen Orientation]?).

So this is either indicative of a mistake in the level at which the
feature is being added or a scope creep.

That said, I think your proposal misses an important use case: enabling
locking the orientation of games.

Typically, this is necessary not only because a given game is playable in
portrait mode only, but also because auto-rotation of the device during
the game would ruin the game play. That's why it is important for games to
be also able to prevent auto-rotation.

Should that be expressed through more precise params inspired from
Mozilla's proposal: portrait, landscape, portrait-primary,
portrait-secondary, landscape-primary, landscape-secondary, auto? Should
there be a different setting (prevent-autorotation) for that use case? I'm
not sure.

>This could be added to Widgets:P&C as an attribute of the widget element;
>this would also need to be harmonized in the mozilla proposal.
>Alternatively, this could be developed as a standalone spec usable by
>both, a bit like VMMF[4].

Where this ends up happening has a lot to do with how fine-grained it
needs to be. Think we need use cases here.

--tobie

---
[Device Adaptation]: http://dev.w3.org/csswg/css-device-adapt/#orientation
[Screen Orientation]:
http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html

Received on Wednesday, 20 June 2012 07:55:47 UTC