Quoting "SULLIVAN, BRYAN L (ATTCINW)" <bs3...@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: marc...@opera.com [mailto:marc...@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)" <bs3...@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-requ...@w3.org
[mailto:public-webapps-requ...@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
