Re: question about screen_size in Runtime and Security Model

On Saturday, 9 March 2013 at 18:49, Mounir Lamouri wrote:

> On 04/03/13 11:44, Marcos Caceres wrote:
> > This makes problematic assumptions about dimensions and pixel ratios, etc. and could end up conflicting with other parts of the platform (e.g., meta viewport and @viewport). And worst, we could end up specifying a useless feature that does nothing in practice.
> >  
> > In addition, this starts getting into dangerous territory of using these values to target particular device sizes. Unless we intend to have floating applications, I would strongly urge the WG to drop this.  
> >  
> > If, for business reasons, developers want to sell a tablet version and a phone version of their app, then they should do that through different origins:
> >  
> > hd.myapp.com (http://hd.myapp.com)
> > phone.myapp.com (http://phone.myapp.com)
>  
> If I recall correctly, the problem Mozilla's apps team was raising was
> not that related to business practices (sell two apps instead of one)
> but mostly to prevent users to get an application that wouldn't look
> good on their device. The same way a developer wouldn't want a user with
> a device that doesn't support webgl to buy a 3d game, a developer
> wouldn't want a 4" phone owner to buy an application that has been
> optimized for a 10" tablet or even desktop/laptop usage. Actually, the
> idea of buy/sell is a bit orthogonal here, the main problem being user
> satisfaction and developer's reputation.

I completely understand the challenge being faced here by developers - and, as someone who dabbles in Web development myself, I'm totally sympathetic to the work/costs required to make exceptional cross-device/cross-screen experiences. For better or for worst, the Web platform has always been a delivery platform where the size display area is both dynamic (people can resize their browser windows) and never guaranteed (resolutions and pixel densities vary widely). That's a strength of the platform: people are accustomed to resizing text, or zooming in on the virtual viewport in a way other platforms don't support. In this sense, the idea of fixed layout for a 4" phone or 10" tablet becomes kinda meaningless because the renderable area is never guaranteed.  

On the Web, we've come a long way with regards to solving this problem with media queries, responsive design and progressive enhancements. I'm just worried that this could be a second coming of the "best viewed at Xpx" days - and this time, actually sanctioned by a standard.  

Having said that, I'm sympathetic to the problem of certain kinds of applications (games in particular) requiring specific hardware/software capabilities to be able to run at all (specially if the end-user is making a purchase) … though, the advantage that the Web (hosted apps, at least) has here over native (and packaged apps) is that you can easily "try before you buy" in a way that native platforms can only dream of :). Imagine that, instead of just screenshots, you can have live pages where required non-security sensitive capabilities (e.g., WebGL, Web Audio) can be feature tested for by the application itself before the commitment to making a purchase.    
> This is why I believe we should move this to 'required_features'. This
> is actually nothing but a requirement for the device screen
> size/dpi/whatever.

I agree with you here. If it's a "must must… absolutely must!" that the screen be of a particular size, then required_feature seems like a much better fit for this (with the caveat the developers be told to avoid this kind of thing when possible and use other solutions - like meta viewport, or letter-boxing content).  
> I agree that the current manifest entry isn't great
> but I would prefer to keep it until we find a replacement.

It would be great if we can file a bug and link to it from the spec soliciting input to this problem as part of the FPWD. I'm happy to draft up some text if need be.   

Kind regards,
Marcos

Received on Saturday, 9 March 2013 20:02:38 UTC