RFC: <meta name=viewport> support in B2G

[Philipp von Weitershausen]

Background: Mobile devices have much less screen real-estate than
desktop computers. Many traditional websites expect viewports that are
wider than O(400px), though. That's why mobile browsers typically
render pages to viewports that are much bigger (O(1000px)) and
initially present them zoomed out (if necessary). The user can then
zoom in as they wish. For web apps that *are* optimized for small
screen real estate, Apple originally added the <meta name=viewport>
directive to Mobile Safari for letting the app control various
viewport properties such as initial size and scale as well as
zoomability. This has since been adopted by all major mobile browsers,
including Fennec and is kind of a de-facto standard, for better or for
worse. See e.g.
https://developer.mozilla.org/en/Mobile/Viewport_meta_tag and
http://www.quirksmode.org/blog/archives/2012/07/webkit_as_defac.html

In B2G we are now faced with the following questions:

(a) in which cases should we support <meta name=viewport>?

(b) what should the default viewport settings be?

If Fennec supports <meta name=viewport>, there's a strong case to be
made that browser windows in B2G should too. This presumably means it
should apply to <iframe mozbrowser> as used in browser tabs and, when
sites are "bookmarked" to the homescreen somehow, also to their
<iframe mozbrowser> containers. Basically, whenever we show "regular"
websites, we should be on par with Fennec.

A more open question is whether beyond that it should apply to <iframe
mozbrowser mozapp> elements, in other words, apps that have been
installed as such.

I can come up with the following pros and cons:

Pro:
* We've been promoting Open Web Apps as a very lightweight mechanism
around already existing web apps. Rendering them differently depending
on whether they're installed or running in a browser could be
interpreted as breaking the promise that essentially reads "B2G apps
=== web apps".
* With <meta name=viewport> being part of the defacto mobile web,
mobile web app developers would presumably expect it to work on B2G.

Con:
* <meta name=viewport> is a non-standard hack that is better served by
e.g. the @viewport CSS rule http://dev.w3.org/csswg/css-device-adapt/.
We should allow regular web content to function for now, as we do in
Fennec, but not promote it as part of our app stack.

Thoughts? More pros/cons?


P.S.: The implementation is being tracked at
https://bugzilla.mozilla.org/show_bug.cgi?id=746502.

[Matt Brubeck]

On 07/11/2012 09:22 PM, Philipp von Weitershausen wrote:
> * <meta name=viewport> is a non-standard hack that is better served by
> e.g. the @viewport CSS rule http://dev.w3.org/csswg/css-device-adapt/.
> We should allow regular web content to function for now, as we do in
> Fennec, but not promote it as part of our app stack.

<meta name=viewport> is exactly as standard as @viewport, since both of
them are specified only in the CSS Device Adaptation editors' draft
linked above. So even if @viewport becomes a standard, the equivalent
meta attribute will become one too. If we want it to go away, we should
be trying much harder to replace and deprecate it, and we should start
that effort two or three years ago.

The @viewport rule is implemented (with vendor prefixes) only in recent
versions of Opera Mini/Mobile, and in IE10. It won't be a viable option
for content on the web for quite a while. In the meantime, <meta
name=viewport> is the only tool for some common use cases for mobile app
developers, and is also part of the proposed standard for those use
cases. Refusing to support it for B2G apps will cause developer pain
for no benefit that I can see.

[Philipp von Weitershausen]

On Wed, Jul 11, 2012 at 11:41 PM, JOSE MANUEL CANTERA FONSECA
<jm...@tid.es> wrote:
>>In B2G we are now faced with the following questions:
>>
>>(a) in which cases should we support <meta name=viewport>?
>

> Meta name=viewport should be supported, but probably only
> width=device-width and not any "arbitrary" value

Why would you not allow other viewport widths? Also, the question was:
"in which cases", not "whether" :)

>>(b) what should the default viewport settings be?
>

> Wishlist: If the content is mobile targeted it will be very likely that
> the author have set a width=device-width.

Likely, though not guaranteed. I could imagine games setting the
viewport to a fixed size and then using the zoom factor to fit it on
the screen.

> If the content is not adapted to
> mobile then the browser should be creating a viewport with the same
> dimensions as those currently presented by Webkit on Android or iOS,
> allowing the user to zoom or pan

Right. And for installed apps we should probably default to device-width.

>>* We've been promoting Open Web Apps as a very lightweight mechanism
>>around already existing web apps. Rendering them differently depending
>>on whether they're installed or running in a browser could be
>>interpreted as breaking the promise that essentially reads "B2G apps
>>=== web apps".
>

> If an app is wild on the Web it is reasonable to think that it is not
> adapted to mobile.

But if it's an app with a manifest, we could probably expect at least
a minimum of mobile-readiness. So at least setting the *default*
viewport size to device-width would make sense to me. The question is
whether we should completely ignore any other viewport directive.

>>Con:

>>* <meta name=viewport> is a non-standard hack that is better served by
>>e.g. the @viewport CSS rule http://dev.w3.org/csswg/css-device-adapt/.
>>We should allow regular web content to function for now, as we do in
>>Fennec, but not promote it as part of our app stack.
>

> I think meta viewport is going to stay

Probably. Though hopefully most mobile apps will declare
width=device-width, which should also be our default for installed web
apps, thus making it mostly useless. So there's hope yet for it to
die.

[JOSE MANUEL CANTERA FONSECA]

El 13/07/12 00:39, "Philipp von Weitershausen" <phil...@googlemail.com>
escribió:

>On Wed, Jul 11, 2012 at 11:41 PM, JOSE MANUEL CANTERA FONSECA
><jm...@tid.es> wrote:
>>>In B2G we are now faced with the following questions:
>>>
>>>(a) in which cases should we support <meta name=viewport>?
>>
>> Meta name=viewport should be supported, but probably only
>> width=device-width and not any "arbitrary" value
>
>Why would you not allow other viewport widths? Also, the question was:
>"in which cases", not "whether" :)

It can be supported but I don't know if the effort is worth it, some
investigation might be needed but my suspect is that the majority of
authors are using width=device-width

>
>>>(b) what should the default viewport settings be?
>>
>> Wishlist: If the content is mobile targeted it will be very likely that
>> the author have set a width=device-width.
>
>Likely, though not guaranteed. I could imagine games setting the
>viewport to a fixed size and then using the zoom factor to fit it on
>the screen.

Yes, that's a good point but we need to see if it is happening in real
world

>
>> If the content is not adapted to
>> mobile then the browser should be creating a viewport with the same
>> dimensions as those currently presented by Webkit on Android or iOS,
>> allowing the user to zoom or pan
>
>Right. And for installed apps we should probably default to device-width.
>
>>>* We've been promoting Open Web Apps as a very lightweight mechanism
>>>around already existing web apps. Rendering them differently depending
>>>on whether they're installed or running in a browser could be
>>>interpreted as breaking the promise that essentially reads "B2G apps
>>>=== web apps".
>>
>> If an app is wild on the Web it is reasonable to think that it is not
>> adapted to mobile.
>
>But if it's an app with a manifest, we could probably expect at least
>a minimum of mobile-readiness. So at least setting the *default*
>viewport size to device-width would make sense to me. The question is
>whether we should completely ignore any other viewport directive.

If an author has taken care of a minimum mobile readiness I think the
first thing he would have been doing is setting a meta viewport ... But I
tend to agree that the most wild content will be that loaded from the
browser and in that case we will assume by default that zooming and
panning would be needed ...

>
>>>Con:
>>>* <meta name=viewport> is a non-standard hack that is better served by
>>>e.g. the @viewport CSS rule http://dev.w3.org/csswg/css-device-adapt/.
>>>We should allow regular web content to function for now, as we do in
>>>Fennec, but not promote it as part of our app stack.
>>
>> I think meta viewport is going to stay
>
>Probably. Though hopefully most mobile apps will declare
>width=device-width, which should also be our default for installed web
>apps, thus making it mostly useless. So there's hope yet for it to
>die.

Useless when the app is run in B2G but useful in other contexts such as
Phonegap

>



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Jonas Sicking]

On Wed, Jul 11, 2012 at 9:22 PM, Philipp von Weitershausen
<phil...@googlemail.com> wrote:
> Background: Mobile devices have much less screen real-estate than
> desktop computers. Many traditional websites expect viewports that are
> wider than O(400px), though. That's why mobile browsers typically
> render pages to viewports that are much bigger (O(1000px)) and
> initially present them zoomed out (if necessary). The user can then
> zoom in as they wish. For web apps that *are* optimized for small
> screen real estate, Apple originally added the <meta name=viewport>
> directive to Mobile Safari for letting the app control various
> viewport properties such as initial size and scale as well as
> zoomability. This has since been adopted by all major mobile browsers,
> including Fennec and is kind of a de-facto standard, for better or for
> worse. See e.g.
> https://developer.mozilla.org/en/Mobile/Viewport_meta_tag and
> http://www.quirksmode.org/blog/archives/2012/07/webkit_as_defac.html
>

> In B2G we are now faced with the following questions:
>
> (a) in which cases should we support <meta name=viewport>?
>

> (b) what should the default viewport settings be?
>

> If Fennec supports <meta name=viewport>, there's a strong case to be
> made that browser windows in B2G should too.

It does.

> This presumably means it
> should apply to <iframe mozbrowser> as used in browser tabs and, when
> sites are "bookmarked" to the homescreen somehow, also to their
> <iframe mozbrowser> containers. Basically, whenever we show "regular"
> websites, we should be on par with Fennec.

Agreed.

> A more open question is whether beyond that it should apply to <iframe
> mozbrowser mozapp> elements, in other words, apps that have been
> installed as such.
>
> I can come up with the following pros and cons:
>
> Pro:

> * We've been promoting Open Web Apps as a very lightweight mechanism
> around already existing web apps. Rendering them differently depending
> on whether they're installed or running in a browser could be
> interpreted as breaking the promise that essentially reads "B2G apps
> === web apps".

> * With <meta name=viewport> being part of the defacto mobile web,
> mobile web app developers would presumably expect it to work on B2G.
>

> Con:
> * <meta name=viewport> is a non-standard hack that is better served by
> e.g. the @viewport CSS rule http://dev.w3.org/csswg/css-device-adapt/.
> We should allow regular web content to function for now, as we do in
> Fennec, but not promote it as part of our app stack.
>

> Thoughts? More pros/cons?

I suspect the webapps team has been looking at this. I'd really like
to hear what their thoughts are.

/ Jonas