[xhr] remove readystatechange event fired while invoking async send()?
In step eight of the send() method a substep fires a readystatechange event while the state of the object does not actually change. Internet Explorer and Firefox implement this, Safari, Chrome, and Opera do not. It would be somewhat cleaner if we remove it as then readyState would go 1,2,3,4 rather than 1,1,2,3,4. And it seems we can remove it given that in six years nobody felt the need to become interoperable on this. Objections? -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] Numeric constants vs enumerated strings
On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking jo...@sicking.cc wrote: Yes! I would love to make this change. This is my main peeve with the API as it stands. Cool! :D I even think that implementations could remove support for the numbers by keeping the constants but have them defined to return string values. I.e. db.transaction([store], IDBTransaction.READ_WRITE); would continue to work and is the usage pattern that I've seen in all code that I've looked at. Ah, that is a very smart idea. We just had the break of open() with upgradeneeded instead of setVersion. That's a much bigger break, and if most of us get this in with the same change - it can just slip nicely in. The code would have to change anyway. So I think it's not too hard to remove the constants as well. It's obviously a bit different for Mozilla, since they've shipped their setVersion killer already, but generally Mozilla is not afraid of changing stuff if they want to (and it doesn't hurt too much, which IMHO it won't in this case, sync XHR + CORS is much more painful :P). The few people who code directly to nightly versions will be used to changing their code anyway. Keep supporting the numbers is OK, but a bit strange, given the above reasons. As long as it's not possible to rely on the numbers, I hope that developers won't use it anyway, and it'll slowly become obsolete. Then it can be very easily removed again. Although skipping that dance is of course even better ;-) To be honest, I think authors will use the enumerated strings - so if some implementations do some backwards compat stuff, it'll hopefully become obsolete. -- Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /
Re: StreamBuilder threshold
On 02/23/2012 12:58 AM, Feras Moussa wrote: -Original Message- From: Stefan Hakansson LK [mailto:stefan.lk.hakans...@ericsson.com] Sent: Sunday, February 05, 2012 4:50 AM To: Feras Moussa Cc: Travis Leithead; public-webapps@w3.org Subject: Re: StreamBuilder threshold On 01/26/2012 07:05 PM, Feras Moussa wrote: Can you please clarify what scenario you are looking at regarding multiple consumers? When designing the StreamBuilder API, we looked at it as a more primitive API which other abstractions (such as multiple consumers) can be built upon. (Please forgive me if I am making stupid input - I am in a learning phase). A very simple scenario would be the example in the draft that demonstrates how to use StreamBuilder to load a stream into the audio tag. In this example the consumer is an audio tag, and new data is appended to the stream each time the buffer falls below 1024 bytes. Fine so far, but what happens if the same stream (via createObjectURL) is connected to one more audio tag, but at T ms later. In this case the first audio tag would have consumed down to the threshold (1024 bytes) T ms before the second. This isn't clear from the spec (And I've made a note to clarify it) but URLs for streams should be one time use URLs (once used it should be automatically revoked). Thus a scenario as you said below (connecting the same stream to multiple tags) isn't possible. There will only be one event to notify the threshold has been reached, thus there should not be multiple consumers 'racing' for this event. Would be great to clarify. But to my understanding you could always call createObjectURL again with the same Stream as input argument. Even if both createObjectURL's generate one-time URLs, you could have a 'race' condition. Another example could be that one Stream is uploaded using two parallel xhr's; one of them could have a couple of pakcet losses and then consume slower than the other (and if WS could take send(stream) the same would apply). If you can please let me know what issue you're trying to address, I'm happy to discuss the possibilities. I hope the above input explained the issue. However, I'm still not clear on what the scenario you'd like to accomplish is - can you please explain it in more detail? If you're looking for a way to reuse data from a Stream, then you should use StreamReader to read the data as a Blob (or another type) which will then provide you with all the Blob semantics, including multiple reads on the data. Actually I am not trying to satisfy a specific scenario, but I've heard people thinking about sending a Stream (being generated at this device using StreamBuilder) to several remote ends. I think this would not really work since there would always be some differences in transmission speed and then the low buffer threshold would have several different triggers (as discussed above). I think it need to be clarified that you can't do this (or attach it to several tags), but it is not clear how to clarify it to me (as said above, even if you have one time URLs you can create several of them). Thanks, Stefan Thanks, Feras Also, For future reference, the latest draft is now located on the W3 site at http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm Thanks for updating me! Stefan Thanks, Feras -Original Message- From: Stefan Hakansson LK [mailto:stefan.lk.hakans...@ericsson.com] Sent: Tuesday, January 17, 2012 12:28 AM To: Feras Moussa; Travis Leithead Cc: public-webapps@w3.org Subject: StreamBuilder threshold I'm looking at http://html5labs.interoperabilitybridges.com/streamsapi/, and specifically at the StreamBuilder. It has the possibility to generate an event if the data available falls below a threshold. How is this supposed to work if there is more than one consumer, and those consumers either don't start consuming at exactly the same time or consume at different rates, of the Stream? --Stefan
[DOM4] EventTarget as first class citizen
Hi,
Would it be possible for DOM4 to define a way for user objects to be able to
extend EventTarget (as in Object.create(EventTarget))?
The use case: give the ability to create objects that can dispatch events using
native means… instead of hacking around it like so:
var obj = Object.create(null);
var dispatcher = document.createElement(x-EventDispatcher);
//implement EventTarget interface on obj
Object.defineProperty(obj, addEventListener, {
value: function(type, callback, capture){
dispatcher.addEventListener(type, callback, capture);
}
});
Object.defineProperty(obj, removeEventListener, {
value: function(type, callback, capture){
dispatcher.removeEventListener(type, callback, capture);
}
});
Object.defineProperty(obj, dispatchEvent, {
value: function(e){
dispatcher.dispatchEvent(e);
}
});
var e = document.createEvent('CustomEvent');
e.initEvent(myEvent, false, false, null);
dispatcher.dispatchEvent(e);
Also, AFAIK, all JS frameworks have implemented custom ways of handling events
and how they are dispatched, so clearly its a desired part of the platform. For
example:
http://developer.yahoo.com/yui/docs/YAHOO.util.CustomEvent.html
http://api.jquery.com/category/events/event-object/
http://dojotoolkit.org/reference-guide/quickstart/events.html
Developers have also built their own:
http://www.nczonline.net/blog/2010/03/09/custom-events-in-javascript/
Other solutions fire at the document, which means registering listeners on an
object that is not the one that needs to receive the event:
http://tiffanybbrown.com/2011/10/12/dispatching-custom-dom-events/
So, together with CustomEvents provided by the platform, it would be nice to
have a custom EventTarget to fire those things at :)
Kind regards,
Marcos
--
Marcos Caceres
Re: [IndexedDB] Numeric constants vs enumerated strings
On Thu, 23 Feb 2012 10:47:56 +0100, Odin Hørthe Omdal odi...@opera.com wrote: On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking jo...@sicking.cc wrote: Yes! I would love to make this change. This is my main peeve with the API as it stands. Cool! :D I even think that implementations could remove support for the numbers by keeping the constants but have them defined to return string values. I.e. db.transaction([store], IDBTransaction.READ_WRITE); would continue to work and is the usage pattern that I've seen in all code that I've looked at. Ah, that is a very smart idea. We just had the break of open() with upgradeneeded instead of setVersion. That's a much bigger break, and if most of us get this in with the same change - it can just slip nicely in. The code would have to change anyway. So I think it's not too hard to remove the constants as well. It's obviously a bit different for Mozilla, since they've shipped their setVersion killer already, but generally Mozilla is not afraid of changing stuff if they want to (and it doesn't hurt too much, which IMHO it won't in this case, sync XHR + CORS is much more painful :P). The few people who code directly to nightly versions will be used to changing their code anyway. Keep supporting the numbers is OK, but a bit strange, given the above reasons. As long as it's not possible to rely on the numbers, I hope that developers won't use it anyway, and it'll slowly become obsolete. Then it can be very easily removed again. Although skipping that dance is of course even better ;-) To be honest, I think authors will use the enumerated strings - so if some implementations do some backwards compat stuff, it'll hopefully become obsolete. I think if we want the end result to be strings only, the best way to get there is for everyone to remove support for constants and numbers at the same time as they implement support for strings. -- Simon Pieters Opera Software
Re: [IndexedDB] Numeric constants vs enumerated strings
On Thu, 23 Feb 2012 13:09:20 +0100, Simon Pieters sim...@opera.com wrote: I think if we want the end result to be strings only, the best way to get there is for everyone to remove support for constants and numbers at the same time as they implement support for strings. Agreed. Note that Web IDL does not support string constants anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOM4] Constructor for DOMException?
On Thu, 23 Feb 2012 00:57:54 +0100, Cameron McCormack c...@mcc.id.au wrote: João Eiras: DOMExceptions have both a code and a message. Perhaps the constructor should be extended to include both. Anne van Kesteren: code is legacy, but name would be good to expose. The constructor has the same signature as the standard ECMAScript Error constructors, so we are being consistent there. I think it's fine for code and name to be assigned after creating the object, if JS needs to create a DOMException object (which I don't expect to be a common thing anyway). Well, it does make # throw new DOMException(message) and bit more verbose: # var e = new DOMException(message); # e.code value; # throw e; Adding the code as a second optional argument would be ok.
Re: [IndexedDB] Numeric constants vs enumerated strings
On Thu, Feb 23, 2012 at 1:09 PM, Simon Pieters sim...@opera.com wrote: On Thu, 23 Feb 2012 10:47:56 +0100, Odin Hørthe Omdal odi...@opera.com wrote: On Thu, 23 Feb 2012 01:27:27 +0100, Jonas Sicking jo...@sicking.cc wrote: Yes! I would love to make this change. This is my main peeve with the API as it stands. Cool! :D I even think that implementations could remove support for the numbers by keeping the constants but have them defined to return string values. I.e. db.transaction([store], IDBTransaction.READ_WRITE); would continue to work and is the usage pattern that I've seen in all code that I've looked at. Ah, that is a very smart idea. We just had the break of open() with upgradeneeded instead of setVersion. That's a much bigger break, and if most of us get this in with the same change - it can just slip nicely in. The code would have to change anyway. So I think it's not too hard to remove the constants as well. It's obviously a bit different for Mozilla, since they've shipped their setVersion killer already, but generally Mozilla is not afraid of changing stuff if they want to (and it doesn't hurt too much, which IMHO it won't in this case, sync XHR + CORS is much more painful :P). The few people who code directly to nightly versions will be used to changing their code anyway. Keep supporting the numbers is OK, but a bit strange, given the above reasons. As long as it's not possible to rely on the numbers, I hope that developers won't use it anyway, and it'll slowly become obsolete. Then it can be very easily removed again. Although skipping that dance is of course even better ;-) To be honest, I think authors will use the enumerated strings - so if some implementations do some backwards compat stuff, it'll hopefully become obsolete. I think if we want the end result to be strings only, the best way to get there is for everyone to remove support for constants and numbers at the same time as they implement support for strings. Yes. I definitely think that we should put just plain strings in the spec. But implementations can use various tactics to move their support to that while giving people a migration path. Of course, I think we need to get Microsoft's approval on this. / Jonas
Re: [DOM4] EventTarget as first class citizen
On Thu, Feb 23, 2012 at 12:21 PM, Marcos Caceres w...@marcosc.com wrote:
Hi,
Would it be possible for DOM4 to define a way for user objects to be able to
extend EventTarget (as in Object.create(EventTarget))?
The use case: give the ability to create objects that can dispatch events
using native means… instead of hacking around it like so:
var obj = Object.create(null);
var dispatcher = document.createElement(x-EventDispatcher);
//implement EventTarget interface on obj
Object.defineProperty(obj, addEventListener, {
value: function(type, callback, capture){
dispatcher.addEventListener(type, callback, capture);
}
});
Object.defineProperty(obj, removeEventListener, {
value: function(type, callback, capture){
dispatcher.removeEventListener(type, callback, capture);
}
});
Object.defineProperty(obj, dispatchEvent, {
value: function(e){
dispatcher.dispatchEvent(e);
}
});
var e = document.createEvent('CustomEvent');
e.initEvent(myEvent, false, false, null);
dispatcher.dispatchEvent(e);
Also, AFAIK, all JS frameworks have implemented custom ways of handling
events and how they are dispatched, so clearly its a desired part of the
platform. For example:
http://developer.yahoo.com/yui/docs/YAHOO.util.CustomEvent.html
http://api.jquery.com/category/events/event-object/
http://dojotoolkit.org/reference-guide/quickstart/events.html
Developers have also built their own:
http://www.nczonline.net/blog/2010/03/09/custom-events-in-javascript/
Other solutions fire at the document, which means registering listeners on an
object that is not the one that needs to receive the event:
http://tiffanybbrown.com/2011/10/12/dispatching-custom-dom-events/
So, together with CustomEvents provided by the platform, it would be nice to
have a custom EventTarget to fire those things at :)
I think the way we should do this is to enable instantiating
EventTarget objects using an EventTarget ctor. This won't give you a
neato extension syntax, but I think we'll have to rely on ES.next for
that. Before ecma-script has a better solution you can always
monkeypatch the object.
So something like:
a = new EventTarget();
b = new EventTarget(a); // a is the parent in the target chain
should be doable. I don't know if we need a way to modify the parent
chain after construction. It's somewhat complex to allow this while
still preventing cycles from being created.
/ Jonas
[IndexedDB] IDBDAtabase.transaction clarification
Hi. It seems IDBDatabase.transaction in the working draft is poorly defined. IDBDatabase.transaction, according to the transaction creation algorithm, have a null callback, but then IDBDatabase.createObjectStore and IDBDatabase.deleteObjectStore say they should fail if not called from the transaction callback. I think it should be changed so they fail if there is not an active transaction, or that the current active transaction is not a VERSION_CHANGE one. Is this the intended behavior ? It tells IDBDatabase.transaction returns the IDBTransaction object. Shouldn't it be an IDBRequest object ? If not, then what the lifetime of the transaction ? When should it be commited ? IDBDatabase.transaction accepts either an array of strings or string as first argument, which are the name of the object stores. What should be used for the very first transaction of an empty database with no object stores ? Empty array ?
[Bug 16094] New: Do not allow editing commands to affect editing hosts that aren't near the selection
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16094 Summary: Do not allow editing commands to affect editing hosts that aren't near the selection Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org (In reply to bug 13118 comment #20) I think similar problems can arise with selections spanning non-nested editing hosts, or outside of editing hosts entirely. E.g., per current spec, running indent on foodiv style=display:inline contenteditable=truebar/div[baz] will actually produce foodiv style=display:inline contenteditable=trueblockquotebar/blockquote/div[baz] or something, I think. This is probably just a spec bug, though! Probably block-extending the selection shouldn't cross editing hosts. So we should try to make sure that commands don't affect any editing hosts that aren't ancestors of some node that's contained or partially contained in the selection? This should be changed. If the selection doesn't touch an editing host, commands should never affect it. Likewise, if multiple beforeInput events get fired at different editing hosts, canceling some should make the command not affect that editing host. -- Configure bugmail: https://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: [IndexedDB] IDBDAtabase.transaction clarification
On Thu, Feb 23, 2012 at 9:27 PM, João Eiras jo...@opera.com wrote: Hi. It seems IDBDatabase.transaction in the working draft is poorly defined. IDBDatabase.transaction, according to the transaction creation algorithm, have a null callback, but then IDBDatabase.createObjectStore and IDBDatabase.deleteObjectStore say they should fail if not called from the transaction callback. I think it should be changed so they fail if there is not an active transaction, or that the current active transaction is not a VERSION_CHANGE one. Is this the intended behavior ? Yes. Please file a bug. It tells IDBDatabase.transaction returns the IDBTransaction object. Shouldn't it be an IDBRequest object ? If not, then what the lifetime of the transaction ? When should it be commited ? IDBTransaction is correct. How committing works should be detailed in the Transaction part of the Constructs section: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#transaction-concept IDBDatabase.transaction accepts either an array of strings or string as first argument, which are the name of the object stores. What should be used for the very first transaction of an empty database with no object stores ? Empty array ? When a database is created a VERSION_CHANGE transaction is automatically created. So there is no need to call IDBDatabase.transaction. Not entirely sure I understand the question here. / Jonas
Re: [IndexedDB] IDBDAtabase.transaction clarification
IDBDatabase.transaction accepts either an array of strings or string as first argument, which are the name of the object stores. What should be used for the very first transaction of an empty database with no object stores ? Empty array ? When a database is created a VERSION_CHANGE transaction is automatically created. So there is no need to call IDBDatabase.transaction. Not entirely sure I understand the question here. Then how can one get a reference to that IDBTransaction object ?
[Bug 16095] New: Element with contenteditable=true shouldn't be considered as an editing host if it's already in an editable region
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16095 Summary: Element with contenteditable=true shouldn't be considered as an editing host if it's already in an editable region Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: rn...@webkit.org QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org This is a request to match the original HTML5 spec definition of the editing host. Elements with contenteditable=true shouldn't define a new editing host unless the element is in a non-editable region (i.e. it doesn't have an editing host of its own). This matches the way CSS inheritance and computed value works. WebKit can't implement the current definition of editing host since we use CSS style resolver to decide whether a given element is an editing host or not. -- Configure bugmail: https://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: [IndexedDB] Transactions during window.unload?
I'm not sure we should include this in the IDB spec. The reason is that I
would expect every browser to provide different guarantees based on their
internals. In our case after the Javascript engine finishes its processing,
the server starts its processing and once started the server started its
transaction it would be difficult for us to abort the transaction. However, if
the page is navigated while the Javascript engine is still processing, the
transaction will never be committed.
You can also get into all kinds of corner cases where the Javascript engine
finished processing but the server requests haven't started, or the Javascript
engine finished processing and the server request was sent.
Adding this to the spec would make it difficult for us to provide unique
solutions to are spec compliant.
Israel
On Tuesday, February 21, 2012 2:34 PM, Joshua Bell wrote:
On Tue, Feb 21, 2012 at 1:40 PM, Joshua Bell
jsb...@chromium.orgmailto:jsb...@chromium.org wrote:
In a page utilizing Indexed DB, what should the expected behavior be for an
IDBTransaction created during the window.onunload event callback?
e.g.
window.onunload = function () {
var transaction = db.transaction('my-store', IDBTransaction.READ_WRITE);
transaction.onabort = function () { console.error('aborted'); };
transaction.oncomplete = function () { console.log('completed'); };
var request = transaction.objectStore('my-store').put('value', 'key');
request.onsuccess = function () { console.log('success'); };
request.onerror = function () { console.error('error'); };
};
I'm not sure if there's a spec issue here, or if I'm missing some key
information (from other specs?).
As the execution context is being destroyed, the database connection would be
closed. (3.1.1). But the implicit close of the database connection would be
expected to wait on the pending transaction (4.9, step 2). As written, step 6
of lifetime of a transaction (3.1.7) would kick in, and the implementation
would attempt to commit the transaction after the unload event processing was
completed. If this commit is occurring asynchronously in a separate
thread/process, it would require that the page unload sequence block until the
commit is complete, which seems very undesirable.
Alternately, the closing page could abort any outstanding transactions.
However, this leads to a race condition where the asynchronous commit could
succeed in writing to disk before the abort is delivered.
Either way, I believe that that after the unload event there are no more spins
of the JS event loop, so therefore none of the events
(abort/complete/success/error) will ever be seen by the script.
Is there an actual spec issue here, or is my understanding just incomplete?
... and since I never actually wrote it: if there is a spec issue here, my
suggestion is that we should specify that any pending transactions are
automatically aborted after the unload event processing is complete. In the
case of transactions created during unload, they should never be given the
chance to start to commit, avoiding a possible race condition. (Script would
never see the abort event, of course.)
Disallowing mutation events in shadow DOM
Can we disallow mutation events inside shadow DOM? There is no legacy content that depends on mutation events API inside shadow DOM, and we have a nice spec implementation of new mutation observer API already. FYI, https://bugs.webkit.org/show_bug.cgi?id=79278 Best, Ryosuke Niwa Software Engineer Google Inc.
Re: Disallowing mutation events in shadow DOM
On 02/24/2012 01:38 AM, Ryosuke Niwa wrote: Can we disallow mutation events inside shadow DOM? Sounds good to me. Whatever shadow dom spec will be implemented, mutation events shouldn't fire there. Mutation observers should work. -Olli There is no legacy content that depends on mutation events API inside shadow DOM, and we have a nice spec implementation of new mutation observer API already. FYI, https://bugs.webkit.org/show_bug.cgi?id=79278 Best, Ryosuke Niwa Software Engineer Google Inc.
Re: Disallowing mutation events in shadow DOM
Sounds good. Filed a bug here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16096 :DG On Thu, Feb 23, 2012 at 3:38 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we disallow mutation events inside shadow DOM? There is no legacy content that depends on mutation events API inside shadow DOM, and we have a nice spec implementation of new mutation observer API already. FYI, https://bugs.webkit.org/show_bug.cgi?id=79278 Best, Ryosuke Niwa Software Engineer Google Inc.
Re: Disallowing mutation events in shadow DOM
Just to be clear on this: what is the status of mutation observers? If there any chance shadow dom beats mutation observers to standardization? I don't think so, but just checking... If that turned out to be the case it could be crippling shadow dom until such a time.. Brian On Feb 23, 2012 6:46 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Sounds good. Filed a bug here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16096 :DG On Thu, Feb 23, 2012 at 3:38 PM, Ryosuke Niwa rn...@webkit.org wrote: Can we disallow mutation events inside shadow DOM? There is no legacy content that depends on mutation events API inside shadow DOM, and we have a nice spec implementation of new mutation observer API already. FYI, https://bugs.webkit.org/show_bug.cgi?id=79278 Best, Ryosuke Niwa Software Engineer Google Inc.
Re: Disallowing mutation events in shadow DOM
On 02/24/2012 02:10 AM, Brian Kardell wrote: Just to be clear on this: what is the status of mutation observers? They are in DOM 4. The API may still change a bit, but there is already one implementation, and another one close to ready. If there any chance shadow dom beats mutation observers to standardization? AFAIK, shadow DOM is quite far from being stable. I don't think so, but just checking... If that turned out to be the case it could be crippling shadow dom until such a time.. Brian On Feb 23, 2012 6:46 PM, Dimitri Glazkov dglaz...@chromium.org mailto:dglaz...@chromium.org wrote: Sounds good. Filed a bug here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16096 :DG On Thu, Feb 23, 2012 at 3:38 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: Can we disallow mutation events inside shadow DOM? There is no legacy content that depends on mutation events API inside shadow DOM, and we have a nice spec implementation of new mutation observer API already. FYI, https://bugs.webkit.org/show_bug.cgi?id=79278 Best, Ryosuke Niwa Software Engineer Google Inc.
Re: Disallowing mutation events in shadow DOM
On Thu, Feb 23, 2012 at 4:10 PM, Brian Kardell bkard...@gmail.com wrote: Just to be clear on this: what is the status of mutation observers? If there any chance shadow dom beats mutation observers to standardization? I don't think so, but just checking... If that turned out to be the case it could be crippling shadow dom until such a time.. I second Olli's opinion. Also, I don't think we're wiling to ship shadow DOM with mutation events enabled regardless. At least, I'll do everything I can to prevent that from happening. - Ryosuke
Re: Disallowing mutation events in shadow DOM
Yeah that was pretty much my feeling but always worth checking. On Feb 23, 2012 7:13 PM, Olli Pettay olli.pet...@helsinki.fi wrote: On 02/24/2012 02:10 AM, Brian Kardell wrote: Just to be clear on this: what is the status of mutation observers? They are in DOM 4. The API may still change a bit, but there is already one implementation, and another one close to ready. If there any chance shadow dom beats mutation observers to standardization? AFAIK, shadow DOM is quite far from being stable. I don't think so, but just checking... If that turned out to be the case it could be crippling shadow dom until such a time.. Brian On Feb 23, 2012 6:46 PM, Dimitri Glazkov dglaz...@chromium.org mailto:dglaz...@chromium.org wrote: Sounds good. Filed a bug here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16096 :DG On Thu, Feb 23, 2012 at 3:38 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: Can we disallow mutation events inside shadow DOM? There is no legacy content that depends on mutation events API inside shadow DOM, and we have a nice spec implementation of new mutation observer API already. FYI, https://bugs.webkit.org/show_bug.cgi?id=79278 Best, Ryosuke Niwa Software Engineer Google Inc.
[webapps-component] Web and Canvas Components, select, audio controls and ARIA
Regarding UI components in web applications For me it's been an uphill battle to have Canvas surfaces recognized as a legitimate surface for interactive UI controls. I know XBL advocates have had quite a battle in developing a markup syntax for packaging UI components. I suppose I should be grateful. Without these battles, I'd have nothing to talk about... What say you all about recognizing this situation as a class of problems and addressing it as such? I've yet to reach a shared reality with Dimitri Glazkov, as he authors web components, I've yet to reach a compromise with Tab Atkins and Ian Hickson, the editor and assistant person-thing of HTML5, and I can barely hold a consensus with Rich Schwerdtfeger, a previous editor and prime mover of ARIA. Yet, these all live in the same realm of Web Apps UI. They are somewhat separable from Web Apps APIs. While I seem to have connected with Richard on the concept that ARIA should be applied to UI components (not that difficult, since that matches his world view), I'm struggling with others to gain consensus on the importance of UI APIs. Tab and Ian have gone with a pure markup model, where the UA could/should and all the work declarative. Dimitri is in between, providing a markup language and shadow DOM, but not yet addressing other imperative APIs. That's my situation with spec contributors. And now onto element cases: select / has been around a long long time. It's a unique element in that it may display outside of the browser window. When I tap on a select element, the options list may go beyond the bounds of the client window. Neat stuff. It's one of the untouchable elements when it comes to CSS. Everyone and their grandmother has programmed some form of select via div. That's a big part of the motivation behind ARIA's creation. select / hasn't changed much. We can now style the font and background, and maybe the scroll bars if we use some vendor-prefixed CSS. That's about it. select / [option] is a prime example of CSS+HTML Forms failing to work together. audio controls, now that's an interesting case. This media element was designed with flexibility in mind. The flexibility being that, you use @controls, or you roll your own UI and we'll give you everything in the API you need to do it. It's great, but the built-in UI suffers from the all-or-nothing phenomenon. And that sucks, because I have made CSS hacks with with the audio tag. I re-discovered that the css @zoom attribute is important for web components. I've used CSS transforms and had as much fun with audio @controls as I have with repainting the canvas tag to meet my visibility needs. That's all great, but I came up against an obstacle in implementations. I can't push and pull the audio tag out of the DOM without causing a stutter in the audio playing in Chrome. I filed a bug, sure, but I lost my ability to really use the audio tag in a flexible manner with @controls. I'm forced to implement my own @controls UI, even though I really would prefer to use the one packaged with the browser. All or nothing, and when something, something minor breaks, I'm back to nothing. I'd really like to use the progress meter, and play and volume buttons that are implemented for audio controls. But I can't, because it's all or nothing. Then there's ARIA. There are some great techniques to expose data with ARIA. Now that CSS selectors are working with ARIA, I tell you my world is getting easier each day. But even ARIA can't help me with audio. I can't markup my custom play, pause, and I am indeed playing audio right now, elements in ARIA. So the moment I remove my audio controls tag from the DOM, because it fails on me, I also remove the opportunity for any standard method of pausing or detecting that audio is playing in my window. While we can argue these are about bugs, or these are just shortcomings of browser vendors who haven't reached an ideal situation: they just haven't made that final convergence that the HTML5 editor is hoping for, I'd prefer to have a focused discussion on how we can meet obligations of programmatic access and of re-usability. I'd like to find a means of testing, talking about and solving issues with these UI components. ARIA has done a lot for that. I can prove that an AT is getting sufficient access to a component. I can prove that the scripting environment also has sufficient access. I want to carry that work forward. To do that, I need to have a consensus of some sort in webapps that we are talking about the same thing. Can I provide details to an audio controls UI that allows the progress meter to monitor progress? I've got everything but a means to say, yeah dude, you're at minute 1 and 20 seconds. Can I provide details to the UA and AT that an audio element is currently playing and spouting out some volume? Can I write a select element in canvas where I have indeed applied style to individual
Re: [IndexedDB] IDBDAtabase.transaction clarification
req = indexedDB.open(mydb, 5);
req.onupgradeneeded = function(e) {
assert(e.target === req);
var thetransaction = req.transaction;
var thedb = req.result;
doStuffWith(thetransaction, thedb);
}
req.onsuccess = function(e) {
assert(e.target === req);
assert(req.transaction === null);
var thedb = req.result;
alert(the database is now open);
}
/ Jonas
On Thu, Feb 23, 2012 at 10:56 PM, João Eiras jo...@opera.com wrote:
IDBDatabase.transaction accepts either an array of strings or string as
first argument, which are the name of the object stores. What should
be used for the very first transaction of an empty database with no
object stores ? Empty array ?
When a database is created a VERSION_CHANGE transaction is
automatically created. So there is no need to call
IDBDatabase.transaction. Not entirely sure I understand the question
here.
Then how can one get a reference to that IDBTransaction object ?
