[webkit-dev] Adding ENABLE_CONTACTS to WebCore

[Robin Berjon]

Hi all,

sorry for not jumping into this thread earlier. I'll try to summarise my opinions succinctly in order to avoid extra noise.

On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai wrote:
> Is there a document that lists the use-cases for this API? I couldn't find
> anything from a quick glance through the DAP working group's mailing list
> archive. A list of use-cases would help evaluate whether this is the best
> API. At first glance, it strikes me that something like <input
> type=contacts> would meet the uses-cases I can think of better.


Unfortunately there is no formal use cases document, rather they were discussed as the API was developed (it has changed a lot since the first input was made available). In general this API shines compared to the available input types when you need either multiple people at once and/or multiple fields from given contacts. If you want to email 50 people, you're better off selecting them in a contacts picker than typing them in, even assuming friendly completion from <input type=email> (note that since the contacts picker that the API expects can be platform-provided, existing structure you may have in your contacts DB such as groups can be used directly). Likewise if you need to enter email and snail addresses for someone, you're better off picking that person once rather than having to select them multiple times with a completion helper (or typing everything in, of course).

Based on this we can see use cases such as:

    • Send printed invites to a whole bunch of people to a party/wedding/whatever, needing full name and address.
    • Set up a Web VoIP conference and invite people over email.
    • Load a bunch of friends and get a map of which locations in town are closest to all (as in http://old.isokron.com/ but with more than two people).

That's just what's at the top of my head tonight, but I think it gives an idea.

As for <input type=contacts>, it's something that was considered but it's less straightforward than one would hope as there are several aspects to consider. The first is that it would need to expose an <input type=contacts>.contacts API in the same way as <input type=file>.files does. That's pretty simple — in fact that API is 90% of what's in the Contacts API.

But then it needs to contribute to form submission. They idea of just attaching a vCard as a file for each contact was floated but it feels like a cop out. It also requires browsers to correctly generate vCard content (since even if they had access to the raw vCard they'd need to keep only the relevant fields). It's not the end of the world but, as usual, there are kinks. Another option is to use one of the conventions for multi-model forms so that if you have <input type=contacts name=mycontacts> you generate mycontacts[email], mycontacts[name], etc. or possibly (in the multiple case) mycontacts[0][email], mycontacts[0][name], etc. There's no single convention for that though, so it doesn't feel overly satisfying.

Then there's fallback. New <input> types work best when it makes sense for them to fallback to <input type=text> (the default): email, url, tel, search, dates all work that way. For contacts, it really doesn't work all that well and you'd' have to hide it (or provide some heavy lifting).

There's also the issue of what you show since it's a visible control. You need a button to trigger the contacts dialog of course, but you also need something to provide the user with visual feedback that they've selected a set of contacts. This can be anything from a "You have selected 47 contacts" string to actually displaying each contact and its relevant fields. Wherever you fall in that spectrum, you then have the issue of how to style it. Speaking personally, I'd very much rather not spend the next five years finding yet more CSS workarounds to get a new form control to work in a dazzling system*browser matrix.

None of this is insurmountable but it's extra work for benefits that aren't immediately obvious (to me). What's more, it's work that seems to involve a solid potential for interop snafus.

The Contacts API is actually designed to operate in the same way as <input type=file>.click() does, but sans the form-related issues. It only triggers on valid auto-invocation events and asynchronously provides a list of objects (the fields of which are tailored to match the request). The idea behind the approach is that if ever there is a will to make this into a form input type, then the code path to support the API on top of it should be as short as calling <input type=contacts accept-fields='name email url'>.click().

So, put another way, what the spec doesn't tell you is that it *is* <input type=contacts>, with the same security model and the same platform integration, but trimmed down to include what you need for the use cases and to exclude what you don't for the headaches.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon