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

Hi,

On 3.2.2011, at 15.00, ext Rich Tibbett wrote:

> 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.

That's right, there's at least location.replace() and location.assign() that I'm aware of (and there may be more) that could be used here. Below is a summary of my inline script tests (if invoked via user-initiated action all are ok):

window.location (or window.location.href)
Firefox ok, Chrome ok, Opera ok

window.location.assign()
Firefox ok, Chrome ok, Opera blocked

window.location.replace()
Firefox ok, Chrome ok, Opera blocked

window.open()
Firefox blocked, Chrome partially blocked, Opera blocked 

(Firefox 4.0b10, Chrome 10, Opera 11.01 on OS X)

I'd guess the examples should reflect the best practices and based on the above results it seems window.location is the safest bet for now to work around popup blockers. But of course, there's no guarantee of that if UAs tune their blocking algorithms (the relevant parts of the HTML5 spec here are naturally silent on blocking behavior [1,2]).   

>  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. 

That'd be helpful, as it would demonstrate the versatility of this mechanism better. And in general, I think having more good examples is helpful to web developers who may not be so well-versed in WebIDL and would still like to look at the specs and give feedback.

> (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 go!

Well, even better if you're happy keeping both in sync :)

Thanks!

-Anssi

Btw. We touched this topic a bit already in [3].

[1] http://dev.w3.org/html5/spec/history.html#the-location-interface
[2] http://dev.w3.org/html5/spec/browsers.html#dom-open
[3] http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0163.html

Received on Thursday, 3 February 2011 16:21:43 UTC