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

On Tue, 19 Jun 2012 11:36:54 +0200, Robin Berjon <> wrote:

> On Jun 19, 2012, at 11:11 , Charles McCathieNevile wrote:
>> On Tue, 19 Jun 2012 10:32:07 +0200, Tobie Langel <> 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.

The implementation I saw was for signs, where as I understand it the  
security layer is basically for the whole device which accesses restricted  

>>> 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...)



Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan noen norsk       Try Opera:

Received on Tuesday, 19 June 2012 12:10:53 UTC