Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15
On Wed, Sep 26, 2012 at 10:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Gamepad - Scott, Ted - what's the status of the spec and its implementation? We probably need to discuss a bit more, but I think the spec is pretty close to a first version. The one large issue that we haven't tackled yet is how button layouts should be described. Scott and I have talked about that a bit, but we need to nail it down. I'm reasonably happy with the rest of it, I think there's enough there to be useful without wandering off into more complex territory. AFAIK Chrome has shipped an implementation. The Firefox implementation is hung up in review still because it's been a side project for me. I'd like to get it landed in nightly builds soon. -Ted
Re: [admin] Call for Editor for XHR REC track doc
On 9/25/12 7:00 PM, ext Arthur Barstow wrote: If you are interested in this Editor position, please contact me offlist. Thanks to those that expressed interest in helping move the XHR spec along the Recommendation track. We selected three co-Editors for this spec: Julian Aubourg (jQuery), Jungkee Song (Samsung) and Hallvord Steen (Opera). -Regards, Art and Chaals [XHR] http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
RE: In WebIDL, should having a .prototype on interface objects be optional?
From: Rick Waldron [mailto:waldron.r...@gmail.com] I wasn't specific enough in my original question, but I did note that I wasn't referring to construction exceptions, so I'm guessing by your response that you actually _just_ meant testing for constructability. I apologize for not being clearer, but I was actually referring to the URL string parameter itself, and how to test if passing an argument to the constructor is supported (the example I gave falls short of answering that question). Loosely related... will invalid URL string parameters throw in the same manner that invalid selectors throw? eg. context.querySelector(?) Hmm, that's not a question for WebIDL, as far as I know. The spec defining the constructor behavior would need to specify that.
Re: In WebIDL, should having a .prototype on interface objects be optional?
On Mon, Oct 1, 2012 at 10:58 AM, Travis Leithead travis.leith...@microsoft.com wrote: From: Rick Waldron [mailto:waldron.r...@gmail.com] I wasn't specific enough in my original question, but I did note that I wasn't referring to construction exceptions, so I'm guessing by your response that you actually _just_ meant testing for constructability. I apologize for not being clearer, but I was actually referring to the URL string parameter itself, and how to test if passing an argument to the constructor is supported (the example I gave falls short of answering that question). Loosely related... will invalid URL string parameters throw in the same manner that invalid selectors throw? eg. context.querySelector(?) Hmm, that's not a question for WebIDL, as far as I know. The spec defining the constructor behavior would need to specify that. Fair enought, apologies for the noise. Thanks! Rick
Re: [IndexedDB] blocked event could be an error
On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 27, 2012 at 6:47 AM, João Eiras jo...@opera.com wrote: http://odinho.html5.org/IndexedDB/spec/Overview.html Like I said, I think it's too late to make such a big change. I believe it's much too late to make such a change in IE10, and we have been shipping Firefox with the current behavior for quite a while now (and are about to unprefix with our current behavior). / Jonas Sorry but it is not late. It's actually quite early and the right time. I don't know by what measure it's quite early or the right time. It'd be the right time because though IDB usage is picking up, it's still relatively low. Optimally this change would have been made a few months or years ago, but now is better than later. We've passed Last Call, there are 3 shipping implementations, all of which have considered their implementation complete enough to switch from prefixed implementations to unprefixed ones. They all implement the behavior that you are proposing to change. We'd be ok with changing this, our unprefixedness notwithstanding. I think the pain it would save developers down the road would make up for the immediate pain it would cause to both vendors and developers. But that's just a judgment call, I'm relying on intuition and obviously have no data about what the future will hold. To balance the concerns of open with complicated semantics and backward-compatibility, I propose that we add two methods to IDBFactory: openOrFail and openOrBlock. Most introductory IDB tutorials and examples would steer developers towards openOrFail. The current open method would be an alias for openOrBlock. That open's documentation would be [deprecated] alias for openOrBlock should give developers some pause about using it just because it has the simplest name. At least the Amazon cloud reader uses IndexedDB. I've started receiving enough questions about IDB that I would imagine that there are more websites deployed which uses it. / Jonas
