-
Notifications
You must be signed in to change notification settings - Fork 8
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
Closer HTML alignment #21
Comments
I like this idea. How would you see it working with selecting multiple contacts, for instance? Would you see it being a repeated |
I like the idea of re-using autocomplete names, we might have to do something about icons though. @marcoscaceres, I'm assuming you mean returning a list of On the other hand, if you goal is to display them in a form before uploading it would be pretty easy to create a form with repeated |
No, was thinking just one
Perhaps. I wonder how clunky would it be to use a single FormData object, given that it supports multiple keys? |
I'd imagine the FormData would look something like this, since we'd have to namespace which contact that field belongs to, and the value has to be a string or a blob: const formData = await navigator.contacts.select(['name', 'email'], {multiple: true});
print(formData);
// c1.name => 'Rayan'
// c1.name => 'rayankans'
// c2.name => 'marcoscaceres'
// c2.email => 'marcos@marcosc.com' Getting field values would work nicely, even for missing / unshared fields: formData.getAll('c1.name'); // ['Rayan', 'rayankans']
formData.getAll('c1.email'); // [] But getting the number of contacts is a bit awkward (unless explicitly passed over as well). new Set([...formData.keys()].map(k => k.split('.')[0])).size; // 2 I personally find the data in this format hard to interact with, specifically the contact namespacing. One entry per contact in a list is easier to reason about, and easier to transform into any other format. |
Without going down a rathole (that I started, sorry! :)), I don't think you need the namespace:
I guess ultimately what I'm trying to get to with the I know I'm telling you things you all already know, but the primary use cases would appear to be:
I think I saw you opted to use a dictionary instead of an interface, but I'm imagining something cute like:
Or:
anyway, these are all half-baked ideas... but wanted to plant a few seeds. |
I don't think that's true, in the example I constructed I really like switching the |
I was thinking one ContactInfo per contact too, and then we could maybe have a static method: ContactInfo.toFormData(...contacts); Which merges them into a single FormData that one could later POST. |
Alright, so putting everything together, this is the new proposed structure: interface ContactInfo {
sequence<DOMString> name;
sequence<DOMString> email;
sequence<DOMString> tel;
[default] object toJSON();
static FormData toFormData(sequence<ContactInfo> contacts);
}; The chosen field names happen to already match the autocomplete names. I still have a few concerns regarding |
Re: FormData, I'm ok with the above. I'm not sure about the sequences:
I'd suggest just a single value for each. Otherwise it can get a bit crazy because it will inconsistent across UAs what returned order means.... also, from our experience with Payment Request, mapping to NSPersonComponent is hard. If we want alternative names or whatever, then we should add fields for that (again matching what autocomplete in HTML does). And geessss... I eventually want:
But getting ahead of myself :) |
From the peanut gallery: most address books support multiple values for most fields, and looking at my own contact list this applies to many individuals. How would we represent that data w/o sequences? |
I was thinking about the same thing today while looking at both Contacts.app and the HTML spec. Let’s take phone number as a case: in iOS’s contacts, you can have home, work, mobile, main, iPhone, and so on. The current tel sequence obviously can’t distinguish between them. I think this why we need something MapLike that works similarly to HTML autocomplete.... and why I instinctively reached for FormData (even though it was admittedly the wrong choice!).... but I still think we need something that can capture and distinguish between “home tel” and “work tel”. Again, take a look at how elegantly HTML autocomplete is able to declaratively extract the right information. We need something similar, and as fine grained. |
In #12 (comment) I pointed to the vCard standard. |
Just noting the case in #12 is covered by payment request api (heh, I’m totally not biased! 😂)... but Tom’s right about the scope of the problem - and I imagine none of us want to parse vCard or give developers back vCard data 🤢. I feel like the right solution is within our grasp tho. |
It’s an agreed-on standard and parsing seems like a solved problem, but I see your point… |
I can see why the API should be closely aligned to the HTML standard but not sure if FormData is the right API for this to follow. Is there any reason why the assumption is for these contacts to be only interoperable with HTML forms? I would imagine implementors may want to do something with the data other than submit it through a form. |
Apart from displaying it and POSTing it, what else are you envisioning? I guess “sharing” using web share would be pretty useful. Anything else? |
Random thought... I wonder if
ContactProperty
should actually reflect the list of HTML autocomplete names... and, instead of returning aContactInfo
dictionary, the API just returnedFormData
?That might be nice, because then you can just POST contacts directly (or use the FormData API to query what you got back). That also works nicely if the API is not available, because then the developer would just fall back to a HTML form.
The text was updated successfully, but these errors were encountered: