Re: [manifest] orientation member
On Monday, January 27, 2014 at 9:47 PM, Jonas Sicking wrote: > On Mon, Jan 13, 2014 at 1:44 AM, Marcos Caceres (mailto:w...@marcosc.com)> wrote: > > Ok, makes sense. > > So my counter questions are: > > 1. Could we get away without using generic media queries and instead > only allow switching on screen size height and/or width? Probably - need to check if there is anything else on which this decision would be made. This is something we will need to look into. > 2. Could we get away with just using static orientations in v1? I.e. > punt using different orientations for mobile/tablet until v2 of the > manifest? > Personally, I think so. That's currently what is in the spec [1]. [1] http://w3c.github.io/manifest/#default_orientation-member
Re: [manifest] orientation member
On Mon, Jan 13, 2014 at 1:44 AM, Marcos Caceres wrote:
>
>
> On Wednesday, December 4, 2013 at 5:26 AM, Jonas Sicking wrote:
>
>> 3On Tue, Dec 3, 2013 at 4:20 AM, Mounir Lamouri > (mailto:mou...@lamouri.fr)> wrote:
>> > On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
>> > > My impression has been that the vast majority of apps only need a
>> > > single orientation that is independent of media-query results. If
>> > > that's the case, then I think the above is too complicated. I.e. if
>> > > that is the common case, then we should support:
>> > >
>> > > "orientation": ["landscape"],
>> > >
>> > > or maybe even
>> > >
>> > > "orientation": "landscape",
>> >
>> > I definitely agree with that. Though, we should allow both syntaxes
>> > (array and string).
>> > If we want a more complex system later, we could move to that. For the
>> > moment, I think we should keep it simple. Also, when comparing how
>> > applications handle landscape/portrait, it is worth considering how
>> > common/easy it is to write responsive UI on the platform. iOS has a very
>> > limited number of device sizes so I am not really surprised that iOS
>> > applications try to optimize for some sizes (thus arbitrary ignore some
>> > others). Is that common on Android? Would that be common using Web
>> > applications?
>>
>>
>>
>> I too am curious what the use cases are for switching orientation
>> based on screen size is. If your app runs fine in both orientations,
>> then why lock the orientation at all?
>
> Yes, of course when one presents it like that ("if it works on both, why lock
> it?") it seems to makes sense: but it’s overly simplistic: It’s only in the
> opposite case (on smaller devices/phones, single locked orientation makes
> more sense)… i.e., this is a “mobile first” design issue - where even though
> it “works” in landscape, the experience is so sub-optimal for some
> application types that it’s not worth optimizing/designing for. However, the
> Web case may be unique, in that installed applications are bookmarked from
> browsers, which generally support portrait and landscape on phones and
> anything bigger.
>
> You can see that the landscape experience is sub-optimal if you just play
> around with apps on your mobile phone that are not games. With the exceptions
> of a few apps (e.g., calculator on iPhone, which turns into a scientific
> calculator when rotated; and the Stocks app - which shows a graph view when
> rotated to landscape), I’m confident that you will see that even the ones
> that support rotation are not particularly useful in landscape mode (i.e.,
> are more natural to use in portrait - particularly web applications). Games
> are always the exception, as they really do require landscape to support for
> continuos interaction (i.e., because the user’s fingers are on the screen so
> would block too much of the viewport). Also, on phones, starting applications
> is generally done in portrait mode (at least on iPhone, Android, and FxOS) -
> so most apps are expecting to be launched and primarily used in portrait.
>
> But that’s not the case on tablets (particularly for applications that are
> both created for both phones and tablets) - where it’s natural to hold the
> device in any orientation. This leads to the problem:
>
> 1. an application may work best as portrait on a phone, but has to work on
> any orientation on tablet. Forcing a single orientation would only be useful
> for games - all other application types would need to support any (forcing
> developers to have to design for landscape on small devices when they don’t
> have to in their native counterparts - or worst, they have to display a
> “rotate your phone portrait” message to users, as some apps already do -
> e.g., forecast.io displays advertising for a future product when rotated to
> landscape).
>
> 2. Forcing an application on a table into portrait leads to a bad user
> experience (because a percentage of users will be unnecessarily forced to
> rotate their device to portrait). So I don’t imagine anyone will use this,
> unless they are using UA/device sniffing, which would show that the solution
> is broken.
Ok, makes sense.
So my counter questions are:
1. Could we get away without using generic media queries and instead
only allow switching on screen size height and/or width?
2. Could we get away with just using static orientations in v1? I.e.
punt using different orientations for mobile/tablet until v2 of the
manifest?
/ Jonas
Re: [manifest] orientation member
On Wednesday, December 4, 2013 at 3:22 AM, Scott Wilson wrote: > Hmm. Does this take us back to viewmodes [1]? For example you also have the > ability on Windows Phone to have the live tiles view, with primary and > secondary tiles, and both square and wide tiles... > I thought it did, but I don’t think it does… not yet anyway - but we are seeing a lot of overlap in the discussion (“windowed”, “fullscreen” for now). > Also it may be necessary to consider where apps are intended not to take over > the device, but as additional content within another platform, e.g.: > OpenSocial has 'canvas', 'profile' views, etc. However I think OpenSocial is > heading towards the option of just using adaptive CSS, along with contextual > metadata from the container platform via AJAX. That might work better, specially if we ever get @viewport support in browsers. > [1] http://www.w3.org/TR/view-mode/
Re: [manifest] orientation member
On Tuesday, December 3, 2013 at 10:20 PM, Mounir Lamouri wrote: > On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote: > > My impression has been that the vast majority of apps only need a > > single orientation that is independent of media-query results. If > > that's the case, then I think the above is too complicated. I.e. if > > that is the common case, then we should support: > > > > "orientation": ["landscape"], > > > > or maybe even > > > > "orientation": "landscape", > > I definitely agree with that. Though, we should allow both syntaxes > (array and string). I don’t like the idea of supporting two types, but can live with it. My preference is just having an array, and having unknown values ignored - at least that gives us some kind of extensibility mechanism. > If we want a more complex system later, we could move to that. As above - so long as whatever we come up with is somewhat future proof. > For the > moment, I think we should keep it simple. Also, when comparing how > applications handle landscape/portrait, it is worth considering how > common/easy it is to write responsive UI on the platform. It’s only technically easy. Design and UX wise it’s actually really hard in practice - and doing it cross platform/cross device is even harder because support for layout application technology remains in its infancy (i.e., Flexbox support is really lacking on mobile, and who knows how long that situation will continue for). In addition, the data we are seeing from applications that declare "apple-mobile-webapp-capable" show that developers are not doing this. Or, worst case, when apps are being rotated, they have to display a “rotate your phone the other way” message. > iOS has a very > limited number of device sizes so I am not really surprised that iOS > applications try to optimize for some sizes (thus arbitrary ignore some > others). Is that common on Android? Yes, it appears to be common on Android too. > Would that be common using Web > applications? Web apps don’t really have a choice. But you can try out your favorite apps on a phone in landscape move and see how usable they are: they may be usable (and some actually do provide a little adaptability - like BBC news), but it’s probably just coincidental that they work that was and not the way you would normally use them (unless its’ a game, of course). In any case, as you suggest, let’s build this up incrementally - but let’s make sure that we have a migratory path to give developers a choice to better control orientation.
Re: [manifest] orientation member
On Wednesday, December 4, 2013 at 5:26 AM, Jonas Sicking wrote:
> 3On Tue, Dec 3, 2013 at 4:20 AM, Mounir Lamouri (mailto:mou...@lamouri.fr)> wrote:
> > On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
> > > My impression has been that the vast majority of apps only need a
> > > single orientation that is independent of media-query results. If
> > > that's the case, then I think the above is too complicated. I.e. if
> > > that is the common case, then we should support:
> > >
> > > "orientation": ["landscape"],
> > >
> > > or maybe even
> > >
> > > "orientation": "landscape",
> >
> > I definitely agree with that. Though, we should allow both syntaxes
> > (array and string).
> > If we want a more complex system later, we could move to that. For the
> > moment, I think we should keep it simple. Also, when comparing how
> > applications handle landscape/portrait, it is worth considering how
> > common/easy it is to write responsive UI on the platform. iOS has a very
> > limited number of device sizes so I am not really surprised that iOS
> > applications try to optimize for some sizes (thus arbitrary ignore some
> > others). Is that common on Android? Would that be common using Web
> > applications?
>
>
>
> I too am curious what the use cases are for switching orientation
> based on screen size is. If your app runs fine in both orientations,
> then why lock the orientation at all?
Yes, of course when one presents it like that ("if it works on both, why lock
it?") it seems to makes sense: but it’s overly simplistic: It’s only in the
opposite case (on smaller devices/phones, single locked orientation makes more
sense)… i.e., this is a “mobile first” design issue - where even though it
“works” in landscape, the experience is so sub-optimal for some application
types that it’s not worth optimizing/designing for. However, the Web case may
be unique, in that installed applications are bookmarked from browsers, which
generally support portrait and landscape on phones and anything bigger.
You can see that the landscape experience is sub-optimal if you just play
around with apps on your mobile phone that are not games. With the exceptions
of a few apps (e.g., calculator on iPhone, which turns into a scientific
calculator when rotated; and the Stocks app - which shows a graph view when
rotated to landscape), I’m confident that you will see that even the ones that
support rotation are not particularly useful in landscape mode (i.e., are more
natural to use in portrait - particularly web applications). Games are always
the exception, as they really do require landscape to support for continuos
interaction (i.e., because the user’s fingers are on the screen so would block
too much of the viewport). Also, on phones, starting applications is generally
done in portrait mode (at least on iPhone, Android, and FxOS) - so most apps
are expecting to be launched and primarily used in portrait.
But that’s not the case on tablets (particularly for applications that are both
created for both phones and tablets) - where it’s natural to hold the device in
any orientation. This leads to the problem:
1. an application may work best as portrait on a phone, but has to work on any
orientation on tablet. Forcing a single orientation would only be useful for
games - all other application types would need to support any (forcing
developers to have to design for landscape on small devices when they don’t
have to in their native counterparts - or worst, they have to display a “rotate
your phone portrait” message to users, as some apps already do - e.g.,
forecast.io displays advertising for a future product when rotated to
landscape).
2. Forcing an application on a table into portrait leads to a bad user
experience (because a percentage of users will be unnecessarily forced to
rotate their device to portrait). So I don’t imagine anyone will use this,
unless they are using UA/device sniffing, which would show that the solution is
broken.
> I thought that the main use case was for something like a video player
> or a game that wanted to always be in landscape mode was the main use
> case?
>
No - specially the video use case is not really valid because videos will
usually just enter full screen mode and allow any orientation once they start
playing (think of them as an application within an application). Again, the
300+ odd apps we looked at paints a different picture: small device, then
single orientation (generally portrait primary) - unless it’s a game. Tablet
device, free to rotate to any orientation - tablet applications that lock to an
orientation are annoying in that they are unnatural to use (unless it’s a game,
of course).
We could assume that any orientation be supported on any device, but this means
we (browsers) are putting developers in a bad situation again of not having the
freedom to control how their applications are displayed on different device
type
Re: [manifest] orientation member
3On Tue, Dec 3, 2013 at 4:20 AM, Mounir Lamouri wrote: > On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote: >> My impression has been that the vast majority of apps only need a >> single orientation that is independent of media-query results. If >> that's the case, then I think the above is too complicated. I.e. if >> that is the common case, then we should support: >> >> "orientation": ["landscape"], >> >> or maybe even >> >> "orientation": "landscape", > > I definitely agree with that. Though, we should allow both syntaxes > (array and string). > If we want a more complex system later, we could move to that. For the > moment, I think we should keep it simple. Also, when comparing how > applications handle landscape/portrait, it is worth considering how > common/easy it is to write responsive UI on the platform. iOS has a very > limited number of device sizes so I am not really surprised that iOS > applications try to optimize for some sizes (thus arbitrary ignore some > others). Is that common on Android? Would that be common using Web > applications? I too am curious what the use cases are for switching orientation based on screen size is. If your app runs fine in both orientations, then why lock the orientation at all? I thought that the main use case was for something like a video player or a game that wanted to always be in landscape mode was the main use case? / Jonas
Re: [manifest] orientation member
Hmm. Does this take us back to viewmodes [1]? For example you also have the ability on Windows Phone to have the live tiles view, with primary and secondary tiles, and both square and wide tiles... Also it may be necessary to consider where apps are intended not to take over the device, but as additional content within another platform, e.g.: OpenSocial has 'canvas', 'profile' views, etc. However I think OpenSocial is heading towards the option of just using adaptive CSS, along with contextual metadata from the container platform via AJAX. S [1] http://www.w3.org/TR/view-mode/ On 3 Dec 2013, at 13:47, Mounir Lamouri wrote: > On Tue, Dec 3, 2013, at 23:32, John Mellor wrote: >>> I definitely agree with that. Though, we should allow both syntaxes >>> (array and string). >>> If we want a more complex system later, we could move to that. For the >>> moment, I think we should keep it simple. >> >> >> It seems an even simpler option would be to simply omit viewport from the >> manifest for now unless someone can provide a more compelling reason for >> it >> being there. > > I think those two options could live side by side. I guess on advantage > of the manifest is that the orientation can be set once and would apply > for the entire app. > >> How do the various UAs plan on avoiding a white flash of unpainted page >> when launching web apps? One potential solution to the white flash might >> be >> to delay opening a window for the web app until first paint. In which >> case, >> you wouldn't want to rotate the system UI before launching your window >> anyway... > > Interestingly, Chrome Apps is experimenting that: delaying showing new > window until the first paint happens to prevent a white flash. It is > only an experiment because there is the problem of the window not > showing for a long time if the first paint takes a long time to happen. > I think doing that on mobile would be easier because there is usually > one window showing at a time so the user would understand that the app > is being loaded. I'm a bit digressing though. > > -- > Mounir > PGP.sig Description: This is a digitally signed message part
Re: [manifest] orientation member
On Tue, Dec 3, 2013, at 23:32, John Mellor wrote: > > I definitely agree with that. Though, we should allow both syntaxes > > (array and string). > > If we want a more complex system later, we could move to that. For the > > moment, I think we should keep it simple. > > > It seems an even simpler option would be to simply omit viewport from the > manifest for now unless someone can provide a more compelling reason for > it > being there. I think those two options could live side by side. I guess on advantage of the manifest is that the orientation can be set once and would apply for the entire app. > How do the various UAs plan on avoiding a white flash of unpainted page > when launching web apps? One potential solution to the white flash might > be > to delay opening a window for the web app until first paint. In which > case, > you wouldn't want to rotate the system UI before launching your window > anyway... Interestingly, Chrome Apps is experimenting that: delaying showing new window until the first paint happens to prevent a white flash. It is only an experiment because there is the problem of the window not showing for a long time if the first paint takes a long time to happen. I think doing that on mobile would be easier because there is usually one window showing at a time so the user would understand that the app is being loaded. I'm a bit digressing though. -- Mounir
Re: [manifest] orientation member
On Tue, Dec 3, 2013 at 12:20 PM, Mounir Lamouri wrote: > On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote: > > My impression has been that the vast majority of apps only need a > > single orientation that is independent of media-query results. If > > that's the case, then I think the above is too complicated. I.e. if > > that is the common case, then we should support: > > > > "orientation": ["landscape"], > > > > or maybe even > > > > "orientation": "landscape", > > I definitely agree with that. Though, we should allow both syntaxes > (array and string). > If we want a more complex system later, we could move to that. For the > moment, I think we should keep it simple. It seems an even simpler option would be to simply omit viewport from the manifest for now unless someone can provide a more compelling reason for it being there. > Also, when comparing how > applications handle landscape/portrait, it is worth considering how > common/easy it is to write responsive UI on the platform. iOS has a very > limited number of device sizes so I am not really surprised that iOS > applications try to optimize for some sizes (thus arbitrary ignore some > others). Is that common on Android? Would that be common using Web > applications? > > On Tue, Dec 3, 2013, at 22:03, John Mellor wrote: > > Assuming @viewport is included in inline CSS in the (which it > > needs > > to be anyway, so the preload scanner can evaluate media attributes and > > responsive images), then the UA will parse the @viewport before it starts > > painting anything. Is there any benefit to the UA knowing the orientation > > before it starts painting the page? > > Not sure. Maybe if there are some bits of system UI, rotating that could > take longer than painting? > How do the various UAs plan on avoiding a white flash of unpainted page when launching web apps? One potential solution to the white flash might be to delay opening a window for the web app until first paint. In which case, you wouldn't want to rotate the system UI before launching your window anyway... > -- Mounir >
Re: [manifest] orientation member
On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote: > My impression has been that the vast majority of apps only need a > single orientation that is independent of media-query results. If > that's the case, then I think the above is too complicated. I.e. if > that is the common case, then we should support: > > "orientation": ["landscape"], > > or maybe even > > "orientation": "landscape", I definitely agree with that. Though, we should allow both syntaxes (array and string). If we want a more complex system later, we could move to that. For the moment, I think we should keep it simple. Also, when comparing how applications handle landscape/portrait, it is worth considering how common/easy it is to write responsive UI on the platform. iOS has a very limited number of device sizes so I am not really surprised that iOS applications try to optimize for some sizes (thus arbitrary ignore some others). Is that common on Android? Would that be common using Web applications? On Tue, Dec 3, 2013, at 22:03, John Mellor wrote: > Assuming @viewport is included in inline CSS in the (which it > needs > to be anyway, so the preload scanner can evaluate media attributes and > responsive images), then the UA will parse the @viewport before it starts > painting anything. Is there any benefit to the UA knowing the orientation > before it starts painting the page? Not sure. Maybe if there are some bits of system UI, rotating that could take longer than painting? -- Mounir
Re: [manifest] orientation member
On Tue, Dec 3, 2013 at 4:48 AM, Jonas Sicking wrote: > As I understand it, the main use case for putting orientation in the > manifest is to enable the UA to launch the app in the correct > orientation from the get-go. It seems very hard for an implementation > to do that with this solution. You would have to inspect the cached > HTML and CSS to figure out what the initial orientation will be. If > there is any HTML/CSS cached. If it's loaded from the server or a > service worker you're completely out of luck. > Assuming @viewport is included in inline CSS in the (which it needs to be anyway, so the preload scanner can evaluate media attributes and responsive images), then the UA will parse the @viewport before it starts painting anything. Is there any benefit to the UA knowing the orientation before it starts painting the page?
Re: [manifest] orientation member
On Fri, Nov 29, 2013 at 7:41 AM, Marcos Caceres wrote:
> Option 1: Provide a list of orientation sets in the manifest. The user agent
> uses the first one with a matching media query. The order in which the
> orientations are listed by a developer does not imply a preference for
> setting the orientation - it is always left up to the user agent to pick the
> best orientation given, for example, how the user is holding the device. In
> the example below, no orientation is given for widths of 721px or above, so
> the default is used: allowing all orientations supported by the device.
>
> {
> "orientations": [{
> "media": "max-width: 320px",
> "supported": ["portrait-primary", "landscape"]
> }, {
> "media": "max-width: 720px",
> "supported": ["landscape"]
> }]
> }
My impression has been that the vast majority of apps only need a
single orientation that is independent of media-query results. If
that's the case, then I think the above is too complicated. I.e. if
that is the common case, then we should support:
"orientation": ["landscape"],
or maybe even
"orientation": "landscape",
That could then scale to something as complex as what you have above
if really needed, which may or may not need to happen in the initial
version of the manifest spec.
One thing to keep in mind here is that applications that want complex
rules for orientation always have the option of not setting an
orientation in the manifest and instead using the JS API to do so.
The main benefit of the manifest is that it enables the UA to start
the application in the correct orientation right away, rather than
having to rotate the UI a fraction of a second after the app has been
started.
> Option 2: The second proposal is to remove orientation from the manifest and
> use CSS @viewport instead. This would mean:
>
>
>
> /*set it by default to portrait primary for small screens */
> @media (max-width: 320px) {
> @viewport {
> orientation: portrait-primary, landscape;
> }
> }
> /*Tablet, switch to landscape only*/
> @media (max-width: 720px) {
> @viewport {
> orientation: landscape;
> }
> }
>
> /* similarly on screens with a width of 721px or more, all
> orientations are allowed */
>
>
As I understand it, the main use case for putting orientation in the
manifest is to enable the UA to launch the app in the correct
orientation from the get-go. It seems very hard for an implementation
to do that with this solution. You would have to inspect the cached
HTML and CSS to figure out what the initial orientation will be. If
there is any HTML/CSS cached. If it's loaded from the server or a
service worker you're completely out of luck.
So I think using CSS should be possible, but it doesn't solve the same
use case as putting something in the manifest.
> Problem with using @viewport at the moment is that the specification is
> progressing a bit slowly and no one has implemented the "orientation"
> descriptor. It also lacks definitions for "-primary" and "-secondary"
> contraints, which are important for various applications, and doesn't
> currently allow providing multiple allowed orientations - hopefully the CSS
> Device Adaption spec can align with the Screen Orientation spec.
Yes. This is something that should be fixed irregardless of what the
manifest spec does.
/ Jonas
Re: [manifest] orientation member
Hi there
On Fri, Nov 29, 2013 at 4:41 PM, Marcos Caceres wrote:
> TLDR; orientation is hard. We've temporarily removed it from the spec. We
> have two proposals below.
Sounds good to me.
> Orientation of an application is dependent on the media features of the
> display. For example an application might need to be launched in landscape on
> phones (in order to have sufficient display width), but prefer to be in
> portrait on tablets.
>
> When analyzing applications across various runtimes, we've found evidence
> that such applications are common (e.g., basically any application on the
> iPhone that has an iPad counterpart will be designed to constrain to a
> particular orientation based on the device being used: LinkedIn, Flipboard,
> GoodReads, etc. will all go from portrait-primary on the iPhone to allowing
> "any" orientation on the iPad. A more extreme example is BBC iPlayer - which
> supports portrait-primary on the iPhone, but both landscape orientations on
> iPad. The same can be seen on Android devices. Unlike native apps, Web Apps
> should not target devices/OS's - they have to be device neutral.
>
> In order to address the use cases, we currently have two proposals.
>
> Option 1: Provide a list of orientation sets in the manifest. The user agent
> uses the first one with a matching media query. The order in which the
> orientations are listed by a developer does not imply a preference for
> setting the orientation - it is always left up to the user agent to pick the
> best orientation given, for example, how the user is holding the device. In
> the example below, no orientation is given for widths of 721px or above, so
> the default is used: allowing all orientations supported by the device.
>
> {
> "orientations": [{
> "media": "max-width: 320px",
> "supported": ["portrait-primary", "landscape"]
> }, {
> "media": "max-width: 720px",
> "supported": ["landscape"]
> }]
> }
>
> In this example, a device with a screen width of 320px or below would start
> either "portrait-primary" or "landscape" with the abilty to be "flipped"
> depending on how the user is holding the device (and OS permitting). A device
> with a screen width of 321px through 720px would request to be launched in
> landscape (leaving it up to the UA to pick either landscape-primary or
> landscape-secondary, while allowing "flippability"), and a device with a
> screen width of 721px and above would start in any orientation chosen by the
> UA (ideally, one that matches how the user is holding the device).
I am not much of a fan for duplicating parts of option 2 in JSON.
> Option 2: The second proposal is to remove orientation from the manifest and
> use CSS @viewport instead. This would mean:
>
>
>
> /*set it by default to portrait primary for small screens */
> @media (max-width: 320px) {
> @viewport {
> orientation: portrait-primary, landscape;
> }
> }
> /*Tablet, switch to landscape only*/
> @media (max-width: 720px) {
> @viewport {
> orientation: landscape;
> }
> }
>
> /* similarly on screens with a width of 721px or more, all
> orientations are allowed */
>
>
>
> Problem with using @viewport at the moment is that the specification is
> progressing a bit slowly and no one has implemented the "orientation"
> descriptor. It also lacks definitions for "-primary" and "-secondary"
> contraints, which are important for various applications, and doesn't
> currently allow providing multiple allowed orientations - hopefully the CSS
> Device Adaption spec can align with the Screen Orientation spec.
Let's finish up the Screen Orientation spec first and then see how the
same solution will fit with CSS Device Adaptation aka @viewport rule.
Kenneth
--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆
[manifest] orientation member
TLDR; orientation is hard. We've temporarily removed it from the spec. We have
two proposals below.
Orientation of an application is dependent on the media features of the
display. For example an application might need to be launched in landscape on
phones (in order to have sufficient display width), but prefer to be in
portrait on tablets.
When analyzing applications across various runtimes, we've found evidence that
such applications are common (e.g., basically any application on the iPhone
that has an iPad counterpart will be designed to constrain to a particular
orientation based on the device being used: LinkedIn, Flipboard, GoodReads,
etc. will all go from portrait-primary on the iPhone to allowing "any"
orientation on the iPad. A more extreme example is BBC iPlayer - which supports
portrait-primary on the iPhone, but both landscape orientations on iPad. The
same can be seen on Android devices. Unlike native apps, Web Apps should not
target devices/OS's - they have to be device neutral.
In order to address the use cases, we currently have two proposals.
Option 1: Provide a list of orientation sets in the manifest. The user agent
uses the first one with a matching media query. The order in which the
orientations are listed by a developer does not imply a preference for setting
the orientation - it is always left up to the user agent to pick the best
orientation given, for example, how the user is holding the device. In the
example below, no orientation is given for widths of 721px or above, so the
default is used: allowing all orientations supported by the device.
{
"orientations": [{
"media": "max-width: 320px",
"supported": ["portrait-primary", "landscape"]
}, {
"media": "max-width: 720px",
"supported": ["landscape"]
}]
}
In this example, a device with a screen width of 320px or below would start
either "portrait-primary" or "landscape" with the abilty to be "flipped"
depending on how the user is holding the device (and OS permitting). A device
with a screen width of 321px through 720px would request to be launched in
landscape (leaving it up to the UA to pick either landscape-primary or
landscape-secondary, while allowing "flippability"), and a device with a screen
width of 721px and above would start in any orientation chosen by the UA
(ideally, one that matches how the user is holding the device).
Option 2: The second proposal is to remove orientation from the manifest and
use CSS @viewport instead. This would mean:
/*set it by default to portrait primary for small screens */
@media (max-width: 320px) {
@viewport {
orientation: portrait-primary, landscape;
}
}
/*Tablet, switch to landscape only*/
@media (max-width: 720px) {
@viewport {
orientation: landscape;
}
}
/* similarly on screens with a width of 721px or more, all orientations
are allowed */
Problem with using @viewport at the moment is that the specification is
progressing a bit slowly and no one has implemented the "orientation"
descriptor. It also lacks definitions for "-primary" and "-secondary"
contraints, which are important for various applications, and doesn't currently
allow providing multiple allowed orientations - hopefully the CSS Device
Adaption spec can align with the Screen Orientation spec.
