W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2011

Re: Add/update via window.location (was: vCard and vEvent microdata in HTML5)

From: Rich Tibbett <rich.tibbett@gmail.com>
Date: Thu, 3 Feb 2011 14:00:18 +0100
Message-ID: <AANLkTikuAvYJ0RCHf1qHg5FjmsA5znQzee8bgTuyVQ2T@mail.gmail.com>
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
On Thu, Feb 3, 2011 at 12:19 PM, Anssi Kostiainen <
anssi.kostiainen@nokia.com> wrote:

> Hi,
> On 28.1.2011, at 19.09, ext Rich Tibbett wrote:
> > Perhaps an example, section or a couple of sentences are need to explain
> how this microdata fits in to the Device API specs.
> [Not directly Microdata related, but inspired by the examples in there.]
> Here's an alternative mechanism to add and update contacts (/calendar
> entries/you-name-it):
> window.location = 'data:text/x-vcard;charset=utf-8,' +
> encodeURIComponent(vcard);
> The use of window.location assignment fits nicely in the event-driven
> programming model. This way any add/update operation can be invoked
> programmatically on load, click, keypress, mouseover etc. as well as in
> inline script.

The download and save can be any triggered on navigation to any generated
blob: or data: URI or any static http: or ftp: URI that points to a valid
contact resource (as defined in the spec). As such, we can use any mechanism
to navigate to such a valid contact resource URL. The window.location method
you described works as does any number of other URL-invocation methods
available in the web platform today e.g. window.open.

>  The <a href>-based mechanism I proposed earlier requires either user to
> click the link or script to call the click() [1] method on the <a> element.
> The click() method may not be widely supported for a while, so
> window.location provides an alternative backward-compatible mechanism.

> I'd suggest we add this alternative mechanism to [2] (and also keep the <a
> href>-based one).

There are no requirements on only using anchor elements for this purpose.
Adding a few alternative examples to reflect the multitude of ways that
valid contact resource URLs can be invoked makes sense.

> (I assume we'd like to keep the Contacts examples on the bleeding-edge and
> sync with Calendar examples later on while we still iterate. So perhaps it
> wouldn't hurt to add a note to Calendar stating that for the latest
> add/update examples look for Contacts, they're very similar apart from
> obvious MIME type and vCard vs. iCalendar format diffs.)

That sounds good to me though I'm happy to update both specs in sync as we



> -Anssi
> [1] http://dev.w3.org/html5/spec/Overview.html#activation
> [2] http://dev.w3.org/2009/dap/contacts/#adding-and-updating-contacts
Received on Thursday, 3 February 2011 13:01:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:25 UTC