Spec proposal - JS/CSS relative path support
78 views
Skip to first unread message
Michael Mahemoff
Apr 23, 2008, 6:01:27 AM4/23/08
to opensocial-an...@googlegroups.com
I posted this as a question in the API group and it was suggested I make a spec proposal.
The proposal is to allow gadget authors to include Javascript or CSS using a relative path against the URL of the XML gadget spec. Right now, you have to use standard script/link tags, which means you must use absolute paths in the case of content-type=HTML gadgets (relative paths don't work of course because the gadget is served from the gadget server, not from the source). Absolute paths means you have to hard-code your domain and path information, which makes it unsuitable for running in different environments (dev/test/production/etc) and distributing gadgets to others.
AFAIK the only way to achieve it right now is to manually calculate the gadget URL and dynamically include the script/stylesheet, but this approach is slow and unreliable. I'm looking for a way to include "../common.js" and have the gadget server output a standard <script> tag from it when it generates the gadget content.
The proposal is to allow gadget authors to include Javascript or CSS using a relative path against the URL of the XML gadget spec. Right now, you have to use standard script/link tags, which means you must use absolute paths in the case of content-type=HTML gadgets (relative paths don't work of course because the gadget is served from the gadget server, not from the source). Absolute paths means you have to hard-code your domain and path information, which makes it unsuitable for running in different environments (dev/test/production/etc) and distributing gadgets to others.
AFAIK the only way to achieve it right now is to manually calculate the gadget URL and dynamically include the script/stylesheet, but this approach is slow and unreliable. I'm looking for a way to include "../common.js" and have the gadget server output a standard <script> tag from it when it generates the gadget content.
Arne Roomann-Kurrik
Apr 23, 2008, 2:17:02 PM4/23/08
to opensocial-an...@googlegroups.com
+1 this would really make serving gadgets out of SVN (and having release/dev tagged versions) much easier.
~Arne--
OpenSocial IRC - irc://irc.freenode.net/opensocial
~Arne
OpenSocial IRC - irc://irc.freenode.net/opensocial
Zhen Wang
Apr 23, 2008, 3:20:13 PM4/23/08
to opensocial-an...@googlegroups.com
+1
Kevin Brown
Apr 23, 2008, 5:21:15 PM4/23/08
to opensocial-an...@googlegroups.com
I'm completely in favor of this idea, but we need a solid implementation proposal. It's not clear to me whether or not simply setting a base url in the html output will be sufficient. Rewriting urls could become very error prone.
--
~Kevin
On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff <mic...@mahemoff.com> wrote:
--
~Kevin
Zhen Wang
Apr 23, 2008, 6:27:13 PM4/23/08
to opensocial-an...@googlegroups.com
I suggest we inject a <base> tag automatically, or, better yet, allow
gadget developers to control the content of the <head> section.
gadget developers to control the content of the <head> section.
Kevin Brown
Apr 23, 2008, 7:19:47 PM4/23/08
to opensocial-an...@googlegroups.com
On Wed, Apr 23, 2008 at 3:27 PM, Zhen Wang <wa...@google.com> wrote:
I suggest we inject a <base> tag automatically, or, better yet, allow
gadget developers to control the content of the <head> section.
Setting <base> would be an obvious potential solution, but I don't know that it's clear that this adequately solves the problem without creating new ones.
--
~Kevin
Arne Roomann-Kurrik
Apr 23, 2008, 9:06:03 PM4/23/08
to opensocial-an...@googlegroups.com
I believe that someone previously brought up the idea of adding a substitution token like __BASE_URL__ that would be rewritten with the base URL of the gadget. This way, authors would have a bit more control compared to automatic rewriting. I can't remember if there were any inherent problems with this approach, though... is this still a possibility?
~Arne
~Arne
Zhen Wang
Apr 23, 2008, 9:23:02 PM4/23/08
to opensocial-an...@googlegroups.com
I am not aware of any security issues with the <base> tag.
Michael Mahemoff
Apr 24, 2008, 1:18:58 AM4/24/08
to opensocial-an...@googlegroups.com
On Wed, Apr 23, 2008 at 10:21 PM, Kevin Brown <et...@google.com> wrote:
> I'm completely in favor of this idea, but we need a solid implementation proposal. It's not clear to me whether or not simply setting a base url in the html output will be sufficient. Rewriting urls could become very error prone.
> I'm completely in favor of this idea, but we need a solid implementation proposal. It's not clear to me whether or not simply setting a base url in the html output will be sufficient. Rewriting urls could become very error prone.
I personally don't have any strong preferences on the precise
mechanism. As long as others are willing to propose concrete details,
I will stay out of that debate.
Kevin Brown
Apr 24, 2008, 1:55:52 AM4/24/08
to opensocial-an...@googlegroups.com
On Wed, Apr 23, 2008 at 6:06 PM, Arne Roomann-Kurrik <kur...@google.com> wrote:
I believe that someone previously brought up the idea of adding a substitution token like __BASE_URL__ that would be rewritten with the base URL of the gadget. This way, authors would have a bit more control compared to automatic rewriting. I can't remember if there were any inherent problems with this approach, though... is this still a possibility?
Certainly a possibility, but it's awfully ugly and hacky. I'm definitely in favor of setting a base element, so long as it actually works :).
Evan Gilbert
Apr 24, 2008, 2:26:56 AM4/24/08
to opensocial-an...@googlegroups.com
<base> may cause more headaches when we inline, and I could also see it causing problems with the social XHR requests (which may use a relative URL back to the server).
I like the equivalent of a substitution token... we could also have a <Require> feature for loading JS/CSS, this might make it easier to identify and concatenate resources for optimized processing.
I like the equivalent of a substitution token... we could also have a <Require> feature for loading JS/CSS, this might make it easier to identify and concatenate resources for optimized processing.
Kevin Brown
Apr 24, 2008, 2:36:35 AM4/24/08
to opensocial-an...@googlegroups.com
On Wed, Apr 23, 2008 at 11:26 PM, Evan Gilbert <uid...@google.com> wrote:
<base> may cause more headaches when we inline, and I could also see it causing problems with the social XHR requests (which may use a relative URL back to the server).
Inlined gadgets would always have their urls rewritten regardless of whether a base url was specified or not. Everything has to be forced through the cajoling proxy to ensure that it is safe (even images), so this isn't really an issue. Caja already allows for this type of behavior since it uses callbacks for url rewriting.
Social XHR requests can simply use an absolute url on the same domain as the renderer, so that's not really an issue either.
Zhen has been doing some research at my request to try to determine any situations where <base> doesn't work for the iframe case, and so far we haven't turned up any, so it probably is a viable solution to this problem, and it's certainly a lot cleaner than dropping substitutions all over your gadget.
Michael Mahemoff
Apr 24, 2008, 5:07:09 AM4/24/08
to opensocial-an...@googlegroups.com
For maximum flexibility, it would be good if the script had a way to
discover the source path, e.g. with a token. For instance, I mentioned
CSS and JS, but it may also be that the script needs to refer to
something else, e.g. a media item or a CGI service. Or it may want to
generate a link based on the path.
discover the source path, e.g. with a token. For instance, I mentioned
CSS and JS, but it may also be that the script needs to refer to
something else, e.g. a media item or a CGI service. Or it may want to
generate a link based on the path.
Cassie
Apr 24, 2008, 11:28:33 AM4/24/08
to opensocial-an...@googlegroups.com
btw - this would be for the next spec iteration, which we refer to as 0.9 I suppose.
Arne Roomann-Kurrik
Apr 24, 2008, 3:59:53 PM4/24/08
to opensocial-an...@googlegroups.com
It's a shame that we can't tag threads as 0.8, 0.9, etc. Are you collecting proposals for 0.9 anywhere? It seems far enough out that early proposals like this could get lost along the way...
fargo
May 14, 2008, 6:08:08 PM5/14/08
to OpenSocial and Gadgets Specification Discussion
Thus far <base> does seem like the obvious solution.
Concretely, the proposal is:
"When rendering a gadget in an IFRAME which has URL [gadgetUrl],
inject <base>[gadgetUrl]</base> in the <head> section of output."
For completeness, does anybody know if:
A) all major browsers support <BASE> URL resolution for...
B) every common usage of relative URLs, including: <a>, <img>,
<script>, <object>, CSS selectors, XHR, etc...
?
I suspect the answer is yes, but haven't been able to find a
comprehensive description of same. Zhen, what tests have you run? The
HTML spec (http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4)
doesn't explicitly list every type of resolved relative reference.
In addition, this proposal should be augmented to ensure that
gadgets.io.makeRequest (all types) and <Preload> also honor the base
URL.
--John
On Apr 24, 12:59 pm, "Arne Roomann-Kurrik" <kur...@google.com> wrote:
> It's a shame that we can't tag threads as 0.8, 0.9, etc. Are you collecting
> proposals for 0.9 anywhere? It seems far enough out that early proposals
> like this could get lost along the way...
>
>
>
> On Thu, Apr 24, 2008 at 8:28 AM, Cassie <d...@google.com> wrote:
> > btw - this would be for the next spec iteration, which we refer to as 0.9 I
> > suppose.
>
> > On Thu, Apr 24, 2008 at 11:07 AM, Michael Mahemoff <mich...@mahemoff.com>
Concretely, the proposal is:
"When rendering a gadget in an IFRAME which has URL [gadgetUrl],
inject <base>[gadgetUrl]</base> in the <head> section of output."
For completeness, does anybody know if:
A) all major browsers support <BASE> URL resolution for...
B) every common usage of relative URLs, including: <a>, <img>,
<script>, <object>, CSS selectors, XHR, etc...
?
I suspect the answer is yes, but haven't been able to find a
comprehensive description of same. Zhen, what tests have you run? The
HTML spec (http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4)
doesn't explicitly list every type of resolved relative reference.
In addition, this proposal should be augmented to ensure that
gadgets.io.makeRequest (all types) and <Preload> also honor the base
URL.
--John
On Apr 24, 12:59 pm, "Arne Roomann-Kurrik" <kur...@google.com> wrote:
> It's a shame that we can't tag threads as 0.8, 0.9, etc. Are you collecting
> proposals for 0.9 anywhere? It seems far enough out that early proposals
> like this could get lost along the way...
>
>
>
> On Thu, Apr 24, 2008 at 8:28 AM, Cassie <d...@google.com> wrote:
> > btw - this would be for the next spec iteration, which we refer to as 0.9 I
> > suppose.
>
Mike Samuel
May 14, 2008, 7:59:01 PM5/14/08
to opensocial-an...@googlegroups.com
2008/5/14 fargo <john...@gmail.com>:
Thus far <base> does seem like the obvious solution.
Concretely, the proposal is:
"When rendering a gadget in an IFRAME which has URL [gadgetUrl],
inject <base>[gadgetUrl]</base> in the <head> section of output."
For completeness, does anybody know if:
A) all major browsers support <BASE> URL resolution for...
BASE is part of HTML4 and HTML5. http://www.w3.org/html/wg/html5/#the-base
XHTML strict only supports the href form, not the target form : http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
John Hjelmstad
May 14, 2008, 8:08:47 PM5/14/08
to opensocial-an...@googlegroups.com
True. I just wanted to ensure that all the browsers we care about accurately support HTML4 and 5. :)
Re: target form, we don't care so we're covered.
Re: target form, we don't care so we're covered.
Mike Samuel
May 14, 2008, 8:28:12 PM5/14/08
to opensocial-an...@googlegroups.com
2008/5/14 John Hjelmstad <fa...@google.com>:
True. I just wanted to ensure that all the browsers we care about accurately support HTML4 and 5. :)
Re: target form, we don't care so we're covered.
HTML 5 is a codification of existing browser behavior. Mousing over the link in
<html><head><base href="http://foo.com/" /></head><body><a href="bar">bar</a></body></html>
shows http://foo.com/bar in all the browsers I tested: IE6, Firefox 2, and Safari.
It's not deprecated in either XHTML or HTML5, so it can probably be relied upon to continue working.
Zhen Wang
May 14, 2008, 8:54:19 PM5/14/08
to opensocial-an...@googlegroups.com
XHR is also covered in IE6, FF2, and Safari3.
Kevin Brown
May 14, 2008, 11:25:23 PM5/14/08
to opensocial-an...@googlegroups.com
Based on this, it sounds like it's worth trying to implement it this way and see if it works. I'll start the ball rolling in Shindig to see if there are any cases that don't work; we also need to make sure it all can be implemented in conjunction with the static content rewriting that Louis has proposed.
Reply all
Reply to author
Forward
0 new messages