Re: W3C XML Digital Signature Object Element Processing Issue

2010-12-15 Thread Andreas Kuehne
Hi Deepak, I guess you came across some of the very common problems of XML signature verification. Do you use a ready-made toolkit ( like Bouncy Castle ) ? I guess you have to dig into the details of reference resolving ... But I would propose another approach for your scenario : I'm member of

Re: [Bug 11553] New: Ensure indexedDBSync is on the right worker interface

2010-12-15 Thread Jeremy Orlow
I believe the instance of WorkerUtils is much like window in a page. I.e. you put stuff on there that you want in the global scope. Thus I'm pretty sure that WorkerUtils is the right place for both. J On Wed, Dec 15, 2010 at 1:54 AM, bugzi...@jessica.w3.org wrote:

Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers

2010-12-15 Thread Jeremy Orlow
On Wed, Dec 15, 2010 at 3:42 AM, Jonas Sicking jo...@sicking.cc wrote: Speaking of which, we use UNKNOWN_ERR for a bunch of other internal consistency issues. Is this OK by everyone, should we use another, or should we create a new one? (Ideally these issues will be few and far between

[widgets] Storage keys and ECMAScript incompatibility?

2010-12-15 Thread Scott Wilson
We've come across an issue with storage keys in Widget preferences; namely that the Web Storage spec [1] states that: Keys are strings. Any string (including the empty string) is a valid key. Values can be any data type supported by the structured clone algorithm. However, common guidance on

Re: [widgets] Storage keys and ECMAScript incompatibility?

2010-12-15 Thread timeless
On Wed, Dec 15, 2010 at 3:29 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: things like widgets.preferences.12345=xyz throw exceptions. widgets.preferences[12345]=xyz probably works...

Re: [widgets] Storage keys and ECMAScript incompatibility?

2010-12-15 Thread Tab Atkins Jr.
On Wed, Dec 15, 2010 at 5:29 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: We've come across an issue with storage keys in Widget preferences; namely that the Web Storage spec [1] states that: Keys are strings. Any string (including the empty string) is a valid key. Values can be any

Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Tab Atkins Jr.
On Tue, Dec 14, 2010 at 10:32 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/14/10 10:08 PM, Tab Atkins Jr. wrote: Hm, good point.  So then, no, there has to be an element in the shadow DOM that represents an output port, which is then *replaced* with the appropriate normal-DOM children in

Re: [widgets] Storage keys and ECMAScript incompatibility?

2010-12-15 Thread Scott Wilson
On 15 Dec 2010, at 15:50, Tab Atkins Jr. wrote: On Wed, Dec 15, 2010 at 5:29 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: We've come across an issue with storage keys in Widget preferences; namely that the Web Storage spec [1] states that: Keys are strings. Any string (including

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Boris Zbarsky
On 12/15/10 7:51 AM, Tab Atkins Jr. wrote: Yes to the first two. Maybe to the last - the final flattened tree is just what's handed to CSS as the element-tree. There aren't really DOM nodes there, or at least it doesn't matter whether or not there is. OK. (Events and such don't work on the

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Tab Atkins Jr.
On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 7:51 AM, Tab Atkins Jr. wrote: (Events and such don't work on the final flattened tree Sort of.  Hit testing clearly needs to work on the layout structure generated from the final flattened tree, so event

Re: [widgets] Storage keys and ECMAScript incompatibility?

2010-12-15 Thread timeless
note that i should have said: widgets.preferences[12345]=xyz probably works... since other reserved words don't work well unquoted... and obviously if your identifier includes , ', or \, you may need to quote it or escape it appropriately...

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Dimitri Glazkov
On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 7:51 AM, Tab Atkins Jr. wrote: (Events and such don't work on the final flattened tree Sort of.  Hit testing clearly needs to work

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Dimitri Glazkov
On Wed, Dec 15, 2010 at 11:10 AM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Dec 15, 2010 at 10:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Dec 15, 2010 at 10:19 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 7:51 AM, Tab Atkins Jr. wrote: (Events and such don't

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Boris Zbarsky
On 12/15/10 10:51 AM, Tab Atkins Jr. wrote: Yes, output ports can be moved. I don't have any particular use-case for it, but under the current conceptual model for how output ports work, it's simpler to allow it than to disallow it, because output ports are just elements. It significantly

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Dimitri Glazkov
On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 10:51 AM, Tab Atkins Jr. wrote: Yes, output ports can be moved.  I don't have any particular use-case for it, but under the current conceptual model for how output ports work, it's simpler to allow it than to

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Tab Atkins Jr.
On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/15/10 10:51 AM, Tab Atkins Jr. wrote: Yes, output ports can be moved.  I don't have any particular use-case for it, but under the current conceptual model for how output ports work, it's simpler to allow it than to

Re: Fwd: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Boris Zbarsky
On 12/15/10 11:40 AM, Tab Atkins Jr. wrote: If all you're doing is moving the output port, why wouldn't all the associated normal-DOM elements end up in the same place? Because the new parent of the output port can have a binding attached itself, which puts them in different output ports

RE: [Bug 11553] New: Ensure indexedDBSync is on the right worker interface

2010-12-15 Thread Pablo Castro
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Wednesday, December 15, 2010 3:21 AM I believe the instance of WorkerUtils is much like window in a page.  I.e. you put stuff on there that you want in the global scope.  Thus I'm

Re: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Ian Hickson
On Tue, 14 Dec 2010, Boris Zbarsky wrote: So that in this case there would be a span element in the shadow DOM and a different span element in the flattened tree? As XBL2 is specced currently, the nodes in the explicit DOM and in the shadow DOM are the same nodes as in the final flattened

Re: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Tab Atkins Jr.
On Wed, Dec 15, 2010 at 1:18 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Dec 2010, Boris Zbarsky wrote: So that in this case there would be a span element in the shadow DOM and a different span element in the flattened tree? As XBL2 is specced currently, the nodes in the explicit DOM and

[IndexedDB] Do we need a timeout for VERSION_CHANGE?

2010-12-15 Thread Pablo Castro
Regular transactions take a timeout parameter when started, which ensures that we eventually make progress one way or the other if there's an un-cooperating script that won't let go of an object store or something like that. I'm not sure if we discussed this before, it seems that we need to add

Re: XBL2: First Thoughts and Use Cases

2010-12-15 Thread Maciej Stachowiak
On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote: At least in Gecko's case, we still use XBL1 in this way, and those design goals would apply to XBL2 from our point of view. It sounds like you have entirely different design goals, right? Sounds like it. OK, so given contradictory