RE: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group)

Marcos,
You're saying if I understand you, that if I create an anchor:

<a href="http://mywidget.com">Click to load the online version</a>

That when the user clicks this link it will launch the browser, instead of retrieving the online version of my widget (or at least of this page of it)? This would in essence prevent the use of anchors anywhere in widgets, where the developer's intent was to have the web runtime retrieve and present the content directly, within the widget's context. For example, if I want to use an iframe to pull in some external content and then allow the user to navigate the content within the iframe - in your proposal the first link they hit in the iframe would take them out of the widget and into the browser. Not the desired experience IMO.

Or do I misunderstand your proposal?

Thanks, 
Bryan Sullivan | AT&T


-----Original Message-----
From: marcosc@opera.com [mailto:marcosc@opera.com] 
Sent: Monday, August 09, 2010 2:51 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: Web Applications Working Group WG
Subject: RE: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group)

Quoting "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>:

> Marcos,
> That method works for well-know URI schemes except for http:// and   
> https://. The openURL() method would have launched the browser for   
> those schemes, and we still need a method to do that.
>

No.  We dont. Please see my proposal.

> I was not able to attend the last week's call and was not aware   
> there was a plan to remove the openURL() method. This leaves a major  
>  hole in the functionality we need from

Major hole?  No one has yet presented a single use case that could not  
be done with an a element.

the Widgets specs (ability to
> launch the browser when necessary/desirable, which is something only  
>  known by the widget - e.g. it needs to invoke a resource that it   
> knows needs to be handled through the browser or other registered   
> URI scheme handler).

See my proposal. Its not needed.

>
> Thanks,
> Bryan Sullivan | AT&T
>
> -----Original Message-----
> From: public-webapps-request@w3.org   
> [mailto:public-webapps-request@w3.org] On Behalf Of Marcos Caceres
> Sent: Friday, August 06, 2010 8:56 AM
> To: Web Applications Working Group WG
> Subject: Re: ACTION-568: Create an alternative mechanism for openURL  
>  and send it to the mail list (Web Applications Working Group)
>
>
>
> On 8/5/10 3:30 PM, Web Applications Working Group Issue Tracker wrote:
>>
>> ACTION-568: Create an alternative mechanism for openURL and send it  
>>  to the mail list (Web Applications Working Group)
>>
>> http://www.w3.org/2008/webapps/track/actions/568

>>
>> On: Marcos Caceres
>> Due: 2010-08-12
>>
>> If you do not want to be notified on new action items for this   
>> group, please update your settings at:
>> http://www.w3.org/2008/webapps/track/users/39125#settings

>
> The proposal is simply to use HTML <a> element.
>
> So, instead of:
>    widget.openURL("sms:+123456789101112");
>
> It would just be:
>   <a href="sms:+123456789101112">Send and SMS</a>
>
> Then you can use the .click() element to open links programmatically (on
> trusted URI types) or only respond to explicit user interaction (the
> user clicks on the link to do something).
>
> Kind regards,
> Marcos
>
>
> --
> Marcos Caceres
> Opera Software
>
>

Received on Tuesday, 10 August 2010 00:08:44 UTC