W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

Re: [contacts] Propsed addition of <input file> extensions to Contacts API

From: Robin Berjon <robin@robineko.com>
Date: Tue, 1 Dec 2009 14:30:33 +0100
Cc: richard.tibbett@orange-ftgroup.com, public-device-apis@w3.org
Message-Id: <83CBB65F-2504-4315-83F4-3939F07C243B@robineko.com>
To: Max Froumentin <maxfro@opera.com>
On Dec 1, 2009, at 14:06 , Max Froumentin wrote:
> On 01/12/2009 13:05, richard.tibbett@orange-ftgroup.com wrote:
>> <input type='file' accept='pim/contact'>
>> 
>> ...and the resulting object would extend the current File object defined
>> in the File Reader API with Contact attributes defined in the Contacts
>> API.
>> 
>> interface ContactFile : File {
>> 	// ... ContactProperties
>> }
> 
> Why extending the File object and not have <input type='contact'>
> which would let the user select an instance of Contacts. I doubt all devices have contacts in a file, anyway.

I'm not convinced about either of these options. When doing this sort of playing with HTML, one needs to look at what the fallbacks look like. For Richard's pseudo-media type approach, the user gets a file upload control, one that might not expose a File API to boot  and is lost. With <input type=contact> the user gets a text field. Neither of those is a really nice experience.

I think we should, for the moment, stick to a point of entry similar to that which we discussed at the f2f (i.e. like Geo's), and just have the draft include a note that we're looking at other options.

--
Robin Berjon
  robineko  hired gun, higher standards
  http://robineko.com/
Received on Tuesday, 1 December 2009 13:31:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:02 GMT