Re: W3C XML Digital Signature Object Element Processing Issue
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 the DSS-X group of OASIS (http://www.oasis-open.org/apps/org/workgroup/dss-x/index.php). We focus on server side processing of signing, timestamping and verification. I would see the mobile browser signature verification as a very useful application of server side verification. If the browser just makes a simple hash of the widget and sends this to the server together with a link to the widget the server could verify the widget on behalf of the mobile client. This approach would have a impressive list of opportunities : - complex processing on the server side only. - exotic algorithms (like ECC) not required on the mobile device. - multiple calls to OCSP responder don't need to be made by the mobile client / no (lengthy) CRLs updates required by the (resource limited) client. - list of trusted root certificates managed centrally. - intensive use of caching : A central server can cache results of widget verifications for a while and can return the result immediately (as long as the OCSPs are valid) ! - A quick verification result improves the user experience ! If you're interested in this approach we may setup a sample environment. Greetings Andreas - original Nachricht Betreff: W3C XML Digital Signature Object Element Processing Issue Gesendet: Mi, 15. Dez 2010 Von: deepak Hello There, I am writing to you on the behalf of my company Infraware Inc. We are in the business of making Web Runtime and Browsers for Smartphones and other mobile devices. We are based in Seoul, Korea (South). I got your email address from your webpage. Currently me and my team are involved in the development of a Web Runtime and we are facing difficulties in validating the XML Digital signatures. We thought and hope you could help us in this regard. We are able to successfully verify the Reference element in case it is referencing to a URL of an external resource but we are unable to do so if it is pointing to an Object identifier within the same document (Same Document URI References). For Example ;- Reference URI=#prop Transforms Transform Algorithm=http://www.w3.org/2006/12/xml-c14n11/ /Transforms DigestMethod Algorithm=http://www.w3.org/2001/04/xmlenc#sha256/ DigestValueuMzc/pTgtDSq0iydCNGiIX/4Q68bAJrGl/1eohZoyUI=/DigestValue /Reference Object Id=prop SignatureProperties xmlns:dsp=http://www.w3.org/2009/xmldsig-properties; SignatureProperty Id=profile Target=#DistributorSignature dsp:Profile URI=http://www.w3.org/ns/widgets-digsig#profile/ /SignatureProperty SignatureProperty Id=role Target=#DistributorSignature dsp:Role URI=http://www.w3.org/ns/widgets-digsig#role-distributor/ /SignatureProperty SignatureProperty Id=identifier Target=#DistributorSignature dsp:Identifierw3c-testsuite-id-ta-5-5a/dsp:Identifier /SignatureProperty /SignatureProperties /Object We performed the transformation based on the Canonicalization algorithm mentioned in the transform element, but digest value that we obtain after applying the digest algorithm does not match to the given digest value. We suspect that we are not able to figure out the content to be digested correctly. Should the content to be canonicalized start from Object Id = prop and end at /Object or should it start from SignatureProperties and end /SignatureProperties. We would really appreciate if you could help us with this problem by giving some explanation about the process. Thank you for taking time to read this mail. Best Regards, Deepak Tyagi Mobile Business Div./ RD Team 2 3,4,8F Bando B/D 48-1 Banpo-dong Seocho-gu,Korea T 82 2 6190 7936 F 82 2 535 0478 M 82 10 2642 9623 E dee...@infraware.co.kr H www.infraware.co.kr --- original Nachricht Ende
Re: [Bug 11553] New: Ensure indexedDBSync is on the right worker interface
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: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11553 Summary: Ensure indexedDBSync is on the right worker interface Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org I just noticed that the async part of the spec has indexedDB in Worker (i.e. Worker implements IDBEnvironment), whereas the sync API has it WorkerUtils. The second one is probably just old, so for my current editing pass (bringing sync/async in sync) I'll just change it to Worker for consistency. However, from looking at the Web Workers spec [1] it seems that IDBEnvironmentSync should be implemented by AbstractWorker so it's available in regular and shared workers. Is that right? If not, what's the right spot? [1] http://dev.w3.org/html5/workers -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [Bug 11375] New: [IndexedDB] Error codes need to be assigned new numbers
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 as we make things more robust.) Is this things like disk IO errors and the like? Yeah and other impossible conditions. We also use UNKNOWN_ERR for when things are not yet implemented. Any concerns? Ideal is if you can leave out the function entirely if you don't implement it yet. An example is autoIncrement. There isn't really any way to leave it out because we otherwise support creating object stores and silently ignoring it means that we don't behave the way a user would expect. If there were mature IndexedDB implementations, we would have blocked releasing anything until we were feature complete, but until then I think it's better for everyone that we release early and often so we can get feedback. When this isn't possible, I would say that you should throw something different from what could be legitimately thrown from the function. I know gecko has a special exception we throw from various places when functionality isn't implemented. I don't think we should put anything in the spec about this as the spec should specify that everything should be implemented :) I agree. Wasn't asking because I wanted to add anything to the spec. What error code should we use for IDBCursor.update/delete when the cursor is not currently on an item It's currently specced to throw NOT_ALLOWED_ERR. I think this is consistent with other uses of that exception. I see now. In the text at the top it does actually say this clearly, but in the table below it only talks about hitting the end of results. (or that item has been deleted)? I brought up this a while back in bug 11257. Note that you can't throw since you can't synchronously know if an item has been deleted. IMHO the simplest thing is to just treat IDBCursor.update the same as IDBObjectStore.put and IDBCursor.delete as IDBObjectStore.delete. I can't think of a use case for deleting and then wanting to ensure that IDBCursor.update doesn't create a new entry, so we might as well keep things simple and reuse the implementation and spec logic. In short, I think the spec is fine in this area. TRANSIENT_ERR doesn't seem to be used anywhere in the spec. Should it be removed? Yes, along with RECOVERABLE_ERR, NON_TRANSIENT_ERR and DEADLOCK_ERR. We should also remove the .message property. DOMException doesn't have that. As for the numbering: does anyone object to me just starting from 1 and going sequentially? I.e. does anyone have a problem with them all getting new numbers, or should I keep the numbers the same when possible. (i.e. only UNKNOWN_ERR, RECOVERABLE_ERR, TRANSIENT_ERR, TIMEOUT_ERR, DEADLOCK_ERR would change number, but the ordering of those on the page would change.) I intend to tackle this early next week unless there are major areas of contention. Sounds great. The only possible thing that we might want to do differently is that we might want to get rid of IDBDatabaseException entirely and just add values to DOMException. I don't have an opinion on this but I'm currently checking with JS developers what is easiest for them. (In general I'm not a fan of how exceptions in the DOM are so different from JS-exceptions). Other APIs have their own exception classes. What's the benefit of putting our exceptions in DOMException? The downside is that other specs need to coordinate with our exception codes. Unless there's a pretty compelling reason to do this, I don't think we should. J
[widgets] Storage keys and ECMAScript incompatibility?
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 JavaScript states that: Variable names must begin with a letter or the underscore character ECMAScript[3] follows the Unicode identifier syntax[4], which defines variable names as starting with: Characters having the Unicode General_Category of uppercase letters (Lu), lowercase letters (Ll), titlecase letters (Lt), modifier letters (Lm), other letters (Lo), letter numbers (Nl), minus Pattern_Syntax and Pattern_White_Space code points, plus stability extensions So we get into problems using keys that begin with digits, which are allowed as far as I can tell in WebStorage and Widgets, but not in ECMAScript, and things like widgets.preferences.12345=xyz throw exceptions. [1] http://www.w3.org/TR/webstorage/ [2] http://www.w3schools.com/js/js_variables.asp [3] http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf [4] http://unicode.org/reports/tr31/ smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] Storage keys and ECMAScript incompatibility?
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?
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 data type supported by the structured clone algorithm. However, common guidance on JavaScript states that: Variable names must begin with a letter or the underscore character ECMAScript[3] follows the Unicode identifier syntax[4], which defines variable names as starting with: Characters having the Unicode General_Category of uppercase letters (Lu), lowercase letters (Ll), titlecase letters (Lt), modifier letters (Lm), other letters (Lo), letter numbers (Nl), minus Pattern_Syntax and Pattern_White_Space code points, plus stability extensions So we get into problems using keys that begin with digits, which are allowed as far as I can tell in WebStorage and Widgets, but not in ECMAScript, and things like widgets.preferences.12345=xyz throw exceptions. timeless got it. Only a subset of possible keys can be used in the dot syntax. Everything else can be used in the array notation instead. This is perfectly fine. ~TJ
Fwd: XBL2: First Thoughts and Use Cases
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 the final flattened tree. So just to make sure we're on the same page... are you thinking in terms of there being separate DOM nodes in the template, in the shadow DOM and in the final flattened tree? 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. (Events and such don't work on the final flattened tree, they work on the DOM augmented with shadow DOMs, in such a way that the existence of shadow DOMs isn't revealed to elements that don't need to know about them.) content div span/span children/ span/span /div content And then you remove the first span. So that in this case there would be a span element in the shadow DOM and a different span element in the flattened tree? Subject to what I said above, maybe? Ah, ok. Given what I said above (shadow node representing the port, which is replaced in the final flattened tree), then this is trivial. Removing the first span would just change the shadow to be: div outputport span/span /div OK; how would it change the flattened tree? Or am I misunderstanding your conceptual model? The final flattened tree wouldn't have the first original first span, since it's not in the DOM anymore. It would just look like: div ...any normal-DOM elements associated with the output port... span/span /div Hopefully this is the obvious answer. ...exactly as expected, since you're just mutating a DOM, and output ports are real DOM nodes. Should they be, though? Should .childNodes.length on the parent of an output port in the flattened tree count the output port? Sure - from the perspective of the shadow node, it has some shadow children, which may include output ports. The shadow doesn't directly know whether its output port has any normal-DOM elements associated with it, or how many, though this is something you should be able to easily query with script (possibly a property on the output port returning a NodeList of normal-DOM elements associated with it). The way Gecko's implementation works if one can call it that is that there is the template DOM and then the shadow DOM. The shadow DOM is created by cloning the template DOM, more or less. Output ports are kept track of on the template DOM. When you insert a node as a child under the bind element, you find the right port in the template DOM, then try to find the corresponding location in the (possibly mutated) shadow DOM. This clearly doesn't work very well! Ah, so it *is* an issue with combining mutable shadows with live templates! No. The template is not live in the sense that it never mutates. It's a completely static DOM. Oh, gotcha. Well, still, the problem arises from the (cloned) template DOM and the shadow DOM being separate things that can drift out of sync. That's not what happens in our idea - the shadow is cloned from the template, and then it's the only source of truth. ~TJ
Re: [widgets] Storage keys and ECMAScript incompatibility?
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 the empty string) is a valid key. Values can be any data type supported by the structured clone algorithm. However, common guidance on JavaScript states that: Variable names must begin with a letter or the underscore character ECMAScript[3] follows the Unicode identifier syntax[4], which defines variable names as starting with: Characters having the Unicode General_Category of uppercase letters (Lu), lowercase letters (Ll), titlecase letters (Lt), modifier letters (Lm), other letters (Lo), letter numbers (Nl), minus Pattern_Syntax and Pattern_White_Space code points, plus stability extensions So we get into problems using keys that begin with digits, which are allowed as far as I can tell in WebStorage and Widgets, but not in ECMAScript, and things like widgets.preferences.12345=xyz throw exceptions. timeless got it. Only a subset of possible keys can be used in the dot syntax. Everything else can be used in the array notation instead. This is perfectly fine. ~TJ OK, we'll implement using array notation instead. Thanks! smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: XBL2: First Thoughts and Use Cases
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 final flattened tree Sort of. Hit testing clearly needs to work on the layout structure generated from the final flattened tree, so event target determination works on the flattened tree, while event propagation works on the shadow DOMs. What worries me is that if we bake this conceptual assumption about the shadow DOM nodes being distinct from the flattened tree elements that gives us the freedom to write a spec that in fact requires both to be represented by distinct objects, increasing the memory and complexity needed to implement. More on this below. Ah, ok. Given what I said above (shadow node representing the port, which is replaced in the final flattened tree), then this is trivial. Removing the first span would just change the shadow to be: div outputport span/span /div OK; how would it change the flattened tree? Or am I misunderstanding your conceptual model? The final flattened tree wouldn't have the first original first span, since it's not in the DOM anymore. It would just look like: div ...any normal-DOM elements associated with the output port... span/span /div Hopefully this is the obvious answer. Well... it's the desired answer. It wasn't obvious from your formulation, no. Should they be, though? Should .childNodes.length on the parent of an output port in the flattened tree count the output port? Sure - from the perspective of the shadow node, it has some shadow children, which may include output ports. So should the output port nodes then be exposed to methods manipulating the shadow DOM? Should it be ok to move output ports around in the shadow tree? If so, why? My preference, fwiw, would be that output ports are not present as DOM nodes in the shadow DOM. That significantly reduces the complexity of specifying the behavior, I think No. The template is not live in the sense that it never mutates. It's a completely static DOM. Oh, gotcha. Well, still, the problem arises from the (cloned) template DOM and the shadow DOM being separate things that can drift out of sync. That's not what happens in our idea - the shadow is cloned from the template, and then it's the only source of truth. So here's the thing. XBL1 was originally designed as a reusable component model with the idea that the components would actually be reused, with possibly many (tens of thousands) of instantiations of a given template. Which means that memory usage for each instantiation is a concern, which is why as much as possible is delegated to the shared state in the template. 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? -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
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 target determination works on the flattened tree, while event propagation works on the shadow DOMs. What worries me is that if we bake this conceptual assumption about the shadow DOM nodes being distinct from the flattened tree elements that gives us the freedom to write a spec that in fact requires both to be represented by distinct objects, increasing the memory and complexity needed to implement. More on this below. True. We need to dive into event handling a bit more and make sure we're being consistent. I suspect we are, but I need to make sure so I can talk a consistent story. Should they be, though? Should .childNodes.length on the parent of an output port in the flattened tree count the output port? Sure - from the perspective of the shadow node, it has some shadow children, which may include output ports. So should the output port nodes then be exposed to methods manipulating the shadow DOM? Should it be ok to move output ports around in the shadow tree? If so, why? My preference, fwiw, would be that output ports are not present as DOM nodes in the shadow DOM. That significantly reduces the complexity of specifying the behavior, I think 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. I think that having output ports be elements is a good and simple answer, because we want output ports to be insertion points, not containers. Other answers are either incompatible (for example, having a map of selectors to shadow nodes, which makes the pointed-to shadow node a container) or more complicated (trying to match the current shadow DOM to the template DOM to find out where the insertion point should be). No. The template is not live in the sense that it never mutates. It's a completely static DOM. Oh, gotcha. Well, still, the problem arises from the (cloned) template DOM and the shadow DOM being separate things that can drift out of sync. That's not what happens in our idea - the shadow is cloned from the template, and then it's the only source of truth. So here's the thing. XBL1 was originally designed as a reusable component model with the idea that the components would actually be reused, with possibly many (tens of thousands) of instantiations of a given template. Which means that memory usage for each instantiation is a concern, which is why as much as possible is delegated to the shared state in the template. 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. We're approaching the problem from the angle of Every major javascript framework creates its own non-interoperable component framework. How can we make a lingua franca that would allow them all to talk the same language?. We want a jQuery component and a MooTools component to work nicely together, rather than each having their own entirely separate notion of what a component is, how to manage its lifecycle, etc. Under this model, existing components already expose all their DOM separately every time, as real live DOM nodes in the document, so instantiating fresh shadow for each instance of a component is no worse. Encapsulating it in shadow trees restores some sanity to the DOM, and allows some optimizations (like not attempting to match normal selectors against component-internal nodes, or component-internal selectors against the rest of the page). (Elaborating for the viewers at home, what I mean by sanity is the nice hiding of inconsequential DOM that exists only for display and interaction purposes. For example, if you made input type=range in normal HTML, you'd use a nice chunk of DOM structure for it. The details of exactly what the DOM is, though, are unimportant. All you need to know is that there's a slider input, and some relevant knobs are exposed as attributes. You don't want a rule from elsewhere in the page accidentally styling the grabber for the slider just because it happens to match div div or something, *particularly* if different browsers use different DOM structures for the slider input.) ~TJ
Re: [widgets] Storage keys and ECMAScript incompatibility?
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
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 on the layout structure generated from the final flattened tree, so event target determination works on the flattened tree, while event propagation works on the shadow DOMs. What worries me is that if we bake this conceptual assumption about the shadow DOM nodes being distinct from the flattened tree elements that gives us the freedom to write a spec that in fact requires both to be represented by distinct objects, increasing the memory and complexity needed to implement. More on this below. True. We need to dive into event handling a bit more and make sure we're being consistent. I suspect we are, but I need to make sure so I can talk a consistent story. Should they be, though? Should .childNodes.length on the parent of an output port in the flattened tree count the output port? Sure - from the perspective of the shadow node, it has some shadow children, which may include output ports. So should the output port nodes then be exposed to methods manipulating the shadow DOM? Should it be ok to move output ports around in the shadow tree? If so, why? My preference, fwiw, would be that output ports are not present as DOM nodes in the shadow DOM. That significantly reduces the complexity of specifying the behavior, I think 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. I think that having output ports be elements is a good and simple answer, because we want output ports to be insertion points, not containers. Other answers are either incompatible (for example, having a map of selectors to shadow nodes, which makes the pointed-to shadow node a container) or more complicated (trying to match the current shadow DOM to the template DOM to find out where the insertion point should be). I think Boris has the right preference. It's the solution that is not obvious :) Conceptually, what we're talking here is some sort of insertion points that: a) can be added between any two children; b) aren't perceptible from DOM as elements or any other artifacts c) have a clear set of rules governing how what happens to them during sibling/parent mutation. Right? No. The template is not live in the sense that it never mutates. It's a completely static DOM. Oh, gotcha. Well, still, the problem arises from the (cloned) template DOM and the shadow DOM being separate things that can drift out of sync. That's not what happens in our idea - the shadow is cloned from the template, and then it's the only source of truth. So here's the thing. XBL1 was originally designed as a reusable component model with the idea that the components would actually be reused, with possibly many (tens of thousands) of instantiations of a given template. Which means that memory usage for each instantiation is a concern, which is why as much as possible is delegated to the shared state in the template. 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. We're approaching the problem from the angle of Every major javascript framework creates its own non-interoperable component framework. How can we make a lingua franca that would allow them all to talk the same language?. We want a jQuery component and a MooTools component to work nicely together, rather than each having their own entirely separate notion of what a component is, how to manage its lifecycle, etc. Under this model, existing components already expose all their DOM separately every time, as real live DOM nodes in the document, so instantiating fresh shadow for each instance of a component is no worse. Encapsulating it in shadow trees restores some sanity to the DOM, and allows some optimizations (like not attempting to match normal selectors against component-internal nodes, or component-internal selectors against the rest of the page). (Elaborating for the viewers at home, what I mean by sanity is the nice hiding of inconsequential DOM that exists only for display and interaction purposes. For example, if you made input type=range in normal HTML, you'd use a nice chunk of DOM structure for it. The details of exactly what the DOM is, though, are unimportant. All you need to know is that there's a slider input, and some relevant knobs are exposed as attributes. You don't want a rule from elsewhere in the page accidentally styling the grabber for the slider just
Re: Fwd: XBL2: First Thoughts and Use Cases
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 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 target determination works on the flattened tree, while event propagation works on the shadow DOMs. What worries me is that if we bake this conceptual assumption about the shadow DOM nodes being distinct from the flattened tree elements that gives us the freedom to write a spec that in fact requires both to be represented by distinct objects, increasing the memory and complexity needed to implement. More on this below. True. We need to dive into event handling a bit more and make sure we're being consistent. I suspect we are, but I need to make sure so I can talk a consistent story. Should they be, though? Should .childNodes.length on the parent of an output port in the flattened tree count the output port? Sure - from the perspective of the shadow node, it has some shadow children, which may include output ports. So should the output port nodes then be exposed to methods manipulating the shadow DOM? Should it be ok to move output ports around in the shadow tree? If so, why? My preference, fwiw, would be that output ports are not present as DOM nodes in the shadow DOM. That significantly reduces the complexity of specifying the behavior, I think 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. I think that having output ports be elements is a good and simple answer, because we want output ports to be insertion points, not containers. Other answers are either incompatible (for example, having a map of selectors to shadow nodes, which makes the pointed-to shadow node a container) or more complicated (trying to match the current shadow DOM to the template DOM to find out where the insertion point should be). I think Boris has the right preference. It's the solution that is not obvious :) Conceptually, what we're talking here is some sort of insertion points that: a) can be added between any two children; b) aren't perceptible from DOM as elements or any other artifacts c) have a clear set of rules governing how what happens to them during sibling/parent mutation. Right? FWIW, this smells very CSS-ey. No. The template is not live in the sense that it never mutates. It's a completely static DOM. Oh, gotcha. Well, still, the problem arises from the (cloned) template DOM and the shadow DOM being separate things that can drift out of sync. That's not what happens in our idea - the shadow is cloned from the template, and then it's the only source of truth. So here's the thing. XBL1 was originally designed as a reusable component model with the idea that the components would actually be reused, with possibly many (tens of thousands) of instantiations of a given template. Which means that memory usage for each instantiation is a concern, which is why as much as possible is delegated to the shared state in the template. 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. We're approaching the problem from the angle of Every major javascript framework creates its own non-interoperable component framework. How can we make a lingua franca that would allow them all to talk the same language?. We want a jQuery component and a MooTools component to work nicely together, rather than each having their own entirely separate notion of what a component is, how to manage its lifecycle, etc. Under this model, existing components already expose all their DOM separately every time, as real live DOM nodes in the document, so instantiating fresh shadow for each instance of a component is no worse. Encapsulating it in shadow trees restores some sanity to the DOM, and allows some optimizations (like not attempting to match normal selectors against component-internal nodes, or component-internal selectors against the rest of the page). (Elaborating for the viewers at home, what I mean by sanity is the nice hiding of inconsequential DOM that exists only for display and interaction purposes. For example, if you made input type=range in normal HTML, you'd use a nice chunk of DOM structure for it. The details of exactly what the DOM is, though, are unimportant. All you need to know is that there's a slider input, and some relevant knobs are exposed as
Re: Fwd: XBL2: First Thoughts and Use Cases
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 complicates implementation; when an output port is moved you have to find all the elements in the flattened tree that came through the output port and move them to different places (note that they don't all end up in the same place, in general). I think that having output ports be elements is a good and simple answer, because we want output ports to be insertion points, not containers. Sure. But them being insertion points can happen without being elements. For example, an insertion point can be tracked conceptually as a collapsed range (e.g. similar to the way a caret works in text controls; that too is an insertion point). 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 design goals, where do we go from here? Under this model, existing components already expose all their DOM separately every time, as real live DOM nodes in the document, so instantiating fresh shadow for each instance of a component is no worse. Sure. And Gecko instantiates a fresh shadow tree copy for each instance. However you're suggesting also instantiating a fresh copy of various metadata, whose size can easily dwarf the size of the shadow tree itself. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
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 disallow it, because output ports are just elements. It significantly complicates implementation; when an output port is moved you have to find all the elements in the flattened tree that came through the output port and move them to different places (note that they don't all end up in the same place, in general). I think that having output ports be elements is a good and simple answer, because we want output ports to be insertion points, not containers. Sure. But them being insertion points can happen without being elements. For example, an insertion point can be tracked conceptually as a collapsed range (e.g. similar to the way a caret works in text controls; that too is an insertion point). 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 design goals, where do we go from here? I don't understand how the goals are contradictory -- and to be honest, I can't see how anyone could understand this without a set of use cases. Can we instead focus on use cases and then decide? :) Under this model, existing components already expose all their DOM separately every time, as real live DOM nodes in the document, so instantiating fresh shadow for each instance of a component is no worse. Sure. And Gecko instantiates a fresh shadow tree copy for each instance. However you're suggesting also instantiating a fresh copy of various metadata, whose size can easily dwarf the size of the shadow tree itself. That seems like an implementation detail. Metadata can be shared and cloned as needed, just like styles in CSS. -Boris
Re: Fwd: XBL2: First Thoughts and Use Cases
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 disallow it, because output ports are just elements. It significantly complicates implementation; when an output port is moved you have to find all the elements in the flattened tree that came through the output port and move them to different places (note that they don't all end up in the same place, in general). 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? Mutating the output port would obviously cause changes, and the final box-tree for CSS can indeed be changed in non-trivial ways, but I'm not immediately seeing any reason why the final flattened tree would be changed in any extraordinary way. I think that having output ports be elements is a good and simple answer, because we want output ports to be insertion points, not containers. Sure. But them being insertion points can happen without being elements. For example, an insertion point can be tracked conceptually as a collapsed range (e.g. similar to the way a caret works in text controls; that too is an insertion point). True, but having them be anything other than elements complicates the handling of shadow DOM mutations. I don't think there's a non-arbitrary answer to what happens if the shadow tree contains *only* an output port (as a collapsed range) and then you append a child to the shadow tree. Does the range go before or after the node? Is there any way to make this obvious to an author? I'm not wedded to the output ports are elements in the shadow DOM idea, but I think it's a pretty strong idea. 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 design goals, where do we go from here? Hmm, good question. To start, I don't think I fully understand the value of the situation you outline as a design goal. What sort of situation do you envision where you want to optimize producing tens of thousands of components on a single page? In the long term, if our use-cases truly are contradictory or incompatible, then we can decide if it's worthwhile to approach each case independently with different solutions. We need to look at use-cases first, though, so we can decide exactly what problems we're trying to solve. Under this model, existing components already expose all their DOM separately every time, as real live DOM nodes in the document, so instantiating fresh shadow for each instance of a component is no worse. Sure. And Gecko instantiates a fresh shadow tree copy for each instance. However you're suggesting also instantiating a fresh copy of various metadata, whose size can easily dwarf the size of the shadow tree itself. I don't think I agree with that characterization. The necessary metadata isn't very large: 1. A list of output ports. 2. For each output port, a list of which normal-DOM descendants of the component are associated with that port. 3. A list of attribute forwards (a map from name to node/name). 4. A list of pseudos (a map from idents to shadow nodes). 5. Other stuff? This is a few NodeLists and a few maps, comparable in size to a small DOM tree I'd think. Am I missing something? ~TJ
Re: Fwd: XBL2: First Thoughts and Use Cases
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 under that shadow tree. True, but having them be anything other than elements complicates the handling of shadow DOM mutations. I'm still looking for use cases for shadow DOM mutations that involve adding or removing nodes. Why are these useful? If they're not sufficiently useful, then given the specification and implementation complexity of supporting them I would propose that they be disallowed. I don't think there's a non-arbitrary answer to what happens if the shadow tree contains *only* an output port (as a collapsed range) and then you append a child to the shadow tree. Does the range go before or after the node? The range spec defines this, fwiw... ;) But yes, there is less author control in this case; you can't choose whether the node goes before or after the port. OK, so given contradictory design goals, where do we go from here? Hmm, good question. To start, I don't think I fully understand the value of the situation you outline as a design goal. What sort of situation do you envision where you want to optimize producing tens of thousands of components on a single page? A component attached to every table cell in a large data table, say. Or every email in your inbox. Or every text input or checkbox or dropdown select (see Slashdot comment page while moderating). These are all situations where I've seen people trying to use XBL1, fwiw. In the long term, if our use-cases truly are contradictory or incompatible, then we can decide if it's worthwhile to approach each case independently with different solutions. We need to look at use-cases first, though, so we can decide exactly what problems we're trying to solve. Agreed. I don't think I agree with that characterization. The necessary metadata isn't very large: 1. A list of output ports. 2. For each output port, a list of which normal-DOM descendants of the component are associated with that port. 3. A list of attribute forwards (a map from name to node/name). 4. A list of pseudos (a map from idents to shadow nodes). 5. Other stuff? For each output port the relevant CSS selectors. This is a few NodeLists and a few maps, comparable in size to a small DOM tree I'd think. A DOM tree in Gecko takes order of 40 bytes per node. Just storing a single nontrivial CSS selector is comparable in size to a bunch of DOM nodes, last I checked. -Boris
RE: [Bug 11553] New: Ensure indexedDBSync is on the right worker interface
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 pretty sure that WorkerUtils is the right place for both. Yeah, I read the workers spec too quickly yesterday. You're right, WorkerUtils is what we need, I'll make it implement both IDBEnvironment and IDBEnvironmentSync. Thanks, -pablo
Re: XBL2: First Thoughts and Use Cases
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 tree, except that certain elements in the shadow tree don't appear in the final flattened tree (the root template and the insertion point content elements, in particular; also the element used for inheritance insertion). The example in this section, while initially rather perplexing, is probably the quickest way of visualising this: http://dev.w3.org/cvsweb/~checkout~/2006/xbl2/Overview.html?content-type=text/html;%20charset=utf-8#the-final-flattened-tree The key is just that each element in the final flattened tree is _also_ in a DOM somewhere. It's the same elements, they just have two sets of tree pointers (parent, children, siblings, etc). Selectors and events work in XBL2 as specified work on a carefully chosen hybrid of these trees. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XBL2: First Thoughts and Use Cases
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 in the shadow DOM are the same nodes as in the final flattened tree, except that certain elements in the shadow tree don't appear in the final flattened tree (the root template and the insertion point content elements, in particular; also the element used for inheritance insertion). The example in this section, while initially rather perplexing, is probably the quickest way of visualising this: http://dev.w3.org/cvsweb/~checkout~/2006/xbl2/Overview.html?content-type=text/html;%20charset=utf-8#the-final-flattened-tree The key is just that each element in the final flattened tree is _also_ in a DOM somewhere. It's the same elements, they just have two sets of tree pointers (parent, children, siblings, etc). Selectors and events work in XBL2 as specified work on a carefully chosen hybrid of these trees. As far as I know (and I've been in the center of the discussions over here, so hopefully I know pretty far), we agree with this design in XBL2. We have some nits to pick with precisely how shadows are constructed and flattened, but otherwise, yeah, basically the same deal. ~TJ
[IndexedDB] Do we need a timeout for VERSION_CHANGE?
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 a similar thing for setVersion(), and it's basically a way of starting a transaction. I was thinking we could have an optional timeout argument in setVersion with a UA-specific default. In the async case we would fire the onerror event and in the sync case just throw, both with TIMEOUT_ERR. Thanks -pablo
Re: XBL2: First Thoughts and Use Cases
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 design goals, where do we go from here? Are they really contradictory? It sounds like Tab doesn't care about the use case where you want hundreds or thousands of instances without undue memory use, since he's looking to replace technologies that already don't support this. But it doesn't seem like these use cases are fundamentally incompatible. Personally, I think it would be a huge win if XBL2-based components could be more scalable than ones written in pure JavaScript using vanilla DOM calls. That way, XBL2 could enable new kinds of applications and reduce memory use of existing applications, rather than just providing convenience and bridging, as Tab seems to envision. Regards, Maciej
