W3C home > Mailing lists > Public > public-coremob@w3.org > June 2012

Re: coremob-ISSUE-8: No spec to point to for Full-screen mode. [COREMOB-1]

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Tue, 19 Jun 2012 14:45:11 +0100
Cc: "Robin Berjon" <robin@berjon.com>, "W3C CoreMob CG" <public-coremob@w3.org>
Message-Id: <80A6FC02-70FC-40A7-939F-4CDEC6E13E8E@gmail.com>
To: "Charles McCathieNevile" <chaals@opera.com>

On 19 Jun 2012, at 13:10, Charles McCathieNevile wrote:

> On Tue, 19 Jun 2012 11:36:54 +0200, Robin Berjon <robin@berjon.com> wrote:
> 
>> On Jun 19, 2012, at 11:11 , Charles McCathieNevile wrote:
>>> On Tue, 19 Jun 2012 10:32:07 +0200, Tobie Langel <tobie@fb.com> wrote:
>>>> You referring to [Fullscreen], I suppose. I should rename this feature to
>>>> chromeless to avoid confusion (although that might create another kind of
>>>> confusion).
>>> 
>>> Ah. Something like widgets?
>> 
>> It depends on how widgets are implemented :) There's nothing that says that widgets have to run chromeless (though they usually do).
> 
> Right. In Opera now they run as extensions, and I also unzip them and run them in panels...
> 
>>> (I saw another implementation of widgets last week running in a SMIL player on top of a webkit browser. I wonder how many there really are, and have been).
>> 
>> Widgets are easy to implement. I wonder how many have been security audited though Ś it's easy to get things rather wrong.

Check out Webinos, which is a secure W3C Widgets platform for multiple devices including in-vehicle systems:

https://developer.webinos.org/

Apache Wookie uses a fairly simple security model, as its aimed at widgets placed into portal-style applications. However even then its up to the container - so I saw one mil portal recently running inline chromless widgets in fixed positions, rather than the more typical netvibes/igoogle style arrangement.

> 
> The implementation I saw was for signs, where as I understand it the security layer is basically for the whole device which accesses restricted content.
> 
>>>> Here, what we're interested in is an API that lets us advise the UA
>>>> upfront we'd rather run without any browser chrome, similar to
>>>> [view-mode]'s fullscreen mode or Apple's [apple-mobile-web-app-capable]
>>>> meta tag.
>>> 
>>> OK, sorry for being confused.
>> 
>> Actually, we have to think a little bit beyond this being equal to view-mode=fullscreen. On (most) mobile devices, since every application is always full screen, when you remove the chrome you get a full screen application. But on anything that has an windowing system, there's a difference. I think that what's wanted here is view-mode=chromeless, which in a windowed environment would give you an app without chrome but not necessarily occupying the entire screen. And, of course, a way of requesting that a given view-mode be activated.
> 
> Yeah, or seperate the screen coverage aspect from the chrome, as Tobie said. I started a thread in native-web-apps on differentiating docked and minimised (currently they are the same) on the basis that rendering for minimised is generally under control of the app within the size constraint, whereas in docked situations (toolbar buttons, system trays, etc) they are generally far more limited.
> 
> But it turned out I hadn't got it quite right in terms of my own use case - so I should return to that discussion.
> 
>>>> I feel like a declarative API would be better for this.
>>> 
>>> So being able to request a view-mode? That's in the widgets P&C although it sounds like there is a goal to seperate config from packaging and be able to use live web content. That has been expressed before (and is the conceptual difference between widgets on the one hand appcache and the proposed JSON packaging manifest offers on the other, the rest being a matter of syntax and implementation quality).
>>> 
>>> The place for that might be the native-web-apps community group.
>> 
>> Why could this not be an additional view-mode, which could be included in the application configuration that WebApps is working on?
> 
> What's additional about it? I think this is the assumed, but often implicit "default". (In Opera's implementations that is the case...)
> 
> cheers
> 
> Chaals
> 
> -- 
> Charles 'chaals' McCathieNevile  Opera Software, Standards Group
>    je parle franšais -- hablo espa˝ol -- jeg kan noen norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com
> 
Received on Tuesday, 19 June 2012 13:45:55 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:46 UTC