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.
> 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.
On Wed, Apr 23, 2008 at 11:17 AM, Arne Roomann-Kurrik <kur...@google.com> wrote: > +1 this would really make serving gadgets out of SVN (and having release/dev > tagged versions) much easier.
> ~Arne
> On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff <mich...@mahemoff.com> > wrote:
> > 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.
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.
On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff <mich...@mahemoff.com> wrote:
> 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.
On Wed, Apr 23, 2008 at 2:21 PM, Kevin Brown <e...@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.
> On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff <mich...@mahemoff.com> > wrote:
> > 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.
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.
> On Wed, Apr 23, 2008 at 2:21 PM, Kevin Brown <e...@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.
> > On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff <mich...@mahemoff.com> > > wrote:
> > > 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.
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?
On Wed, Apr 23, 2008 at 4:19 PM, Kevin Brown <e...@google.com> wrote: > 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.
> > On Wed, Apr 23, 2008 at 2:21 PM, Kevin Brown <e...@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.
> > > On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff < > > mich...@mahemoff.com> > > > wrote:
> > > > 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.
On Wed, Apr 23, 2008 at 4:19 PM, Kevin Brown <e...@google.com> wrote: > 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.
> > On Wed, Apr 23, 2008 at 2:21 PM, Kevin Brown <e...@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.
> > > On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff <mich...@mahemoff.com> > > > wrote:
> > > > 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.
On Wed, Apr 23, 2008 at 10:21 PM, Kevin Brown <e...@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 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.
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 :).
> On Wed, Apr 23, 2008 at 4:19 PM, Kevin Brown <e...@google.com> wrote:
> > 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.
> > > On Wed, Apr 23, 2008 at 2:21 PM, Kevin Brown <e...@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.
> > > > On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff < > > > mich...@mahemoff.com> > > > > wrote:
> > > > > 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.
<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.
On Wed, Apr 23, 2008 at 10:55 PM, Kevin Brown <e...@google.com> wrote: > 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 :).
>> ~Arne
>> On Wed, Apr 23, 2008 at 4:19 PM, Kevin Brown <e...@google.com> wrote:
>>> 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.
>>>> On Wed, Apr 23, 2008 at 2:21 PM, Kevin Brown <e...@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.
>>>> > On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff < >>>> mich...@mahemoff.com> >>>> > wrote:
>>>> > > 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.
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.
> 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.
> On Wed, Apr 23, 2008 at 10:55 PM, Kevin Brown <e...@google.com> wrote:
> > 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 :).
> > > ~Arne
> > > On Wed, Apr 23, 2008 at 4:19 PM, Kevin Brown <e...@google.com> wrote:
> > > > 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.
> > > > > On Wed, Apr 23, 2008 at 2:21 PM, Kevin Brown <e...@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.
> > > > > > On Wed, Apr 23, 2008 at 3:01 AM, Michael Mahemoff < > > > > > mich...@mahemoff.com> > > > > > > wrote:
> > > > > > > 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.
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.
> 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.
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> > wrote:
>> 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.
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>
> > wrote:
> >> 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.
> 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> > > > wrote:
> > >> 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.
>> 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> >> > > wrote:
>> > >> 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.
> 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.
>>> 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> >>> > > wrote:
>>> > >> 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.
>> 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.
>> On Wed, May 14, 2008 at 4:59 PM, Mike Samuel <mikesam...@gmail.com> wrote:
>>>> 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> >>>> > > wrote:
>>>> > >> 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.
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.
> >> 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.
> >> On Wed, May 14, 2008 at 4:59 PM, Mike Samuel <mikesam...@gmail.com> > wrote:
> >>>> 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> > >>>> > > wrote:
> >>>> > >> 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.
|
