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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
