Re: Contacts API updates

Hi,

On 12.1.2011, at 19.01, ext Rich Tibbett wrote:

[...]

> Actually, the following works in Chrome already:
> 
> <a id="vcard">Save Contact</a>
> 
> <script>
> var vcard = 'BEGIN:VCARD\n' +
>            'VERSION:3.0\n' +
>            'N:Doe;John;;;\n' +
>            'FN:John Doe\n' +
>            'TEL;type=CELL:123456\n' +
>            'END:VCARD';
> 
> document.getElementById('vcard').href = 'data:text/x-vcard;charset=utf-8,' + encodeURIComponent(vcard);
> </script>
> 
> It seems Chrome acts solely based on provided MIME-type (text/x-vcard), and does not require Content-Disposition header in order to trigger the Open/Save As dialog.
> 
> I could only get this to work in Chrome by right-clicking on the link and selecting 'Save Link As...'.

I'm using Chrome 10.0.634.0 dev channel build, also on Mac. Clicking the link opens up my Address Book app directly with a dialog "Are you sure you want to add 1 card yo your address book? Cancel / Add" (I've set Address Book to handle vCard MIME-type, I believe this is the default setting). Clicking Add adds the contact to my address book. Very fluent and intuitive user experience.

> I tested this in Opera, Firefox and Safari (all on Mac). Both Opera and Firefox opens a download dialog on click and correctly identifies the data URI as a vCard. Only Safari was unable to recognize the data URI as a vCard file.

I also get to the download dialog using Firefox and Opera. But from there on "Open with Address Book" says "No importable cards were found". If I hit Save instead, Opera saves the file with the correct .cvf file extension, Firefox with .part, Safari without file extension at all, and also does not display file download dialog.

> FWIW, I also tried changing the last line of your javascript with the following that produced the exact same results:
> 
> document.getElementById('vcard').href = 'data:text/x-vcard;charset=utf-8;filename=contact.vcf;content-disposition=attachment,' + encodeURIComponent(vcard);

I think the filename and content-disposition parameters are not specified in the data URI scheme RFC and based on your experiments it seems no browser vendor has implemented those extensions yet.

> I found a thread on this exact case but it seems it did not go anywhere:
> 
>  http://lists.w3.org/Archives/Public/uri/2010Feb/0058.html
> 
> Disappointed that this was dropped as it seems we have inconsistency in the browser implementation of data URI processing. It would be good for the W3C URI group to clarify the intended behaviour of this since, at the very least, browsers should handle the results in a similar way (and I'd suggest Opera and Firefox as good references for how it should work).

I agree this is a low hanging fruit that has demand and use beyond this group.

> Your use case is IMO valid and is an alternative ready-to-use-today way of saving objects to the user's device.

Feel free to use it in your examples :-)

-Anssi

Received on Wednesday, 12 January 2011 18:02:17 UTC