Re: [whatwg] Missing HTMLSelectElement.autocomplete
On Wed, Jun 4, 2014 at 7:16 PM, Ian Hickson wrote: > On Wed, 4 Jun 2014, Matthew Noorenberghe wrote: >> >> Is it intentional that there is no HTMLSelectElement.autocomplete IDL >> attribute? Both and have it so there is currently >> inconsistency. > > Woops. Totally an oversight on my part. When I added autocomplete to > select recently, I forgot to fix that. > > Fixed. Thanks. > > > On Wed, 4 Jun 2014, Luis Farzati wrote: >> >> I would like to insist on the datalist proposition I posted on this list >> (didn't caught any interest, though). >> >> A datalist for select would enable to have the contents of a select >> defined externally, and would also enable the reuse of this data. >> >> I don't see why datalist can be applied to an input and not to a select. > > Don't worry, your e-mail is in the queue! Requests for features tend to > take a bit longer for me to deal with than simple bug reports, though. > > > On Wed, 4 Jun 2014, Dan Beam wrote: >> >> It'd be nice to avoid more attribute accessors (and encourage authors to >> use getAttribute() instead), but if and have them we >> should probably be consistent. > > Can you elaborate on the cost of attribute accessors? Namespace exhaustion (maybe form.autocomplete() would've worked instead of requestAutocomplete() if autocomplete="" hadn't taken it?), multiple ways to do things (vs getAttribute), longer specs/IDLs/compile times. -- Dan Beam db...@chromium.org > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Missing HTMLSelectElement.autocomplete
On Wed, Jun 4, 2014 at 6:13 PM, Matthew Noorenberghe wrote: > Hello, > > Is it intentional that there is no HTMLSelectElement.autocomplete IDL > attribute[1]? Both [2] and [3] have it so there is currently > inconsistency. I discovered the same issue while working on Autofill/requestAutocomplete in Chrome and Ian Hickson mentioned it was likely just an oversight. Autofill in Chrome didn't always work [well] with tags, so I could see how Autofill-related stuff like [autocomplete] could be out of date. It'd be nice to avoid more attribute accessors (and encourage authors to use getAttribute() instead), but if and have them we should probably be consistent. -- Dan Beam db...@chromium.org > > Thanks, > Matthew Noorenberghe > > [1] http://www.whatwg.org/specs/web-apps/current-work/#the-select-element > [2] http://www.whatwg.org/specs/web-apps/current-work/#the-input-element > [3] http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element
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 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 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": } 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
[whatwg] Proposal: HTMLFormElement#requestAutocomplete() should return a Promise
Hey whatwg@,
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:
form.requestAutocomplete().then(function() {
// form.submit() or some other success action
}, function(errorDetails) {
// handle error based on errorDetails.reason (e.g. "cancel")
});
The returned promise would be resolved after the corresponding
"autocomplete" or "autocompleteerror" event is dispatched on the form.
Null would be passed on fulfillment* and
{"reason": }
would be passed on rejection.
There should be little compatibility risk as requestAutocomplete()
currently returns undefined.
Thoughts? Concerns? Questions?
--
Dan Beam
db...@chromium.org
* until I think of something useful for the success case...
[1]
http://www.whatwg.org/specs/web-apps/current-work/#dom-form-requestautocomplete
[2]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/0TnqLOvC2ZY
[3]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/aqKcZkCMsUI
[whatwg] Supporting more address levels in autocomplete
While internationalizing Chrome’s implementation of requestAutocomplete(), we found that Chinese, Korean, and Thai addresses commonly ask for [at least] 3 levels of administrative region. For example, in this Chinese address: Humble Administrator’s Garden n°178 Dongbei Street, Gusu, Suzhou 215001 Jiangsu China the first-level address component is “Jiangsu” (province) as it’s the first level below country, “Suzhou” is a prefecture level city (below province), and “Gusu” is a district of Suzhou. To support this address format and arbitrarily many administrative levels, we propose adding new tokens to the autocomplete spec: address-level-n, for arbitrary n. In the above example, Jiangsu would slot into address-level-1, Suzhou address-level-2, and Gusu address-level-3. There would be no value returned for address-level-4. In some other cases, address-level-1 might be a province-level city (like Beijing), and address-level-3 might be a county-level division. Thus we think the least confusing way to handle addresses in this type of system is with generic indexing. See [1] for more on Chinese addresses. The current HTML spec supports “region” and “locality”. We feel these should remain in the spec, as they are still useful for typical Western addresses. In a typical Western address, address-level-1 would align with “region” and address-level-2 would align with “locality”. Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. Questions, concerns, or feedback? -- Dan Beam Evan Stade [1] http://en.wikipedia.org/wiki/Administrative_divisions_of_China
Re: [whatwg] asynchronous JSON.parse
On Thu, Mar 7, 2013 at 2:18 PM, David Rajchenbach-Teller <
dtel...@mozilla.com> wrote:
> (Note: New on this list, please be gentle if I'm debating an
> inappropriate issue in an inappropriate place.)
>
> Actually, communicating large JSON objects between threads may cause
> performance issues. I do not have the means to measure reception speed
> simply (which would be used to implement asynchronous JSON.parse), but
> it is easy to measure main thread blocks caused by sending (which would
> be used to implement asynchronous JSON.stringify).
>
Isn't this precisely what Transferable objects are for?
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects
--
Dan Beam
db...@chromium.org
> I have put together a small test here - warning, this may kill your
> browser:
>http://yoric.github.com/Bugzilla-832664/
>
> While there are considerable fluctuations, even inside one browser, on
> my system, I witness janks that last 300ms to 3s.
>
> Consequently, I am convinced that we need asynchronous variants of
> JSON.{parse, stringify}.
>
> Best regards,
> David
>
> > Glenn Maynard wrote
> >
> > (It's hard to talk to somebody called "j", by the way. :)
> >
> > On Thu, Mar 7, 2013 at 2:06 AM, wrote:
> >
> >> right now JSON.parse blocks the mainloop, this gets more and more of an
> >> issue as JSON documents get bigger
> >
> >
> > Just load the data you want to parse inside a worker, and perform the
> > parsing there. Computationally-expensive work is exactly something Web
> > Workers are meant for.
> >
> > and are also used as serialization
> >> format to communicate with web workers.
> >>
> >
> > There's no need to serialize to JSON before sending data to a worker;
> > there's nothing that JSON can represent that postMessage can't post
> > directly. Just postMessage the object itself.
>
>
> --
> David Rajchenbach-Teller, PhD
> Performance Team, Mozilla
>
>
>
>
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Wed, Nov 21, 2012 at 3:55 PM, Ilya Sherman wrote:
> On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson wrote:
>
>> On Tue, 16 Oct 2012, Ilya Sherman wrote:
>> > The payment instrument type is almost certainly appropriate to add -- it
>> > is included on almost every website that I've encountered that includes
>> > payment card fields. It was an oversight on my part to omit it from the
>> > initial proposal.
>>
>> It's redundant data, the credit card number itself says what type it is.
>>
>> More importantly, I don't know how to store the information. What values
>> should we be expecting here? If a site has radio buttons "v", "m" and "a",
>> and another has a with "4", "5", and "3", and yet another has
>> three buttons which set a type=hidden with the values "visa", "mastercard"
>> and "amex", how is the user agent to figure out what's going on? This
>> makes the magic needed around dates look positively easy.
>>
>
> I agree that it's redundant data, but many websites ask for it separately
> anyway. One common reason for this is that the website only supports a
> subset of all possible credit card issuers -- for example, many do not
> support DiscoverCard. While the site *could* theoretically infer from the
> entered card number that the card is not supported, and show the user an
> error, most sites instead force the user to select the card type, and
> inform the user of unsupported card types by omitting them from the list.
>
> Regarding storing of the data: I think being able to fill the data is more
> important than being able to store it. For example, Chrome stores just the
> card number, and not the type; but Chrome supports filling the type by
> inferring it from the stored card number. For filling the card type, I
> think it's strictly easier than filling a dropdown containing
> country names, since localization issues don't come into play as much. The
> user agent is presumably not going to be able to handle *every* case; but
> in my experience, it's not too hard to handle many/most of the real-world
> cases. Since this attribute is used just as a hint, esoteric difficult
> cases don't seem like enough reason to omit the card type as a known token
> in the spec.
>
>
>> > Finally, I have gotten a request to include a field type for bank
>> > account numbers, though I have only seen this info actually requested on
>> > a small handful of extremely prominent (and generally trusted) websites:
>> > Amazon, PayPal, and I think Google Wallet.
>>
>> Is there any reason we shouldn't just treat bank accounts like just
>> another credit card, and use cc-number for these?
>>
>
> Yes: Most websites that support credit card numbers as inputs do not
> support bank account numbers. The few websites that do support bank
> account numbers use separate fields for these vs. credit card number
> inputs. Labeling both fields identically would leave the browser unable to
> distinguish which field to fill with what info.
>
>
>> On Wed, 31 Oct 2012, Dan Beam wrote:
>> >
>> > The experimental implementation [1] has been updated to dispatch an
>> > "autocompleteerror" as per convention/your feedback.
>>
>> "autocompleteerror" seems like it'd be fired for an error, not user
>> cancelation. User cancelation is usually called either "abort" or
>> "cancel". I think autocompletecancel is fine. It's consistent with
>> oncancel, which we used for . (Fullscreen's "error" event is for a
>> slightly different case, based on what the spec says.)
>>
>
> There are also cases where we'd want to return actual errors. For example,
> in Chrome, we are only planning to support this dialog for sites served
> over HTTPS and without security errors. We might also want to fire an
> error in case the input fails to pass the form's validation requirements.
> Should we use autocompleteerror for the errors, and autocompletecancel for
> user cancelations? Firing separate events for cancelations vs. errors
> forces developers to check for each of these cases separately, which seems
> like a less convenient API than just checking for one sort of failure
> event. Perhaps we should have a single event named something like
> autocompletefail or something like that?
I don't particularly care about the naming (fail vs. error), I just
knew we had a pre-existing *error event and agreed with Anne that I
might as well go with the convention (of 1). I can change it quite
easily to whatever the consensus is.
I definitely agree to a single event. It would be great to do this
and give enumerable failure reasons (if this is deemed secure enough).
An example:
enum ErrorCause {
FROM_FRAME,
NEEDS_GESTURE,
NOT_SECURE,
};
This could be a property on the event (event.cause, event.reason?)
argument passed to the error event (kind of like DOM exceptions).
This seems akin to event.property in CSS transition end events (and
disputably many other examples).
Re: [whatwg] Improving autocomplete
On Fri, Oct 26, 2012 at 12:43 AM, Anne van Kesteren wrote: > On Fri, Oct 26, 2012 at 9:24 AM, Elliott Sprehn wrote: >> [...] > > I'm missing the scenario that requires such interference from a web > developer. Can't a UA just offer to autocomplete a form for me once it > finds one? (Or in other words, unless I'm missing something this seems > like a solution without a provided use case.) One great example use case is payments on the web. A user agent has greater knowledge of a user than a web site does and is more trusted. With a small amount of code, web developers can implement an improved checkout flow: Buy a frobber now! With the addition of an imperative API, site authors can request a UI from the browser for secure and simple data input and more efficiently and effectively harness autofill data. On Fri, Oct 26, 2012 at 3:09 AM, Anne van Kesteren wrote: > On Fri, Oct 26, 2012 at 10:01 AM, Adam Barth wrote: >> When should the UA offer to fill in the form (e.g., to select which >> address they would like to use for shipping this particular order)? > > Presumably on page load. There are quite a few use cases we've thought of so far that would not be possible if triggering this UI is uncontrollable by site authors. Some examples: - dynamically changing s based on user input (i.e. showing a list of regions after a country has been chosen). Extra/unwanted info may show if the UI is only invoked on load. Also, third-party widgets/scripts that create “Buy now” buttons that’d want to use this new UI could insert hidden forms into the DOM dynamically after page load. - with more than 1 form on the page (think login + registration + payment) it'd be hard to accurately know which one to autocomplete on load. - [hidden] forms triggering this UI on page load would probably be unexpected, though some websites may want this behavior. Letting the author decide rather than relying on heuristics is much simpler to implement and can be right 100% of the time. An imperative API gives site authors the greatest amount of control over when and what should be interactively autocompleted. I think we’ll be unable to accommodate all use cases if we prescribe when this UI should be invoked. >> In particular, Elliott wrote: >> >>> Authors can also display >>> no forms at all to users of a browser who implements this proposal for >>> one click checkout experiences which are important on mobile devices. > > I guess in that case it would be nice to know the user agent actually > did display some UI. > > Are we using "cancel" elsewhere by the way? Fullscreen uses "error" as > suffix for the event type. The experimental implementation [1] has been updated to dispatch an "autocompleteerror" as per convention/your feedback. Dan Beam db...@chromium.org [1] http://bugs.webkit.org/show_bug.cgi?id=100557
