- From: <gautamc@opera.com>
- Date: Tue, 10 Aug 2010 07:03:21 +0000
- To: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>
- Cc: marcosc@opera.com, Web Applications Working Group WG <public-webapps@w3.org>
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