Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contact Picker API #153

Closed
dbaron opened this issue Apr 24, 2019 · 7 comments · Fixed by #266
Closed

Contact Picker API #153

dbaron opened this issue Apr 24, 2019 · 7 comments · Fixed by #266
Labels

Comments

@dbaron
Copy link
Member

@dbaron dbaron commented Apr 24, 2019

Request for Mozilla Position on an Emerging Web Specification

This is something Google is working on that it would be useful for us to provide input on.

@dbaron dbaron added the wicg label Apr 24, 2019
@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

@marcoscaceres marcoscaceres commented Apr 25, 2019

Safari's solution to this on Desktop is more elegant, IMO. You can still use good old HTML inputs with autocomplete, it requires user gesture, and safari gives you the ability to fill from a contact (even if it's just your own personal details).. and no API needed.

Screenshot 2019-04-25 11 02 42

UPDATE: The above could be expanded to allow selecting a different contact ("Choose from contacts..."), but again, without requiring an API.

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

@marcoscaceres marcoscaceres commented Apr 30, 2019

Example code:

<input type="tel" name="home-phone" autocomplete="home tel">
<input type="email" name="home-email" autocomplete="home email">

Live example to try in Safari:
https://jsfiddle.net/mdtybcuq/

More extensive examples here:
https://cloudfour.com/thinks/autofill-what-web-devs-should-know-but-dont/

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

@marcoscaceres marcoscaceres commented Aug 5, 2019

Had a further look at the contacts API... it does provide some good privacy qualities in that it's a single-use, user-gated, proposal that would work similarly to the file picker. It also protects from oversharing by requiring the author to request what they need up-front (e.g., I need `["name", "phone"]... though these names could probably better align with HTML autocomplete).

@rayankans

This comment has been minimized.

Copy link

@rayankans rayankans commented Oct 1, 2019

@marcoscaceres Given the progress made on the issue you filed and the discussions we had, do you have any more concerns regarding the API? If not, do you mind updating this issue?

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator

@marcoscaceres marcoscaceres commented Oct 1, 2019

I personally don't have any further concern. I wonder if the folks that were originally tagged (@annevk and @tantek) might want to provide additional feedback before we take a position.

@tantek

This comment has been minimized.

Copy link
Member

@tantek tantek commented Feb 6, 2020

I read and re-checked the Explainer, and frankly given the repeated past
Contacts API failures and zero mention of them in the Explainer, I’m going to deem this proposal not worth taking the time to thoroughly evaluate until the Explainer at a minimum:

  1. Documents previous Contacts API standards attempts (see https://tantek.com/2020/026/t2/ for some links to start)
  2. Provides summary explanations for their failures
  3. Describes how the current proposal is different from previous proposals in such a way as to at least avoid those failures (i.e. there should be a logical chain of reasoning from identifying key differences and how those either cause or prevent different outcomes from prior attempts).

I think we should go ahead and publish a position of "defer", since a similar request to number 3 was made a whole year ago (w3ctag/design-reviews#337 (comment)) without any subsequent respective additions to the Explainer.

Also given the critical comments in that discussion, especially from https://github.com/torgo, and knowing how much more abusive social network/media "apps" have become with aggressive sign-up, spam, user-acquisition tactics in recent years, I’m leaning towards expecting an eventual "harmful" evaluation.

If the purely markup-only approaches were separated out into another proposal, I’d be more optimistic of more quickly evaluating those, and expecting browsers could implement those simpler (fewer ways to use/abuse) feature(s) in such a way that could be "worth prototyping".

(Originally published at: https://tantek.com/2020/037/t1/)

@tomayac

This comment has been minimized.

Copy link

@tomayac tomayac commented Feb 6, 2020

There’s a PR open that mentions the previous attempts and describes how the current attempt is different.

tantek added a commit to tantek/standards-positions-1 that referenced this issue Feb 8, 2020
Closes mozilla#153.
@dbaron dbaron closed this in #266 Feb 13, 2020
dbaron pushed a commit that referenced this issue Feb 13, 2020
Closes #153.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants
You can’t perform that action at this time.