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

If the "linked location is outside the widget package", it should not automatically load in the browser. We need the ability of widgets to download and present network-based content through means other than XHR or iframes. If my widget is designed to ingest and present content from external sources (declared as per WARP) within its context (and not just within an iframe), causing such external references to launch in the browser will prevent the intended operation of the widget.

Thanks, 
Bryan Sullivan | AT&T


-----Original Message-----
From: Marcos Caceres [mailto:marcosc@opera.com] 
Sent: Tuesday, August 10, 2010 12:30 AM
To: gautamc@opera.com; 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)



On 8/10/10 9:03 AM, gautamc@opera.com wrote:
> 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?

Hi Bryan, inline content (iframe, img, etc.) inclusion is not affected 
by the proposal. It's perfectly fine to have the following...

Opens in new window:
<a href="http://foo.com">foo</a>
<a href="tel:+12312">Call foo</a>

Relative link, open in widget context:
<a href="bar.html">bar</a>

Embeds in page, if allowed by WARP:
<iframe src="http://foo.com"></iframe>


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

Right. This is/would-be defined in HTML5.

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

As above.

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

You are reading it just fine; But your clarifications are outside the 
scope of the Widget Interface spec.


-- 
Marcos Caceres
Opera Software

Received on Tuesday, 10 August 2010 16:08:52 UTC