W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

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

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 10 Aug 2010 09:30:13 +0200
Message-ID: <4C610005.90407@opera.com>
To: gautamc@opera.com, "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>
CC: Web Applications Working Group WG <public-webapps@w3.org>

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 07:30:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC