Based on the feedbacks I've updated the draft:
http://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html
- Got rid of string enum, instead introduced navigator.persistentStorage
and navigator.temporaryStorage
- Some interface name changes (just for IDL)
QuotaStorageEnvironment -> StorageQuotaEnvi
What do you do when element A goes fullscreen and then element B in the
same document goes fullscreen on top of it? Do you fire a single
fullscreenchange event at B? Or do you fire a fullscreenchange event at A
and then at B? Or something else?
Rob
--
“You have heard that it was said, ‘Love your
On Tue, May 29, 2012 at 10:48 PM, Deepanshu Gautam
wrote:
> Please refer to the email thread below
>
> http://lists.w3.org/Archives/Public/public-web-intents/2012May/0054.html
>
> Where a consensus was reached to delete the following statement from the
> Suggestions related text.
>
> "The User Ag
On 5/30/12 2:36 PM, ext Arthur Barstow wrote:
What are people's thoughts on whether or not the Quota Management API
spec is ready for First Public Working Draft (FPWD)?
(Ooops, c&p error above: s/Quota Management/Webapp Manifest/)
A "rule of thumb" for FPWD is that the ED's scope should cover
I agree that they should be non-normative and that we should avoid
using MAY etc in them. However we should make sure that somewhere
there's a normative statement that says that implementations are
allowed to make .indexedDB be null, or that .open always returns error
for security and/or privacy re
On 06/05/2012 09:27 PM, Tobie Langel wrote:
> On 6/5/12 4:00 PM, "Mounir Lamouri" wrote:
>
>> On 05/31/2012 03:28 PM, Tobie Langel wrote:
>>> I'm probably missing something here, but notifications don't seem to be
>>> going through a system- / browser-wide notification panel from which the
>>> us
On Tue, 05 Jun 2012 21:27:57 +0200, Tobie Langel wrote:
Overall, I feel like writing down use cases and requirements would be
something useful to do at this point. What do you think?
Definitely.
cheers
--
Charles 'chaals' McCathieNevile Opera Software, Standards Group
je parle français
On Mon, 4 Jun 2012, Adam Barth wrote:
> >
> > � http://www.hixie.ch/specs/e4h/strawman
> >
> > Who wants to be first to implement it?
>
> Doesn't e4h have the same security problems as e4x?
As written it did, yes (specifically, if you can inject content into an
XML file you can cause it to run J
Jonas,
Do you agree with Tobie that Sections 6 & 7 should be non-normative? If so, I
am happy to take care of this.
Cheers.
Eliot
> -Original Message-
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Monday, June 04, 2012 12:28 AM
> To: Tobie Langel
> Cc: public-webapps@w3.org
>
On 6/5/12 4:00 PM, "Mounir Lamouri" wrote:
>On 05/31/2012 03:28 PM, Tobie Langel wrote:
>> I'm probably missing something here, but notifications don't seem to be
>> going through a system- / browser-wide notification panel from which the
>> user can decide whether or not to navigate to an applic
Here's another installment of updates around Web Components:
COMPONENTS INTRO
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14949&hide_resolved=1):
* The document is now a FPWD: http://www.w3.org/TR/components-intro/
SHADOW DOM
(https://www.w3.org/Bugs/Public/showdependencytree.cgi?i
On Jun 5, 2012, at 1:06 AM, Anne van Kesteren wrote:
> Why should we standardize this if we always notify the document? Is
> there a benefit to notifying both the element and the document?
I think Vincent put forward a reasonable argument. The document is a finite,
shared resource. Requiring
On Tue, Jun 5, 2012 at 1:06 AM, Anne van Kesteren wrote:
> On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble wrote:
>> Actually, in WebKit, we explicitly also message the document from which the
>> element was removed in that case. I don't see why this behavior couldn't be
>> standardized.
>
> Why sh
On 05/31/2012 03:28 PM, Tobie Langel wrote:
> I'm probably missing something here, but notifications don't seem to be
> going through a system- / browser-wide notification panel from which the
> user can decide whether or not to navigate to an application. In other
> words, it looks like we're cons
On Mon, Jun 4, 2012 at 6:30 PM, Tobie Langel wrote:
> On 6/4/12 11:17 AM, "Anne van Kesteren" wrote:
>
> >On Mon, Jun 4, 2012 at 11:01 AM, Tobie Langel wrote:
> >> Finally, I feel it's slightly misleading to have an interface called
> >> "info" which enables changes (through `requestQuota`). Wo
On Tue, Jun 5, 2012 at 11:02 AM, Adam Barth wrote:
>> On Tue, Jun 5, 2012 at 2:10 AM, Adam Barth wrote:
>> If you mean http://code.google.com/p/doctype-mirror/wiki/ArticleE4XSecurity
>> I guess that would depend on how we define it.
>
> By the way, it occurs to me that we can solve these security
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17321
Art Barstow changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17321
Summary: Implementors should be aware that this specification
is not stable. Implementors who are not taking part in
the discussions are likely to find the specification
chan
Greetings Dom,
Thanks for your bug reports and sorry for my slow response.
I will update this draft next week to apply them. (Unfortunately, I
cannot afford to fix this draft this week.)
Regards,
Hironori Bono
E-mail: hb...@google.com
On Mon, Jun 4, 2012 at 4:19 PM, Dominique Hazael-Massieux w
On Tue, Jun 5, 2012 at 2:10 AM, Adam Barth wrote:
> Doesn't e4h have the same security problems as e4x?
If you mean http://code.google.com/p/doctype-mirror/wiki/ArticleE4XSecurity
I guess that would depend on how we define it.
A (bigger?) problem with E4H/H4E is that TC39 does not like it:
http:
On Tue, Jun 5, 2012 at 12:58 AM, Anne van Kesteren wrote:
> On Tue, Jun 5, 2012 at 2:10 AM, Adam Barth wrote:
>> Doesn't e4h have the same security problems as e4x?
>
> If you mean http://code.google.com/p/doctype-mirror/wiki/ArticleE4XSecurity
> I guess that would depend on how we define it.
By
On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble wrote:
> Actually, in WebKit, we explicitly also message the document from which the
> element was removed in that case. I don't see why this behavior couldn't be
> standardized.
Why should we standardize this if we always notify the document? Is
ther
On 06/05/2012 09:31 AM, Jer Noble wrote:
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan wrote:
If you implemented that proposal as-is then authors would usually need a
listener on the document as well as the element, and as Chris pointed
out, it's simpler to just always listen on the documen
23 matches
Mail list logo
