No longer representing Opera
Hi, I wanted to inform the working group that I no longer represent Opera Software at the W3C - nor am I any longer employed by Opera (or by anyone at this moment). For the next six months I will be representing myself (unless otherwise indicated). The W3C has granted me Invited Expert status, for which I will try to continue editing the Widget specs (depending on whatever funding I can get to do that). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[widgets] Dig Sig spec
I've been reviewing and trying to implement the widgets dig sig spec and I'm finding that there is a lot of redundancies and inconsistencies with the way it is written. Although the conformance requirements are fairly clear, the main problem is that the spec is a bit confused when it comes to algorithms and processing. It also states things that really should just be deferred to XML Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with the goal of making it simpler to implement. -- Marcos Caceres http://datadriven.com.au
[IndexedDB] Discrepancies with the Event type of error in section 4.12
Step 3 in Section 4.12, Fire an error event, on the latest editor draft stipulates that: 3. Dispatch an event at request. The event must use the Event interface and have its type set to error. The event does bubble and is cancelable. ... Looking over the DOM L3 event spec, the type error Event doesn't buble and is not cancelable [1]. Pablo and I are not sure about the benefits of having the error event be cancelable. In our experience, canceling and event implies that the reason for this error can be modified or altered. Leaving this statement would imply that if a developer were to receive a NOT_ALLOWED_ERR she could cancel the error and things would work. The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. Adding bubbling to an event of type error would require us to introduce a new event type, IDBError. The reason is that we probably don't want to overload the existing DOM L3 type definition for error. There is a precedence for this in the SVG spec, the SVGError type. A couple of questions: * Do we agree that errors shouldn't be cancelable? * How do we feel about bubbling? If we want to keep it, what are the main scenarios and what would the event hierarchy look like? * Assuming bubbling, how do you feel about adding a new event type called IDBError to capture the non-cancelable and bubbling behavior of this event? Thanks, Israel [1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-error
Model-driven Views
Myself and a few other chromium folks have been working on a design for a formalized separation between View and Model in the browser, with needs of web applications being the primary motivator. Our ideas are implemented as an experimental Javascript library: https://code.google.com/p/mdv/ and the basic design is described here: http://mdv.googlecode.com/svn/trunk/docs/design_intro.html. It's not complete and there are things we're not happy with, but it's self-consistent enough that you can start to imagine what a full design might look like. We hope to get others interested in collecting requirements/use cases and fleshing out a good solution. We're starting the discussion here because a few people in this group from whom we got early feedback felt that it would be most appropriate place and, further, that this work bears some relation to XBL. What do you think?
Improving DOM Traversal and DOM XPath
Hi All, Since we're taking a look at DOM-Core and fixing some of the old-cruft in it, I have some suggestions for making some of the functions on document easier to use. These functions aren't technically defined as part of DOM-Core, but they are functions on the Document object which is defined by DOM-Core. First off is document.createTreeWalker and document.createNodeIterator. They have the same signature which currently is: document.createX(root, whatToShow, filter, entityReferenceExpansion); Given that entity references are being removed, we should simply remove the last argument. Note that this is a backwards compatible change since additional arguments to any DOM function are just ignored in all browsers I think. Additionally, I see no reason to keep the 'filter' argument required as it's quite common to leave out. We could even make the whatToShow argument optinal and default it to SHOW_ALL. Originally I was going to propose that we default it to SHOW_ELEMENTS as I had thought that that would be a common value, however it appears that SHOW_TEXT is as, if not more, commonly used. The downside to defaulting to SHOW_ALL is that people might use the default and then do filtering manually, which is slower than having the iterator/treewalker do the filtering. I'd like to give some DOM XPath a similar treatment. The following three functions could be simplified: XPathEvaluator.createExpression(expression, resolver); Here I think we can make the 'resolver' argument optional as namespaces are commonly not used on the web. XPathEvaluator.evaluate(expression, contextNode, resolver, type, result); We can make 'resolver', 'type' and 'result' optional. 'type' would default to ANY_TYPE(0) and the other two to null. XPathExpression.evaluate(contextNode, type, result); Here all but the first could be optional. The defaults would be the same as for XPathEvaluator.evaluate. I'd like to make these changes to firefox, but first I wanted to hear what people here think. I know we don't have editors for the relevant specs, but I think we can make an informal decision that these changes sound good if people think they are. / Jonas
Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio isra...@microsoft.com wrote: Step 3 in Section 4.12, Fire an error event, on the latest editor draft stipulates that: 3. Dispatch an event at request. The event must use the Event interface and have its type set to error. The event does bubble and is cancelable. ... Looking over the DOM L3 event spec, the type error Event doesn't buble and is not cancelable [1]. Pablo and I are not sure about the benefits of having the error event be cancelable. In our experience, canceling and event implies that the reason for this error can be modified or altered. Leaving this statement would imply that if a developer were to receive a NOT_ALLOWED_ERR she could cancel the error and things would work. Note that 'cancelable' has a specific defined meaning different from the one you describe above. Cancelling a event is done by calling preventDefault() and means that the events default action is not executed. In the case of IndexedDB the default action is to abort the transaction (as defined by step 3). So in other words, if we want to allow users to catch database errors and prevent them from aborting the transaction, which I assume we do, then we need to keep the event cancelable. The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. The intent is to allow attaching a event handler to just the transaction object and catch all errors happening in the scope of the transaction. For example is a page uses a transaction to insert 1000 entries into a database, it'd be nice to have a single point of attaching error handling code rather than having to do it on every individual Request object. Similarly, by allowing the event to bubble up to the database object, event handlers could be attached there that span multiple transactions. This is similar to how exceptions work. Exceptions walk up the call chain and allow you to attach error handling code higher up in the call stack which handles all errors in a given execution path. Rather than at each low-level action have to hook up error handling code. Adding bubbling to an event of type error would require us to introduce a new event type, IDBError. The reason is that we probably don't want to overload the existing DOM L3 type definition for error. There is a precedence for this in the SVG spec, the SVGError type. I don't see why making the event implement an additional interface would improve the situation. We'd still have to implement the Event interface just like DOM-Events, since all events have to implement Event. But I also don't think it's a problem that we fire an event that is similar to the one DOM-Events define, even though it uses the same name. The event isn't fired on the same objects and so no collisions should occur. I do agree it's somewhat unfortunate that some error events bubble, but others don't. But I think it'd be even worse to use a different event name, or to make the event not bubble. A couple of questions: * Do we agree that errors shouldn't be cancelable? I think we should leave it cancelable as to allow pages to do error handling and not abort the transaction. * How do we feel about bubbling? If we want to keep it, what are the main scenarios and what would the event hierarchy look like? The propagation part is defined in step 3. During the bubbling phase handlers at the IDBRequest are run first, then the ones at the IDBTransaction and then finally at the IDBDatabase. * Assuming bubbling, how do you feel about adding a new event type called IDBError to capture the non-cancelable and bubbling behavior of this event? I don't see what problem that solves? / Jonas
Re: Model-driven Views
Have you heard of knockout.js? It's an MVVM pattern based on JQuery, if you're not aware of it you may be interested to see their approach. Official site: http://knockoutjs.com/ Recent MIX event: http://channel9.msdn.com/Events/MIX/MIX11/FRM08 Just FYI as it was related... On 23 April 2011 01:35, Rafael Weinstein rafa...@google.com wrote: Myself and a few other chromium folks have been working on a design for a formalized separation between View and Model in the browser, with needs of web applications being the primary motivator. Our ideas are implemented as an experimental Javascript library: https://code.google.com/p/mdv/ and the basic design is described here: http://mdv.googlecode.com/svn/trunk/docs/design_intro.html. It's not complete and there are things we're not happy with, but it's self-consistent enough that you can start to imagine what a full design might look like. We hope to get others interested in collecting requirements/use cases and fleshing out a good solution. We're starting the discussion here because a few people in this group from whom we got early feedback felt that it would be most appropriate place and, further, that this work bears some relation to XBL. What do you think?
Re: Improving DOM Traversal and DOM XPath
On Mon, Apr 25, 2011 at 11:31 AM, Jonas Sicking jo...@sicking.cc wrote: First off is document.createTreeWalker and document.createNodeIterator. They have the same signature which currently is: document.createX(root, whatToShow, filter, entityReferenceExpansion); Given that entity references are being removed, we should simply remove the last argument. Note that this is a backwards compatible change since additional arguments to any DOM function are just ignored in all browsers I think. Additionally, I see no reason to keep the 'filter' argument required as it's quite common to leave out. FWIW, WebKit already has filter and entityReferenceExpansion as optional. I expect there would be no opposition to making whatToShow optional as well. We could even make the whatToShow argument optinal and default it to SHOW_ALL. Originally I was going to propose that we default it to SHOW_ELEMENTS as I had thought that that would be a common value, however it appears that SHOW_TEXT is as, if not more, commonly used. The downside to defaulting to SHOW_ALL is that people might use the default and then do filtering manually, which is slower than having the iterator/treewalker do the filtering. I agree with everything here. I think SHOW_ALL is the default people would expect. I'd like to give some DOM XPath a similar treatment. The following three functions could be simplified: XPathEvaluator.createExpression(expression, resolver); Here I think we can make the 'resolver' argument optional as namespaces are commonly not used on the web. XPathEvaluator.evaluate(expression, contextNode, resolver, type, result); We can make 'resolver', 'type' and 'result' optional. 'type' would default to ANY_TYPE(0) and the other two to null. XPathExpression.evaluate(contextNode, type, result); Here all but the first could be optional. The defaults would be the same as for XPathEvaluator.evaluate. These are already all optional in WebKit. We could also make contextNode optional by defaulting it to the document, no? I'd like to make these changes to firefox, but first I wanted to hear what people here think. I support this. As it is, I believe the verbosity of these methods hurts their adoption. I know we don't have editors for the relevant specs, but I think we can make an informal decision that these changes sound good if people think they are. / Jonas
Re: Improving DOM Traversal and DOM XPath
On Mon, Apr 25, 2011 at 2:22 PM, Ojan Vafai o...@chromium.org wrote: On Mon, Apr 25, 2011 at 11:31 AM, Jonas Sicking jo...@sicking.cc wrote: First off is document.createTreeWalker and document.createNodeIterator. They have the same signature which currently is: document.createX(root, whatToShow, filter, entityReferenceExpansion); Given that entity references are being removed, we should simply remove the last argument. Note that this is a backwards compatible change since additional arguments to any DOM function are just ignored in all browsers I think. Additionally, I see no reason to keep the 'filter' argument required as it's quite common to leave out. FWIW, WebKit already has filter and entityReferenceExpansion as optional. I expect there would be no opposition to making whatToShow optional as well. We could even make the whatToShow argument optinal and default it to SHOW_ALL. Originally I was going to propose that we default it to SHOW_ELEMENTS as I had thought that that would be a common value, however it appears that SHOW_TEXT is as, if not more, commonly used. The downside to defaulting to SHOW_ALL is that people might use the default and then do filtering manually, which is slower than having the iterator/treewalker do the filtering. I agree with everything here. I think SHOW_ALL is the default people would expect. Excellent! I'd like to give some DOM XPath a similar treatment. The following three functions could be simplified: XPathEvaluator.createExpression(expression, resolver); Here I think we can make the 'resolver' argument optional as namespaces are commonly not used on the web. XPathEvaluator.evaluate(expression, contextNode, resolver, type, result); We can make 'resolver', 'type' and 'result' optional. 'type' would default to ANY_TYPE(0) and the other two to null. XPathExpression.evaluate(contextNode, type, result); Here all but the first could be optional. The defaults would be the same as for XPathEvaluator.evaluate. These are already all optional in WebKit. We could also make contextNode optional by defaulting it to the document, no? Yup, that would be fine with me. I'd like to make these changes to firefox, but first I wanted to hear what people here think. I support this. As it is, I believe the verbosity of these methods hurts their adoption. That was my thinking exactly. / Jonas
Re: Improving DOM Traversal and DOM XPath
On 04/26/2011 12:22 AM, Ojan Vafai wrote: On Mon, Apr 25, 2011 at 11:31 AM, Jonas Sicking jo...@sicking.cc wrote: First off is document.createTreeWalker and document.createNodeIterator. They have the same signature which currently is: document.createX(root, whatToShow, filter, entityReferenceExpansion); Given that entity references are being removed, we should simply remove the last argument. Note that this is a backwards compatible change since additional arguments to any DOM function are just ignored in all browsers I think. Additionally, I see no reason to keep the 'filter' argument required as it's quite common to leave out. FWIW, WebKit already has filter and entityReferenceExpansion as optional. I expect there would be no opposition to making whatToShow optional as well. Just curious, are they optional by design in webkit, or because of the bug which for example lead the last parameter to addEventListener to be optional. -Olli We could even make the whatToShow argument optinal and default it to SHOW_ALL. Originally I was going to propose that we default it to SHOW_ELEMENTS as I had thought that that would be a common value, however it appears that SHOW_TEXT is as, if not more, commonly used. The downside to defaulting to SHOW_ALL is that people might use the default and then do filtering manually, which is slower than having the iterator/treewalker do the filtering. I agree with everything here. I think SHOW_ALL is the default people would expect. I'd like to give some DOM XPath a similar treatment. The following three functions could be simplified: XPathEvaluator.createExpression(expression, resolver); Here I think we can make the 'resolver' argument optional as namespaces are commonly not used on the web. XPathEvaluator.evaluate(expression, contextNode, resolver, type, result); We can make 'resolver', 'type' and 'result' optional. 'type' would default to ANY_TYPE(0) and the other two to null. XPathExpression.evaluate(contextNode, type, result); Here all but the first could be optional. The defaults would be the same as for XPathEvaluator.evaluate. These are already all optional in WebKit. We could also make contextNode optional by defaulting it to the document, no? I'd like to make these changes to firefox, but first I wanted to hear what people here think. I support this. As it is, I believe the verbosity of these methods hurts their adoption. I know we don't have editors for the relevant specs, but I think we can make an informal decision that these changes sound good if people think they are. / Jonas
Re: [FileAPI] File.slice spec bug
On 4/14/11 5:22 AM, Jonas Sicking wrote: On Thu, Apr 14, 2011 at 2:16 AM, James Grahamjgra...@opera.com wrote: On 04/14/2011 03:04 AM, Jonas Sicking wrote: It would be nice to hear from someone at Opera about their willingness to commit to this change as well. As a general point we think that making breaking changes to APIs with multiple compatible implementations that are already shipping is a really bad idea. So let's try and make this a one off. That said, we will go along with the plan, but we can't commit to a timeline for releasing the changed version. Thanks James! I agree this is something we should really avoid. The best way I think we can do that in the future is to prefix implementations until specs are agreed to be in a more stable state. I certainly have had my fair share in not doing so enough, so not trying to shift blame here. / Jonas I have released a spec. update with File.slice resembling String.prototype.slice (covered in ECMA-262 5th Edition [1]), which I think is the right model (since Blob and String are immutable). http://dev.w3.org/2006/webapi/FileAPI/#blob Comments welcome and encouraged! Other spec. updates will follow shortly. -- A* [1] http://www.ecma-international.org/publications/standards/Ecma-262.htm
RE: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Mon, Apr 25, 2011 at 11:52 AM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio isra...@microsoft.com wrote: Step 3 in Section 4.12, Fire an error event, on the latest editor draft stipulates that: 3. Dispatch an event at request. The event must use the Event interface and have its type set to error. The event does bubble and is cancelable. ... Looking over the DOM L3 event spec, the type error Event doesn't buble and is not cancelable [1]. Pablo and I are not sure about the benefits of having the error event be cancelable. In our experience, canceling and event implies that the reason for this error can be modified or altered. Leaving this statement would imply that if a developer were to receive a NOT_ALLOWED_ERR she could cancel the error and things would work. Note that 'cancelable' has a specific defined meaning different from the one you describe above. Cancelling a event is done by calling preventDefault() and means that the events default action is not executed. In the case of IndexedDB the default action is to abort the transaction (as defined by step 3). So in other words, if we want to allow users to catch database errors and prevent them from aborting the transaction, which I assume we do, then we need to keep the event cancelable. The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. The intent is to allow attaching a event handler to just the transaction object and catch all errors happening in the scope of the transaction. For example is a page uses a transaction to insert 1000 entries into a database, it'd be nice to have a single point of attaching error handling code rather than having to do it on every individual Request object. Similarly, by allowing the event to bubble up to the database object, event handlers could be attached there that span multiple transactions. This is similar to how exceptions work. Exceptions walk up the call chain and allow you to attach error handling code higher up in the call stack which handles all errors in a given execution path. Rather than at each low-level action have to hook up error handling code. Adding bubbling to an event of type error would require us to introduce a new event type, IDBError. The reason is that we probably don't want to overload the existing DOM L3 type definition for error. There is a precedence for this in the SVG spec, the SVGError type. I don't see why making the event implement an additional interface would improve the situation. We'd still have to implement the Event interface just like DOM-Events, since all events have to implement Event. But I also don't think it's a problem that we fire an event that is similar to the one DOM-Events define, even though it uses the same name. The event isn't fired on the same objects and so no collisions should occur. I do agree it's somewhat unfortunate that some error events bubble, but others don't. But I think it'd be even worse to use a different event name, or to make the event not bubble. A couple of questions: * Do we agree that errors shouldn't be cancelable? I think we should leave it cancelable as to allow pages to do error handling and not abort the transaction. * How do we feel about bubbling? If we want to keep it, what are the main scenarios and what would the event hierarchy look like? The propagation part is defined in step 3. During the bubbling phase handlers at the IDBRequest are run first, then the ones at the IDBTransaction and then finally at the IDBDatabase. * Assuming bubbling, how do you feel about adding a new event type called IDBError to capture the non-cancelable and bubbling behavior of this event? I don't see what problem that solves? / Jonas The canceling and bubbling the error event scenarios make sense to me. Thanks for clarifying! You are correct, we don't want to implement another interface. What I was proposing is to define a new event type for indexedDB errors not a new interface. We would still use the same onerror attribute but the event type would be called IDBError, not error. This would allow us to define our own bubbling and canceling behavior on the existing Event interface. Since, the DOM L3 event error type does neither (bubbling and canceling), that seems to be a good reason for us defining a new type (not interface) called IDBError. Do you see any scenarios where we should support the capture phase for the error event? I can open a bug if this makes sense. Israel
Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Mon, Apr 25, 2011 at 3:06 PM, Israel Hilerio isra...@microsoft.com wrote: On Mon, Apr 25, 2011 at 11:52 AM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio isra...@microsoft.com wrote: Step 3 in Section 4.12, Fire an error event, on the latest editor draft stipulates that: 3. Dispatch an event at request. The event must use the Event interface and have its type set to error. The event does bubble and is cancelable. ... Looking over the DOM L3 event spec, the type error Event doesn't buble and is not cancelable [1]. Pablo and I are not sure about the benefits of having the error event be cancelable. In our experience, canceling and event implies that the reason for this error can be modified or altered. Leaving this statement would imply that if a developer were to receive a NOT_ALLOWED_ERR she could cancel the error and things would work. Note that 'cancelable' has a specific defined meaning different from the one you describe above. Cancelling a event is done by calling preventDefault() and means that the events default action is not executed. In the case of IndexedDB the default action is to abort the transaction (as defined by step 3). So in other words, if we want to allow users to catch database errors and prevent them from aborting the transaction, which I assume we do, then we need to keep the event cancelable. The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. The intent is to allow attaching a event handler to just the transaction object and catch all errors happening in the scope of the transaction. For example is a page uses a transaction to insert 1000 entries into a database, it'd be nice to have a single point of attaching error handling code rather than having to do it on every individual Request object. Similarly, by allowing the event to bubble up to the database object, event handlers could be attached there that span multiple transactions. This is similar to how exceptions work. Exceptions walk up the call chain and allow you to attach error handling code higher up in the call stack which handles all errors in a given execution path. Rather than at each low-level action have to hook up error handling code. Adding bubbling to an event of type error would require us to introduce a new event type, IDBError. The reason is that we probably don't want to overload the existing DOM L3 type definition for error. There is a precedence for this in the SVG spec, the SVGError type. I don't see why making the event implement an additional interface would improve the situation. We'd still have to implement the Event interface just like DOM-Events, since all events have to implement Event. But I also don't think it's a problem that we fire an event that is similar to the one DOM-Events define, even though it uses the same name. The event isn't fired on the same objects and so no collisions should occur. I do agree it's somewhat unfortunate that some error events bubble, but others don't. But I think it'd be even worse to use a different event name, or to make the event not bubble. A couple of questions: * Do we agree that errors shouldn't be cancelable? I think we should leave it cancelable as to allow pages to do error handling and not abort the transaction. * How do we feel about bubbling? If we want to keep it, what are the main scenarios and what would the event hierarchy look like? The propagation part is defined in step 3. During the bubbling phase handlers at the IDBRequest are run first, then the ones at the IDBTransaction and then finally at the IDBDatabase. * Assuming bubbling, how do you feel about adding a new event type called IDBError to capture the non-cancelable and bubbling behavior of this event? I don't see what problem that solves? / Jonas The canceling and bubbling the error event scenarios make sense to me. Thanks for clarifying! You are correct, we don't want to implement another interface. What I was proposing is to define a new event type for indexedDB errors not a new interface. We would still use the same onerror attribute but the event type would be called IDBError, not error. This would allow us to define our own bubbling and canceling behavior on the existing Event interface. Since, the DOM L3 event error type does neither (bubbling and canceling), that seems to be a good reason for us defining a new type (not interface) called IDBError. While I don't think it's great that the error event which is fried at DOM Nodes doesn't bubble, but the ones fired at IDB objects does bubble, I think introducing a new name is an
RE: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Mon, Apr 25, 2011 at 3:13 PM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 3:06 PM, Israel Hilerio isra...@microsoft.com wrote: On Mon, Apr 25, 2011 at 11:52 AM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio isra...@microsoft.com wrote: Step 3 in Section 4.12, Fire an error event, on the latest editor draft stipulates that: 3. Dispatch an event at request. The event must use the Event interface and have its type set to error. The event does bubble and is cancelable. ... Looking over the DOM L3 event spec, the type error Event doesn't buble and is not cancelable [1]. Pablo and I are not sure about the benefits of having the error event be cancelable. In our experience, canceling and event implies that the reason for this error can be modified or altered. Leaving this statement would imply that if a developer were to receive a NOT_ALLOWED_ERR she could cancel the error and things would work. Note that 'cancelable' has a specific defined meaning different from the one you describe above. Cancelling a event is done by calling preventDefault() and means that the events default action is not executed. In the case of IndexedDB the default action is to abort the transaction (as defined by step 3). So in other words, if we want to allow users to catch database errors and prevent them from aborting the transaction, which I assume we do, then we need to keep the event cancelable. The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. The intent is to allow attaching a event handler to just the transaction object and catch all errors happening in the scope of the transaction. For example is a page uses a transaction to insert 1000 entries into a database, it'd be nice to have a single point of attaching error handling code rather than having to do it on every individual Request object. Similarly, by allowing the event to bubble up to the database object, event handlers could be attached there that span multiple transactions. This is similar to how exceptions work. Exceptions walk up the call chain and allow you to attach error handling code higher up in the call stack which handles all errors in a given execution path. Rather than at each low-level action have to hook up error handling code. Adding bubbling to an event of type error would require us to introduce a new event type, IDBError. The reason is that we probably don't want to overload the existing DOM L3 type definition for error. There is a precedence for this in the SVG spec, the SVGError type. I don't see why making the event implement an additional interface would improve the situation. We'd still have to implement the Event interface just like DOM-Events, since all events have to implement Event. But I also don't think it's a problem that we fire an event that is similar to the one DOM-Events define, even though it uses the same name. The event isn't fired on the same objects and so no collisions should occur. I do agree it's somewhat unfortunate that some error events bubble, but others don't. But I think it'd be even worse to use a different event name, or to make the event not bubble. A couple of questions: * Do we agree that errors shouldn't be cancelable? I think we should leave it cancelable as to allow pages to do error handling and not abort the transaction. * How do we feel about bubbling? If we want to keep it, what are the main scenarios and what would the event hierarchy look like? The propagation part is defined in step 3. During the bubbling phase handlers at the IDBRequest are run first, then the ones at the IDBTransaction and then finally at the IDBDatabase. * Assuming bubbling, how do you feel about adding a new event type called IDBError to capture the non-cancelable and bubbling behavior of this event? I don't see what problem that solves? / Jonas The canceling and bubbling the error event scenarios make sense to me. Thanks for clarifying! You are correct, we don't want to implement another interface. What I was proposing is to define a new event type for indexedDB errors not a new interface. We would still use the same onerror attribute but the event type would be called IDBError, not error. This would allow us to define our own bubbling and canceling behavior on the existing Event interface. Since, the DOM L3 event error type does neither (bubbling and canceling), that seems to be a good reason for us defining a new type (not interface) called IDBError. While I don't think it's great
Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12
On Mon, Apr 25, 2011 at 4:34 PM, Israel Hilerio isra...@microsoft.com wrote: On Mon, Apr 25, 2011 at 3:13 PM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 3:06 PM, Israel Hilerio isra...@microsoft.com wrote: On Mon, Apr 25, 2011 at 11:52 AM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio isra...@microsoft.com wrote: Step 3 in Section 4.12, Fire an error event, on the latest editor draft stipulates that: 3. Dispatch an event at request. The event must use the Event interface and have its type set to error. The event does bubble and is cancelable. ... Looking over the DOM L3 event spec, the type error Event doesn't buble and is not cancelable [1]. Pablo and I are not sure about the benefits of having the error event be cancelable. In our experience, canceling and event implies that the reason for this error can be modified or altered. Leaving this statement would imply that if a developer were to receive a NOT_ALLOWED_ERR she could cancel the error and things would work. Note that 'cancelable' has a specific defined meaning different from the one you describe above. Cancelling a event is done by calling preventDefault() and means that the events default action is not executed. In the case of IndexedDB the default action is to abort the transaction (as defined by step 3). So in other words, if we want to allow users to catch database errors and prevent them from aborting the transaction, which I assume we do, then we need to keep the event cancelable. The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. The intent is to allow attaching a event handler to just the transaction object and catch all errors happening in the scope of the transaction. For example is a page uses a transaction to insert 1000 entries into a database, it'd be nice to have a single point of attaching error handling code rather than having to do it on every individual Request object. Similarly, by allowing the event to bubble up to the database object, event handlers could be attached there that span multiple transactions. This is similar to how exceptions work. Exceptions walk up the call chain and allow you to attach error handling code higher up in the call stack which handles all errors in a given execution path. Rather than at each low-level action have to hook up error handling code. Adding bubbling to an event of type error would require us to introduce a new event type, IDBError. The reason is that we probably don't want to overload the existing DOM L3 type definition for error. There is a precedence for this in the SVG spec, the SVGError type. I don't see why making the event implement an additional interface would improve the situation. We'd still have to implement the Event interface just like DOM-Events, since all events have to implement Event. But I also don't think it's a problem that we fire an event that is similar to the one DOM-Events define, even though it uses the same name. The event isn't fired on the same objects and so no collisions should occur. I do agree it's somewhat unfortunate that some error events bubble, but others don't. But I think it'd be even worse to use a different event name, or to make the event not bubble. A couple of questions: * Do we agree that errors shouldn't be cancelable? I think we should leave it cancelable as to allow pages to do error handling and not abort the transaction. * How do we feel about bubbling? If we want to keep it, what are the main scenarios and what would the event hierarchy look like? The propagation part is defined in step 3. During the bubbling phase handlers at the IDBRequest are run first, then the ones at the IDBTransaction and then finally at the IDBDatabase. * Assuming bubbling, how do you feel about adding a new event type called IDBError to capture the non-cancelable and bubbling behavior of this event? I don't see what problem that solves? / Jonas The canceling and bubbling the error event scenarios make sense to me. Thanks for clarifying! You are correct, we don't want to implement another interface. What I was proposing is to define a new event type for indexedDB errors not a new interface. We would still use the same onerror attribute but the event type would be called IDBError, not error. This would allow us to define our own bubbling and canceling behavior on the existing Event interface. Since, the DOM L3 event error type does neither (bubbling and canceling), that seems to be a good reason for us
Re: [FileAPI] Result of calling MultipleReads on FileReader
On Mon, Apr 18, 2011 at 8:48 PM, Eric Uhrhane er...@google.com wrote: Apologies for the slow response. I wanted to go back and reread the relevant specs before I said anything more. Having done so, I found that XHR and FileReader were more similar than I had remembered. However, I believe I also found that the exception solution is just as consistent with XHR as the abort. On Fri, Apr 15, 2011 at 12:16 PM, Arun Ranganathan a...@mozilla.com wrote: On 4/15/11 2:57 PM, Adrian Bateman wrote: On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote: FileReader is extremely similar to XMLHttpRequest. The main difference is in how you initiate the request (.open/.send vs. .readAsX). This similarity is even getting stronger now that XHR gets .result. So I think there are good reasons to sticking to XMLHttpRequest here too. Note that no error events are fired by XMLHttpRequest. Just an abort event. So error is still reserved for actual reading errors whereas abort will fire for script-initiated aborts. I agree that calling .readAsX multiple times could be an indication of developer bugs and as such could throw an exception. However I think given the precedence set by XMLHttpRequest it could just as well mean that a new resource is now the one that the author is interested in reading. With this in mind, I don't personally have a strong feeling either way between having to call abort() explicitly or having readAsXXX implicitly call abort(). I've discussed it with others at Microsoft this week and the consensus here is that the defensive exception is better and that developers should have to call abort() if they want to abandon the current operation. I think we could live with either but right now we're planning for throwing the exception. We'd like to make a decision one way or the other pretty soon. Adrian: I'm keen to have behavior similar to XHR, and not raise an exception in this case. From your note above, I'm gathering you can live with an XHR-style abort which FileReader can fire on readAsXXX calls that have been superseded. Eric: can you point out where you think FileReader explicitly deviates in style from XHR2? It's not so much a difference in style as it is a difference in functionality. With XHR, you: Create one via the constructor [set handlers anywhere before returning] Call open() [optionally set headers, response type] Call send() With FileReader you: Create one via the constructor [set handlers anywhere before returning] Call one of the read() methods So depending on how you think of it, either: 1) read == open + send; 2) read == send, and FileReader has no equivalent to open 3) read == open, and FileReader has no send. In XHR, if you open after send, the current request will abort with no error--I believe that's the behavior Arun wants to emulate. That seems to be what you get if you use interpretation 1. Two reads in a row mean I've changed my mind. I have yet to hear a strong argument that that's likely to happen [sorry Jonas]; it still seems to me that it's far more likely to be programmer error. However, it's clearly within the spirit of XHR to go this way. However, if in XHR you try to send when the state is not OPENED or when the send() flag is set, it'll throw an exception. Calling send() sets the send() flag synchronously, so if you call send() twice in a row, you'll get INVALID_STATE_ERR exception on the second call, and the first request will not abort. That's the behavior I'd like to emulate--a fast failure on an obvious coding error--and it follows obviously from interpretation 2. Adding a check that readyState is not LOADING would have much the same effect as the send() flag check. Interpretation 3 doesn't seem to match quite as well, as nothing happens if you stop after open(), and anyway we don't need a three-way debate ;'. I think we have a free choice which way we go, since either 1 or 2 would maintain the [a?] spirit of the XHR interface. So I favor the one I think is generally more programmer-friendly. I think it's pretty clearly 1. xhr.open selects what resource to load (and how to load it), and xhr.send starts the loading. FileReader.readAsX does both. However I did realize one thing, which is that if we go with the throwing behavior for now, we can always change to non-throwing later if people complain about the inconsistency. Going the other way is much harder. So ultimately I'm fine with going either way. / Jonas
Re: [IndexedDB] Isolation mode -- edit
On Thu, Apr 21, 2011 at 4:37 PM, Eliot Graff eliot.gr...@microsoft.com wrote: What we're trying to convey is that two requests placed against different can execute in any order, but that this doesn't matter, and the isolation mode and the transaction scheduling ensures that. Thanks, that makes sense. Any objection to using your phraseology? There is no guarantee about the order in which results from requests in different transactions are returned. Similarly, the transaction modes ensure that two requests placed against different transactions can execute in any order without consequence. I would say without affecting what resulting data is stored in the database. This since the order the events fire in can affect the state of the javascript environment kept by the web page. / Jonas
[IndexedDB] which names can be the empty string?
1. Can an object store be named the empty string? 2. Can an index be named the empty string? Other things, like databases, are allowed to have a name that is the empty string. Mozilla has tests that expect both of the above cases to fail, but as I'm porting those tests to WebKit, it's not clear from my reading of the spec whether those tests are valid. -Mark Pilgrim
RE: [IndexedDB] Discrepancies with the Event type of error in section 4.12
I plan on adding wording to D3E to clarify that DOM event propagation could apply to other tree-like structures (like indexedDB objects) [1]. However, I'm not a fan of defining variable behavior for a given event type. Yes, the spec currently does this--but as you accurately point out, just because it was done before doesn't make it right. :-) Most of these inconsistencies in D3E exist to allow for legacy behavior. Take for example, the scroll event (which is the only event in D3E I can think of which has variable bubbling behavior). It's only defined to bubble in certain cases because that's what is (unfortunately) the interoperable behavior. IMO, I think XHR is wrong to overload error like this. There should be a progresserror event--but I suppose that ship has sailed. Alternatively, DOM3 Events could define an additional event type (with a name other than error) which does bubble. That way dependent specifications have a choice of which behavior to adopt. Going forward, I think we should be consistent in defining the interface, bubbling, and cancelling aspects of an event type cross-specifications. We can't correct the world as it is today, but we shouldn't proliferate the discrepancies. I think it's a complicated developer model to have an event bubble only in certain scenarios. -Jacob [1] http://www.w3.org/2008/webapps/track/issues/176 -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Monday, April 25, 2011 5:27 PM To: Israel Hilerio; Doug Schepers Cc: Jacob Rossi; public-webapps@w3.org Subject: Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12 On Mon, Apr 25, 2011 at 4:34 PM, Israel Hilerio isra...@microsoft.com wrote: On Mon, Apr 25, 2011 at 3:13 PM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 3:06 PM, Israel Hilerio isra...@microsoft.com wrote: On Mon, Apr 25, 2011 at 11:52 AM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio isra...@microsoft.com wrote: Step 3 in Section 4.12, Fire an error event, on the latest editor draft stipulates that: 3. Dispatch an event at request. The event must use the Event interface and have its type set to error. The event does bubble and is cancelable. ... Looking over the DOM L3 event spec, the type error Event doesn't buble and is not cancelable [1]. Pablo and I are not sure about the benefits of having the error event be cancelable. In our experience, canceling and event implies that the reason for this error can be modified or altered. Leaving this statement would imply that if a developer were to receive a NOT_ALLOWED_ERR she could cancel the error and things would work. Note that 'cancelable' has a specific defined meaning different from the one you describe above. Cancelling a event is done by calling preventDefault() and means that the events default action is not executed. In the case of IndexedDB the default action is to abort the transaction (as defined by step 3). So in other words, if we want to allow users to catch database errors and prevent them from aborting the transaction, which I assume we do, then we need to keep the event cancelable. The same question applies to bubbling. What is the intent of bubbling an error? For example, if a developer tries to add an object to an objectStore and he fails, where should the event bubble to: the transaction, the database, etc.? The bubbling hierarchy doesn't seem to be clearly defined. It would be great to clarify the scenarios here. The intent is to allow attaching a event handler to just the transaction object and catch all errors happening in the scope of the transaction. For example is a page uses a transaction to insert 1000 entries into a database, it'd be nice to have a single point of attaching error handling code rather than having to do it on every individual Request object. Similarly, by allowing the event to bubble up to the database object, event handlers could be attached there that span multiple transactions. This is similar to how exceptions work. Exceptions walk up the call chain and allow you to attach error handling code higher up in the call stack which handles all errors in a given execution path. Rather than at each low-level action have to hook up error handling code. Adding bubbling to an event of type error would require us to introduce a new event type, IDBError. The reason is that we probably don't want to overload the existing DOM L3 type definition for error. There is a precedence for this in the SVG spec, the SVGError type. I don't see why making the event implement an additional interface would improve the situation. We'd still have to implement the Event interface just like DOM-Events, since all events have to implement Event.
[indexedDB] transaction.objectStore(...) method question
According to the objectStore method definition in IDBTransaction, the method will return the same IDBObjectStore everytime it is invoked. Imagine the situation when the transaction is aborted, what happens when I call the objectStore method from the IDBTransaction? My interpretation of the spec is that we will continue to return the same IDBObjectStore instance. However, the next time I use the IDBObjectStore instance to read or write a value to the db, I will get an exception because the Steps for asynchronously executing a request would fail with a TRANSACTION_INACTIVE_ERR. Do you agree? Israel
[indexeddb] Cursor data Question
In reading the spec, there doesn't seem to be any long-term state associated with a cursor. However, there is an edge case I would like to validate with everyone. If I have cursor pointing to a specific data record and then I delete the record before accessing it, what happens to the value and key of the cursor object? Do we expect the cursor instance to still have the values of the currently accessed record? Israel
Re: [IndexedDB] which names can be the empty string?
Good question. I don't have a strong opinion. It makes sense to me to allow anything. Don't know I there was any reason we added explicit checks. / Jonas On Monday, April 25, 2011, Mark Pilgrim pilg...@google.com wrote: 1. Can an object store be named the empty string? 2. Can an index be named the empty string? Other things, like databases, are allowed to have a name that is the empty string. Mozilla has tests that expect both of the above cases to fail, but as I'm porting those tests to WebKit, it's not clear from my reading of the spec whether those tests are valid. -Mark Pilgrim
Re: [indexedDB] transaction.objectStore(...) method question
On Monday, April 25, 2011, Israel Hilerio isra...@microsoft.com wrote: According to the objectStore method definition in IDBTransaction, the method will return the same IDBObjectStore everytime it is invoked. Imagine the situation when the transaction is aborted, what happens when I call the objectStore method from the IDBTransaction? My interpretation of the spec is that we will continue to return the same IDBObjectStore instance. However, the next time I use the IDBObjectStore instance to read or write a value to the db, I will get an exception because the Steps for asynchronously executing a request would fail with a TRANSACTION_INACTIVE_ERR. Do you agree? Yup! / Jonas
Re: [indexeddb] Cursor data Question
On Mon, Apr 25, 2011 at 6:23 PM, Israel Hilerio isra...@microsoft.com wrote: In reading the spec, there doesn’t seem to be any long-term state associated with a cursor. However, there is an edge case I would like to validate with everyone. If I have cursor pointing to a specific data record and then I delete the record before accessing it, what happens to the value and key of the cursor object? Do we expect the cursor instance to still have the values of the currently accessed record? Yes, .value and .key are synchronous, so we don't want them to have to access data in the database. Instead they copy the data once fetched from the database. We discussed this specifically on the list iirc. This also has the effect that calling cursor.update() can create a new entry, if the old entry was removed before the call. By the way, for all of these questions, feel free to add explicit text to the specification. Preferably in the form of a note. The spec template supports this by adding: p class=note /p / Jonas
RE: [indexeddb] Cursor data Question
On Mon, Apr 25, 2011 at 6:41 PM, Jonas Sicking wrote: On Mon, Apr 25, 2011 at 6:23 PM, Israel Hilerio isra...@microsoft.com wrote: In reading the spec, there doesn't seem to be any long-term state associated with a cursor. However, there is an edge case I would like to validate with everyone. If I have cursor pointing to a specific data record and then I delete the record before accessing it, what happens to the value and key of the cursor object? Do we expect the cursor instance to still have the values of the currently accessed record? Yes, .value and .key are synchronous, so we don't want them to have to access data in the database. Instead they copy the data once fetched from the database. We discussed this specifically on the list iirc. This also has the effect that calling cursor.update() can create a new entry, if the old entry was removed before the call. By the way, for all of these questions, feel free to add explicit text to the specification. Preferably in the form of a note. The spec template supports this by adding: p class=note /p / Jonas Great! I will work with Eliot to add text to spec to capture this behavior. Israel
RE: [indexedDB] transaction.objectStore(...) method question
On Monday, April 25, 2011, 6:37 PM, Jonas Sicking wrote: On Monday, April 25, 2011, Israel Hilerio isra...@microsoft.com wrote: According to the objectStore method definition in IDBTransaction, the method will return the same IDBObjectStore everytime it is invoked. Imagine the situation when the transaction is aborted, what happens when I call the objectStore method from the IDBTransaction? My interpretation of the spec is that we will continue to return the same IDBObjectStore instance. However, the next time I use the IDBObjectStore instance to read or write a value to the db, I will get an exception because the Steps for asynchronously executing a request would fail with a TRANSACTION_INACTIVE_ERR. Do you agree? Yup! / Jonas Great! I will work with Eliot to make a note on the spec about this.
Re: Model-driven Views
On 4/22/11 8:35 PM, Rafael Weinstein wrote: Myself and a few other chromium folks have been working on a design for a formalized separation between View and Model in the browser, with needs of web applications being the primary motivator. Our ideas are implemented as an experimental Javascript library: https://code.google.com/p/mdv/ and the basic design is described here: http://mdv.googlecode.com/svn/trunk/docs/design_intro.html. The interesting thing to me is that the DOM is what's meant to be the model originally, as far as I can tell, with the CSS presentation being the view I guess we ended up with too much view leakage through the model so we're adding another layer of model, eh? -Boris
