W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2010

RE: [contacts] HTML Contact Sharing

From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
Date: Mon, 27 Sep 2010 12:14:51 +0200
To: Rich Tibbett <rich.tibbett@gmail.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>, "Isberg, Anders" <Anders.Isberg@sonyericsson.com>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA32D5CCBD635@seldmbx03.corpusers.net>
Yes, of course, the user consent model is the same for both APIs.

So, Richard, which are the main differences in capabilities between the JS Contacts API and the HTML Contacts API, i.e. what could be done with the JS version and that could not be done with the HTML-based version?

Claes

From: Rich Tibbett [mailto:rich.tibbett@gmail.com]
Sent: den 27 september 2010 11:41
To: Nilsson, Claes1
Cc: public-device-apis@w3.org; Isberg, Anders
Subject: Re: [contacts] HTML Contact Sharing

On Mon, Sep 27, 2010 at 11:26 AM, Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com<mailto:Claes1.Nilsson@sonyericsson.com>> wrote:
Hi Richard,

Generally I like the idea of creating simple APIs based on HTML elements. As far as I understand your intention is to provide a simpler alternative for developers than the JS Contacts API. This HTML API will be usable for some use cases.

Comparing with the Firefox demo implementation of the JS API I assume that the use case covered by the HTML Contact API is the “Use Contacts to Personalize This Page” case.

Right.

The “e-mail autocompletion” use cases wouldn’t be possible to implement with the “Device-element” as a “selector”-button is required. Correct?

Autocompletion is a feature of the implementation. It could be provided by a UA on top of a page without the page itself needing to request this feature. i.e. it doesn't need to be specified in an API IMO.


Furthermore, in your example in Appendix A I miss user consent for approving the operation.

Consent is implicit. By selecting contacts to share consent is given in the same way as uploading a file works in the file picker. If I don't want to share I don't click to share or click cancel when the contacts UI widget appears.

Thanks,

Rich


From: public-device-apis-request@w3.org<mailto:public-device-apis-request@w3.org> [mailto:public-device-apis-request@w3.org<mailto:public-device-apis-request@w3.org>] On Behalf Of Rich Tibbett
Sent: den 22 september 2010 02:20
To: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: [contacts] HTML Contact Sharing

I've uploaded a new proposal that defines HTML enhancements to provide access to a user's address book data. The first draft can be viewed here:

  http://dev.w3.org/2009/dap/contacts/HTML.html


This draft is up for discussion - it does not assume consensus on the material at this point.

The proposal is based on HTML Device [1] and reuses the basic security and privacy principles and existing low-level parts of the programmatic Contacts API [2] to provide address book data to a web application.

We chose to build atop of the device element for a number of reasons, primarily because:

- unknown/unimplemented HTML input elements degrade to a text field which isn't an intuitive user experience if the feature is not supported in the user's current browser.

- the HTML device element is not a form-based element. That isn't the primary intention of it's use to obtain contact information. Having said that ...

- the HTML device element's data attribute can be serialized quite nicely (in a JSON.stringify like manner) for transmission via web forms if it needed to be and then deserialized (in a JSON.parse like manner) at the other end as required. Whether the device element could/should provide serialization guidelines is a matter for the WHATWG to decide in [1]. (in the HTML Contact Sharing spec a note has been added to this effect). For example, the device element's value attribute could be set to the stringified value of the data attribute to allow for standard web form submission and parsing on the server-side.

This proposal is an early draft and will be developed going forward.

The intention is for both the programmatic model in [2] and the HTML-based model to co-exist within a conforming user agent, allowing a web developer to choose the most suitable mechanism according to their application's needs and to allow either model to function with the aid of a common user interface/experience, contact storage and format.

All feedback is welcome and will be taken onboard in order to create the most compelling integration model we can. As always,

- Rich

[1] http://dev.w3.org/html5/html-device/


[2] http://dev.w3.org/2009/dap/contacts/Overview.html




Received on Monday, 27 September 2010 10:15:26 GMT

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