Event handlers - Pointer Devices
This is a re-post from the WHATWG mailing list. They've suggested I take the discussion to this list, as pointer events have not yet been formalized. I'd like to know if there's room or any work has been done to set aside a standard for an extended set of pointer-device events. With touch screens and touch sensitivity becoming quite main-stream, I'd like to see this popular functionality supported by the HTML 5 standard. We see, in the iPhone, an ontouchstart and ongesturestart, and company. Gesture is a nice way of saying multiple inputs, and it works well. While many people would like to wrap the ontouch events into onmouse events -- they do have some different semantics. And, I believe that ontouch would be a good place to add in pressure sensitivity indexes. So, I thought I'd solicit feedback here. I'd like a common API to support touch screens and pressure/angle sensitive touch devices. I believe that both Apple and Wacom have thrown their hats into the ring, and we can easily integrate their achievements. -Charles
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/1/2010 2:52 PM, Jeremy Orlow wrote:
Thanks for the pointers. I'm actually pretty sold on the general
idea of promises, and my intuition is that there won't be a very
big resource penalty for using an API like this rather than
callbacks or what's currently specced. At the same time, it seems
as though there isn't much of a standard in terms of the precise
semantics and some of the techniques (such as optionally taking
callbacks and not returning a promise if they are supplied) seems
like a decent answer for pure javascript APIs, but maybe not as
good for IDL and a standard like this.
Do you guys have any recommendations for the precise semantics we'd
use, if we used promises in IndexedDB? To get started, let me list
what I'd propose and maybe you can offer counter proposals or
feedback on what would or wouldn't work?
Each method on a Request interface (the async ones in the spec)
whose counterpart returns something other than void would instead
return a Promise.
Asynchronous counterparts to void-returning synchronous functions can
still return promises. The promise would just resolve to undefined,
but it still fulfills the role of indicating when the operation is
complete.
Good point! Silly me.
The promises would only have a then method which would take in an
onsuccess and onerror callback. Both are optional. The onsuccess
function should take in a single parameter which matches the return
value of the synchronous counterpart. The onerror function should
take in an IDBDatabaseError. If the callbacks are null, undefined,
or omitted, they're ignored. If they're anything else, we should
probably either raise an exception immediately or ignore them.
Yes.
Any thoughts on whether we'd raise or ignore improper inputs? I'm leaning
towards raise since it would be deterministic and silently ignoring seems
like a headache from a developer standpoint.
If there's an error, all onerror callbacks would be called with the
IDBDatabaseError.
Yes.
Exceptions within callbacks would be ignored.
With CommonJS promises, the promise returned by the then() call goes
into an error state if a callback throws an exception. For example,
someAsyncOperation.then(successHandler, function(){ throw new
Error(test) })
.then(null, function(error){ console.log(error); });
Would log the thrown error, effectively giving you a way of catching
the error.
Are you suggesting this as a simplification so that IndexedDB impls
doesn't have to worry about recursive creation of promises? If so, I
suppose that seems like a reasonable simplification to me. Although if
promises are something that could be potentially reused in other
specs, it would be nice to have a quality solution, and I don't think
this is a big implementation burden, I've implemented the recursive
capabilities in dozen or two lines of JS code. But if burden is too
onerous, I am fine with the simplification.
When you say recursive capabilities are you just talking about how to
handle exceptions, or something more?
In terms of exceptions: I don't think it's an
enormous implementational burden and thus I think it's fine to ignore that
part of the equation. So the question mainly comes down to whether the
added complexity is worth it. Can you think of any real-world examples of
when this capability is useful in promises? If so, that'd definitely help
us understand the pro's and con's.
In terms of speccing, I'm not sure if we can get away with speccing
one promise interface or whether we'd need to create one for each
type of promise.
Certainly the intent of promises is that there is exists only one
generic promise interface that can be reused everywhere, at least from
the JS perspective, not sure if the extra type constraints in IDL
demand multiple interfaces to model promise's effectively
parameterized generic type form.
Unfortunately, I don't really know. Before we try speccing it, I'll
definitely see if any WebIDL experts have suggestions.
Also, do we want to explicitly spec what happens in the following case?
window.indexedDB.open(...).then(
function(db) { db.openObjectStore(a).then( function(os) {
alert(Opened a); } ) }
).then(
function(db) { alert(Second db opened); }
);
Clearly the first function(db) is called first. But the question is whether
it'd be a race of which alert is called first or whether the Second db
opened alert should always be shown first (since clearly if the first is
called, the second _can_ be fired immediately afterwards).
I'm on the fence about whether it'd be useful to spec that the entire chain
needs to be called one after the other before calling any other callbacks.
Does anyone have thoughts on whether this is useful or not? If we do spec
it to call the entire chain, then what happens if
Re: Information about latest specs for language tagging
Hi Art, Thanks for forwarding this. I've added PC with the new BCP47 reference. I've also removed the reference to the obsolete RFC 4647 (PC now links to RFC5646). Kind regards, Marcos On Mon, Mar 1, 2010 at 4:04 PM, Arthur Barstow art.bars...@nokia.com wrote: Editors, All - FYI, some information from the I18N group re normative reference for language tags. Begin forwarded message: From: ext Richard Ishida ish...@w3.org Date: March 1, 2010 9:53:20 AM EST Subject: Information about latest specs for language tagging It seems that a number of people are unaware of recent changes with regards to language tagging specifications. As it is important to use the right reference for spec development, I hope the following information will prove useful. You used to specify a language tag using RFC 1766, and then RFC 3066, both of which referred you to a list of ISO codes for language subtags and another ISO list for country names. RFC 3066 was replaced by two RFCs: 4646 (Tags for Identifying Languages) and 4647 (Matching of Language Tags). These two RFCs were concatenated at a single location under the name BCP 47. It is intended that BCP 47 will be an unchanging name with a single, unchanging URI that gives access to the most up-to-date RFCs as they are developed. This is particularly helpful since it is not clear from reading RFC the itself that it has been obsoleted. In September 2009, RFC 4646 was obsoleted by RFC 5646 (but RFC 4647 remains current). RFCs 5646 and 4647 are still referred to as BCP 47, and BCP 47 is accessed via the same URI as before. The latest specifications for language tagging allow a number of different types of subtag, over and above language and country/region, and point you to the IANA Language Subtag Registry (rather than ISO code lists) to find the (almost 8,000) subtags which are now available for use. Any language tags constructed using the obsoleted RFCs are still valid according to the syntax of the latest incarnation of BCP 47, though some tags are now deprecated. We recommend that you currently use the following reference for language tag syntax. [BCP47] Tags for Identifying Languages, A. Phillips and M. Davis, Editors, September 2009. Available at http://www.rfc-editor.org/rfc/bcp/bcp47.txt The following additional links may be useful for further reading: IANA Language Subtag Registry http://www.iana.org/assignments/language-subtag-registry Language tags in HTML and XML http://www.w3.org/International/articles/language-tags/ Choosing a Language Tag http://www.w3.org/International/questions/qa-choosing-language-tags Language Subtag Lookup tool http://rishida.net/utils/subtags/ If you have further questions about language tags, please contact the i18n WG. Hope that helps, RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/ -- Marcos Caceres http://datadriven.com.au
[widgets] Draft agenda for 4 March 2010 voice conf
Below is the draft agenda and logistics for the March 4 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/02/25-wam-minutes.html -Regards, Art Barstow = Agenda: 1. Review and tweak agenda 2. Announcements a. No call March 11; next call will be March 18 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ a. span and dir attribute proposal http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0715.html b. Status of Widget BiDI spec http://dev.w3.org/2006/waf/widgets-bidi/ 4. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Test suite status and plans 5. URI Scheme spec http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ a. Julian Reschke's 25-Feb comment: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0713.html 6. AOB a. Next and last call in March is March 18 (no calls on March 11 or 25) b. Heads-up: time for March 18 will be the same in US but 1 hour earlier in Europe (14:00 Paris) = Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/ member-bin/irc/irc.cgi Confidentiality of minutes: Public
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Wed, Mar 3, 2010 at 11:01 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/1/2010 2:52 PM, Jeremy Orlow wrote:
Thanks for the pointers. I'm actually pretty sold on the general
idea of promises, and my intuition is that there won't be a very
big resource penalty for using an API like this rather than
callbacks or what's currently specced. At the same time, it seems
as though there isn't much of a standard in terms of the precise
semantics and some of the techniques (such as optionally taking
callbacks and not returning a promise if they are supplied) seems
like a decent answer for pure javascript APIs, but maybe not as
good for IDL and a standard like this.
Do you guys have any recommendations for the precise semantics we'd
use, if we used promises in IndexedDB? To get started, let me list
what I'd propose and maybe you can offer counter proposals or
feedback on what would or wouldn't work?
Each method on a Request interface (the async ones in the spec)
whose counterpart returns something other than void would instead
return a Promise.
Asynchronous counterparts to void-returning synchronous functions can
still return promises. The promise would just resolve to undefined,
but it still fulfills the role of indicating when the operation is
complete.
Good point! Silly me.
The promises would only have a then method which would take in an
onsuccess and onerror callback. Both are optional. The onsuccess
function should take in a single parameter which matches the return
value of the synchronous counterpart. The onerror function should
take in an IDBDatabaseError. If the callbacks are null, undefined,
or omitted, they're ignored. If they're anything else, we should
probably either raise an exception immediately or ignore them.
Yes.
Any thoughts on whether we'd raise or ignore improper inputs? I'm leaning
towards raise since it would be deterministic and silently ignoring seems
like a headache from a developer standpoint.
If there's an error, all onerror callbacks would be called with the
IDBDatabaseError.
Yes.
Exceptions within callbacks would be ignored.
With CommonJS promises, the promise returned by the then() call goes
into an error state if a callback throws an exception. For example,
someAsyncOperation.then(successHandler, function(){ throw new
Error(test) })
.then(null, function(error){ console.log(error); });
Would log the thrown error, effectively giving you a way of catching
the error.
Are you suggesting this as a simplification so that IndexedDB impls
doesn't have to worry about recursive creation of promises? If so, I
suppose that seems like a reasonable simplification to me. Although if
promises are something that could be potentially reused in other
specs, it would be nice to have a quality solution, and I don't think
this is a big implementation burden, I've implemented the recursive
capabilities in dozen or two lines of JS code. But if burden is too
onerous, I am fine with the simplification.
When you say recursive capabilities are you just talking about how to
handle exceptions, or something more?
In terms of exceptions: I don't think it's an
enormous implementational burden and thus I think it's fine to ignore that
part of the equation. So the question mainly comes down to whether the
added complexity is worth it. Can you think of any real-world examples of
when this capability is useful in promises? If so, that'd definitely help
us understand the pro's and con's.
I've been talking to a co-worker here who seems to know a decent amount
about promises (as implemented in E) and some about differed (as implemented
in Python's Twisted library). From talking to him, it seems that my
original suggestion for not handling exceptions thrown inside a .then()
callback is the way to go.
It seems as though promises put a lot of weight on composability and making
it so that the order of .then() calls not mattering. This means that you
can then pass promises to other async interfaces and not have to worry about
different timings leading to different results. It also means that if you
pass a promise into multiple consumers (say, javascript libraries) you don't
need to worry about one using a promise in a way that screws up another.
Differed seems to be more expressive and flexible. For example, instead of
doing this:
window.indexedDB.open(...).then(
function(db) { db.openObjectStore(a).then(
function(os) { os.get(x).then(
function(value) { alert(Value: + value); }
) }
) }
);
I could do this:
window.indexedDB.open(...).then(
function(db) { return db.openObjectStore(a); }// Note the return
value is passed on to the next step.
).then(
function(os) { return os.get(x); }
).then(
function(value) {
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
Erm... s/differed/deferred/g
On Wed, Mar 3, 2010 at 4:58 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Mar 3, 2010 at 11:01 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/1/2010 2:52 PM, Jeremy Orlow wrote:
Thanks for the pointers. I'm actually pretty sold on the general
idea of promises, and my intuition is that there won't be a very
big resource penalty for using an API like this rather than
callbacks or what's currently specced. At the same time, it seems
as though there isn't much of a standard in terms of the precise
semantics and some of the techniques (such as optionally taking
callbacks and not returning a promise if they are supplied) seems
like a decent answer for pure javascript APIs, but maybe not as
good for IDL and a standard like this.
Do you guys have any recommendations for the precise semantics we'd
use, if we used promises in IndexedDB? To get started, let me list
what I'd propose and maybe you can offer counter proposals or
feedback on what would or wouldn't work?
Each method on a Request interface (the async ones in the spec)
whose counterpart returns something other than void would instead
return a Promise.
Asynchronous counterparts to void-returning synchronous functions can
still return promises. The promise would just resolve to undefined,
but it still fulfills the role of indicating when the operation is
complete.
Good point! Silly me.
The promises would only have a then method which would take in an
onsuccess and onerror callback. Both are optional. The onsuccess
function should take in a single parameter which matches the return
value of the synchronous counterpart. The onerror function should
take in an IDBDatabaseError. If the callbacks are null, undefined,
or omitted, they're ignored. If they're anything else, we should
probably either raise an exception immediately or ignore them.
Yes.
Any thoughts on whether we'd raise or ignore improper inputs? I'm leaning
towards raise since it would be deterministic and silently ignoring seems
like a headache from a developer standpoint.
If there's an error, all onerror callbacks would be called with the
IDBDatabaseError.
Yes.
Exceptions within callbacks would be ignored.
With CommonJS promises, the promise returned by the then() call goes
into an error state if a callback throws an exception. For example,
someAsyncOperation.then(successHandler, function(){ throw new
Error(test) })
.then(null, function(error){ console.log(error); });
Would log the thrown error, effectively giving you a way of catching
the error.
Are you suggesting this as a simplification so that IndexedDB impls
doesn't have to worry about recursive creation of promises? If so, I
suppose that seems like a reasonable simplification to me. Although if
promises are something that could be potentially reused in other
specs, it would be nice to have a quality solution, and I don't think
this is a big implementation burden, I've implemented the recursive
capabilities in dozen or two lines of JS code. But if burden is too
onerous, I am fine with the simplification.
When you say recursive capabilities are you just talking about how to
handle exceptions, or something more?
In terms of exceptions: I don't think it's an
enormous implementational burden and thus I think it's fine to ignore that
part of the equation. So the question mainly comes down to whether the
added complexity is worth it. Can you think of any real-world examples of
when this capability is useful in promises? If so, that'd definitely help
us understand the pro's and con's.
I've been talking to a co-worker here who seems to know a decent amount
about promises (as implemented in E) and some about differed (as implemented
in Python's Twisted library). From talking to him, it seems that my
original suggestion for not handling exceptions thrown inside a .then()
callback is the way to go.
It seems as though promises put a lot of weight on composability and making
it so that the order of .then() calls not mattering. This means that you
can then pass promises to other async interfaces and not have to worry about
different timings leading to different results. It also means that if you
pass a promise into multiple consumers (say, javascript libraries) you don't
need to worry about one using a promise in a way that screws up another.
Differed seems to be more expressive and flexible. For example, instead of
doing this:
window.indexedDB.open(...).then(
function(db) { db.openObjectStore(a).then(
function(os) { os.get(x).then(
function(value) { alert(Value: + value); }
) }
) }
);
I could do this:
window.indexedDB.open(...).then(
function(db) { return db.openObjectStore(a); }// Note
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/3/2010 4:01 AM, Jeremy Orlow wrote:
On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com
mailto:k...@sitepen.com wrote:
[snip]
The promises would only have a
then method which would take in an
onsuccess and onerror callback. Both are optional. The
onsuccess
function should take in a single parameter which matches the
return
value of the synchronous counterpart. The onerror function
should
take in an IDBDatabaseError. If the callbacks are null,
undefined,
or omitted, they're ignored. If they're anything else, we should
probably either raise an exception immediately or ignore them.
Yes.
Any thoughts on whether we'd raise or ignore improper inputs? I'm
leaning towards raise since it would be deterministic and silently
ignoring seems like a headache from a developer standpoint.
Throwing an error on improper inputs is fine with me.
If there's an error, all onerror
callbacks would be called with the
IDBDatabaseError.
Yes.
Exceptions within callbacks
would be ignored.
With CommonJS promises, the promise returned by the then() call goes
into an error state if a callback throws an exception. For example,
someAsyncOperation.then(successHandler, function(){ throw new
Error(test) })
.then(null, function(error){ console.log(error); });
Would log the thrown error, effectively giving you a way of catching
the error.
Are you suggesting this as a simplification so that IndexedDB impls
doesn't have to worry about recursive creation of promises? If so, I
suppose that seems like a reasonable simplification to me.
Although if
promises are something that could be potentially reused in other
specs, it would be nice to have a quality solution, and I don't
think
this is a big implementation burden, I've implemented the recursive
capabilities in dozen or two lines of JS code. But if burden is too
onerous, I am fine with the simplification.
When you say recursive capabilities are you just talking about how
to handle exceptions, or something more?
In terms of exceptions: I don't think it's an
enormous implementational burden and thus I think it's fine to
ignore that part of the equation. So the question mainly comes down
to whether the added complexity is worth it. Can you think of any
real-world examples of when this capability is useful in promises?
If so, that'd definitely help us understand the pro's and con's.
Maybe I misunderstanding your suggestion. By recursive capability I
meant having then() return a promise (that is fulfilled with the
result of executing the callback), and I thought you were suggesting
that instead, then() would not return a promise. If then() returns a
promise, I think the returned promise should clearly go into an error
state if the callback throws an error. The goal of promises is to
asynchronously model computations, and if a computation throws, it
should result in the associated promise entering error state. The
promise returned by then() exists to represent the result of the
execution of the callback, and so it should resolve to the value
returned by the callback or an error if the callback throws. Silenty
swallowing errors seems highly undesirable.
Now if we are simplifying then() to not return a promise at all, than
I would think callbacks would just behave like any other event
listener in regards to uncaught errors.
In terms of speccing, I'm not sure if we can get away with
speccing
one promise interface or whether we'd need to create one for each
type of promise.
Certainly the intent of promises is that there is exists only one
generic promise interface that can be reused everywhere, at
least from
the JS perspective, not sure if the extra type constraints in IDL
demand multiple interfaces to model promise's effectively
parameterized generic type form.
Unfortunately, I don't really know. Before we try speccing it, I'll
definitely see if any WebIDL experts have suggestions.
Also, do we want to explicitly spec what happens in the following case?
window.indexedDB.open(...).then(
function(db) { db.openObjectStore(a).then( function(os) {
alert(Opened a); } ) }
).then(
function(db) { alert(Second db opened); }
);
Clearly the first function(db) is called first. But the question is
whether it'd be a race of which alert is called first or whether the
Second db opened alert should always be shown first (since clearly
if the first is called, the second _can_ be fired immediately
afterwards).
I'm on the fence about whether it'd be useful to spec that the
entire chain needs to be called one after the other before calling
any other callbacks. Does anyone have thoughts on whether this is
useful or not? If we do spec it
