Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
On Wed, Apr 16, 2014 at 6:59 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: db...@google.com [mailto:db...@google.com] On Behalf Of Dan Beam
So just pass no argument at all (i.e. arguments.length == 0)? I was
under the impression some type of value should always be returned (but I'm
biased by blink/v8's current implementation).
It's equivalent, both for promises and for return values of functions.
Both `new Promise(resolve = resolve())` and `new Promise(resolve =
resolve(undefined))` give a promise whose fulfillment value is
`undefined`. In this sense `resolve` behaves like all non-evil JavaScript
functions, where evil is defined as checking `arguments.length` ;)
I've seen only positive feedback on this thread, so I've started
implementing in Blink.
Regarding the rejection argument: requestAutocomplete() can fail in a way
that doesn't map intuitively to the current DOMException names (e.g. the
invoking form has autocomplete=off or isn't in a frame). Adding new
names for these specific failure categories doesn't seem useful to the
platform. Additionally, many potential failure causes may have the same
reason property[1] (disabled = SecurityError, WrongDocumentError?,
InvalidAccessError?)** and the terminology differs slightly (cancel =
AbortError).
This seems confusing to web authors, so I propose a new type instead (in
IDL):
interface AutocompleteError : DOMException {
readonly attribute DOMString reason; // matches
AutocompleteErrorEvent's reason[1]
};
This new type would have a code of 0 (as other new exceptions have; code is
deprecated). I've filed a bug to add this to the DOMException name
table[2].
--
Dan Beam
db...@chomium.org
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#the-autocompleteerrorevent-interface
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25457
** names with ? are the closest existing error names I could find (but
aren’t great)
Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
On 4/25/14, 12:06 AM, Dan Beam wrote:
interface AutocompleteError : DOMException {
DOMException isn't an interface as currently proposed.
In general, please check with public-script-coord before minting new
exception types; there's been a lot of discussion on that issue recently.
-Boris
Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
From: db...@google.com [mailto:db...@google.com] On Behalf Of Dan Beam So just pass no argument at all (i.e. arguments.length == 0)? I was under the impression some type of value should always be returned (but I'm biased by blink/v8's current implementation). It's equivalent, both for promises and for return values of functions. Both `new Promise(resolve = resolve())` and `new Promise(resolve = resolve(undefined))` give a promise whose fulfillment value is `undefined`. In this sense `resolve` behaves like all non-evil JavaScript functions, where evil is defined as checking `arguments.length` ;)
Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
On Mon, Apr 14, 2014 at 9:44 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: whatwg-boun...@lists.whatwg.org [mailto:
whatwg-boun...@lists.whatwg.org] On Behalf Of Dan Beam
I propose requestAutocomplete()[1] should return a Promise. This has
been requested since the creation of this API[2][3] and seems like a
natural fit. Web authors can then call requestAutocomplete() like this:
I strongly support this.
Null would be passed on fulfillment* and
`undefined` would be better, as that is what normal JavaScript functions
return when they have nothing to return.
So just pass no argument at all (i.e. arguments.length == 0)? I was under
the impression some type of value should always be returned (but I'm biased
by blink/v8's current implementation).
{reason: matching AutocompleteErrorEvent#reason} would be passed
on rejection.
Rejection reasons should always be instanceof Error:
https://github.com/w3ctag/promises-guide#rejection-reasons-should-be-errors
Great, will figure out a way to subclass Error to provide some type of
reason property on the rejection argument.
--
Dan Beam
db...@chromium.org
Re: [whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Dan Beam
I propose requestAutocomplete()[1] should return a Promise. This has been
requested since the creation of this API[2][3] and seems like a natural fit.
Web authors can then call requestAutocomplete() like this:
I strongly support this.
Null would be passed on fulfillment* and
`undefined` would be better, as that is what normal JavaScript functions return
when they have nothing to return.
{reason: matching AutocompleteErrorEvent#reason} would be passed on
rejection.
Rejection reasons should always be instanceof Error:
https://github.com/w3ctag/promises-guide#rejection-reasons-should-be-errors
