On Fri, 14 Oct 2011 11:27:21 +0900, Ojan Vafai wrote:
I guess I'd be fine with saying that the undomanager is created at the
time the undoscope property is set, but I'm not sure what we can do
about the
non-editable --> editable case.
So that case is when you have
and then set co
On Thu, Oct 13, 2011 at 7:19 PM, Ryosuke Niwa wrote:
> On Thu, Oct 13, 2011 at 7:06 PM, Ojan Vafai wrote:
>>
>> When an element with an undoscope goes from editable to non-editable, does
>> it then get a fresh undo stack? When it goes from non-editable to editable
>> does it lose it's undo stack
On Thu, Oct 13, 2011 at 7:06 PM, Ojan Vafai wrote:
>
> When an element with an undoscope goes from editable to non-editable, does
> it then get a fresh undo stack? When it goes from non-editable to editable
> does it lose it's undo stack? I think the answer to both those questions
> should be yes,
On Thu, Oct 13, 2011 at 6:43 PM, Anne van Kesteren wrote:
> On Fri, 14 Oct 2011 05:07:18 +0900, Ryosuke Niwa wrote:
>
>> On Tue, Oct 11, 2011 at 1:02 PM, Ehsan Akhgari wrote:
>>
>>> This sounds reasonable. The content attribute should be made
non-conforming in that case. Perhaps the IDL at
On Fri, 14 Oct 2011 05:07:18 +0900, Ryosuke Niwa wrote:
On Tue, Oct 11, 2011 at 1:02 PM, Ehsan Akhgari wrote:
This sounds reasonable. The content attribute should be made
non-conforming in that case. Perhaps the IDL attribute should throw
on setting? Maybe better to just do nothing, but that d
On Tue, Oct 11, 2011 at 1:02 PM, Ehsan Akhgari wrote:
>
> > This sounds reasonable. The content attribute should be made
> > non-conforming in that case. Perhaps the IDL attribute should throw
> > on setting? Maybe better to just do nothing, but that doesn't give
> > the author any idea of what's
That is a *great* addition, thank you Justin. Perhaps "offline-capable"
should be changed to "offline-status" with two possible parameters:
"capable" and "ready", the former indicating that the app has the potential
to function offline, and the latter indicating that the app can presently
function
On Thu, 13 Oct 2011 19:21:59 +0900, Chris Pearce
wrote:
On 13/10/2011 5:23 p.m., Anne van Kesteren wrote:
Is the event dispatched synchronously as well then? I was thinking
that maybe you want to trigger an animation here of some kind. Though
I suppose that could be done synchronously as well.
Hi Brian,
I think this is a very interesting proposition. I would like to add
that there should also be UA-native indication to the user that an app
can become offline-capable upon request, along with a mechanism for
requesting offline capability, and for triggering app data
synchronization. The
It seems to me that "being fullscreen" is a property of the top-level
browsing context. All that is potentially associated with a document is
the "fullscreen element". If you have a document A with two
sub-documents B and C, it does not make much sense to me that if you go
fullscreen from
On 13/10/2011 5:23 p.m., Anne van Kesteren wrote:
On Thu, 13 Oct 2011 11:26:20 +0900, Chris Pearce
wrote:
On 12/10/2011 10:35 p.m., Anne van Kesteren wrote:
Is cancelFullScreen() synchronous or should it queue a task?
Synchronous, so that Document.fullScreen immediately reflects the
state c
11 matches
Mail list logo
