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,
> 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?

I think the proposal is missing explicit meaning for target=_self and _blank
(something I'm sure Marcos has considered, maybe just not clarified.)

<a href="http://www.mywidget.com/">click here</a>

If the linked location is inside the widget package, or  
sms:/tel:/similar protocols that don't need a browsing context, I  
would expect:
  - it to load in target=_self (ie. the widget)

If the linked location is outside the widget package, I would expect:
  - it to load in target=_blank (ie. the browser)

If a specific rule must be followed, the developer must add  
target=_self or _blank depending on where the resource must be opened,  
for example. Loading a widget link from inside a widget, or for  
initiating a download - target=_self could be explicitly used.


Marcos, please correct me if I'm reading too much into your proposal.

Cheers,
Gautam

>
> 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 Wednesday, 11 August 2010 18:56:44 UTC