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, 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 | ATT -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 | ATT -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:+123456789101112Send 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
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, gaut...@opera.com wrote: 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? 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:+12312Call foo/a Relative link, open in widget context: a href=bar.htmlbar/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
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 | ATT -Original Message- From: Marcos Caceres [mailto:marc...@opera.com] Sent: Tuesday, August 10, 2010 12:30 AM To: gaut...@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, gaut...@opera.com wrote: 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? 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:+12312Call foo/a Relative link, open in widget context: a href=bar.htmlbar/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
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: If the linked location is outside the widget package, it should not automatically load in the browser. I don't understand what you mean here? We need the ability of widgets to download and present network-based content through means other than XHR or iframes. What does this have to do with openURL? What do you need openURL to do that window.open can't do? or that a href= can't do? 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. The proposal has no inpact on XHR. What does this have to do with openURL?
RE: ACTION-568: Create an alternative mechanism for openURL andsend it to the mail list (Web Applications Working Group)
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? Thanks, Bryan Sullivan | ATT -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 | ATT -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:+123456789101112Send 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
