Specify ownership of the page fragment identifier in the spec

[Arne Roomann-Kurrik]

Per John Hayes' comments in this thread:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/ef1f8d5a470bedae#

Containers have effectively laid claim to the rendered gadget's iframe url's page fragment identifier, as Shindig-based implementations use this field for storing the gadget security token (and some various other parameters).

This prevents developers from using some standard development practices, such as writing links that look like this:

    <a href="#" onclick="callback();">Click me</a>

or jumping to different sections of a tall app view using:

    <a href="#target">Click me</a>
    ...
    <div id="target">Content here</div>

However, this restriction is not listed in the spec and confuses many first-time OpenSocial developers.  We should clarify the gadgets spec to indicate whether gadget developers or the container should have ownership of this field.  Personally, I don't have a preference (other than this be documented), so could some of the Shindig developers weigh in on this?  As an additional consideration, my understanding is that limiting access to the page fragment will decrease the utility of the proxied content proposal (without some complicated rewriting on the gadget server's end).

~Arne


--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Scott Seely]

FWIW, MySpace also uses the fragment identifier, so this isn’t just a Shindig issue.

[Kevin Brown]

On Thu, Oct 30, 2008 at 8:51 AM, Scott Seely <sSe...@myspace.com> wrote:

FWIW, MySpace also uses the fragment identifier, so this isn't just a Shindig issue.

Indeed -- as near as I can tell virtually all implementations are using it.

We did greatly mitigate this in Shindig by grabbing all our fragment data at page load time, but this fails when using the back button. This too can be mitigated by using a hidden form field or by storing the security token in cookies. Orkut gave up on trying to make this work and implemented a scheme where the security token goes into the query string (which was needed to support OSML, preloading, and proxied rendering anyway, so not a big loss).

I fully support putting the fragment back into the hands of developers, but there is a practical reality of performance to deal with. I'd be happy to work with anyone who has objections to this change to find a way to make this work.

[Kevin Brown]

Another item that was recently brought to my attention is the issue of relative URIs. The proxied rendering proposal includes a change to the general contract to allow for this, but it breaks down with fragments.

The options for relative urls are:

- Injecting a base element into the document. This works well in practice, but when the anchor is fragment relative, it goes to the base location, as the RFC for URIs mandates, even though this is almost never the desired behavior.
- Require that containers parse the document and perform relative URI canonicalization, special casing the anchor-only case. This is computationally expensive.
- Explicitly state that relative urls are not supported in the spec. This requires developers to always output fully qualified URIs.

[Kevin Brown]

On Fri, Oct 31, 2008 at 12:44 PM, Kevin Brown <et...@google.com> wrote:

Another item that was recently brought to my attention is the issue of relative URIs. The proxied rendering proposal includes a change to the general contract to allow for this, but it breaks down with fragments.

The options for relative urls are:

- Injecting a base element into the document. This works well in practice, but when the anchor is fragment relative, it goes to the base location, as the RFC for URIs mandates, even though this is almost never the desired behavior.
- Require that containers parse the document and perform relative URI canonicalization, special casing the anchor-only case. This is computationally expensive.
- Explicitly state that relative urls are not supported in the spec. This requires developers to always output fully qualified URIs.

Some experimentation with popular apps from rockyou, slide, ilike, flixster, and buddypoke indicates that the last option is probably best. Developers can still specify a base element (even dynamically) if they really want relative uris.
 

[Arne Roomann-Kurrik]

On Fri, Oct 31, 2008 at 2:46 PM, Kevin Brown <et...@google.com> wrote:

On Fri, Oct 31, 2008 at 12:44 PM, Kevin Brown <et...@google.com> wrote:

Another item that was recently brought to my attention is the issue of relative URIs. The proxied rendering proposal includes a change to the general contract to allow for this, but it breaks down with fragments.

The options for relative urls are:

- Injecting a base element into the document. This works well in practice, but when the anchor is fragment relative, it goes to the base location, as the RFC for URIs mandates, even though this is almost never the desired behavior.
- Require that containers parse the document and perform relative URI canonicalization, special casing the anchor-only case. This is computationally expensive.
- Explicitly state that relative urls are not supported in the spec. This requires developers to always output fully qualified URIs.

Some experimentation with popular apps from rockyou, slide, ilike, flixster, and buddypoke indicates that the last option is probably best. Developers can still specify a base element (even dynamically) if they really want relative uris.
 

I think we can go the path of least resistance here.  If the spec details what to do in this case, we can teach developers the correct practices, so I'm +1 on the third option.
 

On Wed, Oct 29, 2008 at 1:06 PM, Arne Roomann-Kurrik <kur...@google.com> wrote:

Per John Hayes' comments in this thread:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/ef1f8d5a470bedae#

Containers have effectively laid claim to the rendered gadget's iframe url's page fragment identifier, as Shindig-based implementations use this field for storing the gadget security token (and some various other parameters).

This prevents developers from using some standard development practices, such as writing links that look like this:

    <a href="#" onclick="callback();">Click me</a>

or jumping to different sections of a tall app view using:

    <a href="#target">Click me</a>
    ...
    <div id="target">Content here</div>

However, this restriction is not listed in the spec and confuses many first-time OpenSocial developers.  We should clarify the gadgets spec to indicate whether gadget developers or the container should have ownership of this field.  Personally, I don't have a preference (other than this be documented), so could some of the Shindig developers weigh in on this?  As an additional consideration, my understanding is that limiting access to the page fragment will decrease the utility of the proxied content proposal (without some complicated rewriting on the gadget server's end).

~Arne


--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Scott Seely]

It looks like discussion is settling down. Arne-- can you post what
the patch looks like, including some examples for what the proposal
allows?

On Oct 31, 4:12 pm, Arne Roomann-Kurrik <kur...@google.com> wrote:
> On Fri, Oct 31, 2008 at 2:46 PM, Kevin Brown <e...@google.com> wrote:

> > On Fri, Oct 31, 2008 at 12:44 PM, Kevin Brown <e...@google.com> wrote:
>
> >> Another item that was recently brought to my attention is the issue of
> >> relative URIs. The proxied rendering proposal includes a change to the
> >> general contract to allow for this, but it breaks down with fragments.
>
> >> The options for relative urls are:
>
> >> - Injecting a base element into the document. This works well in practice,
> >> but when the anchor is fragment relative, it goes to the base location, as
> >> the RFC for URIs mandates, even though this is almost never the desired
> >> behavior.
> >> - Require that containers parse the document and perform relative URI
> >> canonicalization, special casing the anchor-only case. This is
> >> computationally expensive.
> >> - Explicitly state that relative urls are not supported in the spec. This
> >> requires developers to always output fully qualified URIs.
>
> > Some experimentation with popular apps from rockyou, slide, ilike,
> > flixster, and buddypoke indicates that the last option is probably best.
> > Developers can still specify a base element (even dynamically) if they
> > really want relative uris.
>
> I think we can go the path of least resistance here.  If the spec details
> what to do in this case, we can teach developers the correct practices, so
> I'm +1 on the third option.
>
>
>
>
>
> >> On Wed, Oct 29, 2008 at 1:06 PM, Arne Roomann-Kurrik <kur...@google.com>wrote:
>
> >>> Per John Hayes' comments in this thread:
>

> >>>http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

[Arne Roomann-Kurrik]

I'm trying to think of what this would look like as a spec change.  Right now, it seems like it would require a docs modification to this page: http://www.opensocial.org/Technical-Resources/opensocial-spec-v081
which isn't in SVN. 

Since I want to keep this as a firm part of the spec, I'm tempted to add a couple of new items to the "Compliance" section:

3.1.) The following assumptions are made when implementing the gadgets specification:

3.1.1.) The container MAY choose to utilize the rendered gadget's page fragment for its own purposes.  Gadget developers SHOULD NOT modify this value.

3.1.2.)  The behavior of relative URLs in the gadget spec is undefined.  Gadget developers SHOULD output fully qualified URLs, or inject a <base> element as described in 3.1.3.

3.1.3.)  Containers MUST support the <base> element as described in the HTML 4.01 specification [http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4].  Containers SHOULD move <base> elements encountered in a gadget's <Content> section into the rendered gadget's <head> element, as required by the HTML 4.01 specification.

I'm not married to any of this, so please speak up if you see any changes that need to be made.

~Arne

[Scott Seely]

This looks about right. I would like to suggest that we add a method to gadgets.util: scrollTo(item). This would be something that devs could depend on. One possible implementation of scrollTo is this:

 

    function scrollTo(elemName) {

        var elem = document.getElementById(elemName);

        if (elem == null) {

            var aTags = document.getElementsByTagName("a");

            if (aTags != null) {

                for (var i = 0; i < aTags.length; i++) {

                    if (elemName == aTags[i].getAttribute("name")) {

                        elem = aTags[i];

                        break;

                    }

                }

            }

            if (elem != null) {

                elem = elem[0];

            }

        }

        window.scrollTo(elem.offsetLeft, elem.offsetTop);

    }

 

The aTags version allows for one to mimic traditional <a href="#elemName"> user experience. Example usage:

 

<a id="top">Top</a>

<!-- html that does stuff is here -->

<div onclick="gadgets.util.scrollTo('top');">Go to top</div>

 

This seems to be in the same spirit as the other gadgets.util functions.

[Arne Roomann-Kurrik]

Per the discussion in http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/ef1f8d5a470bedae/11f1b8e1df8b2593 - is scrollIntoView sufficient for this?

For your example, you could just do:

<a id="top">Top</a>
<!-- html that does stuff is here -->

<div onclick="document.getElementById("top").scrollIntoView(true);">Go to top</div>

~Arne

[Scott Seely]

ok

[Scott Seely]

Adding F2F notes to thread:

At this point, some containers still need to own the identifier. We
discussed many ways to put the identifier back in the hands of
developers. For this iteration, we need to explicitly state that
containers own the fragment and then the containers need to do some
rewriting of the HTML to update the relative links appropriately.

[Scott Seely]

+1

[Lane LiaBraaten]

The wiki page for this was tagged at v.NEXT, but I think the current proposal (http://wiki.opensocial.org/index.php?title=Specify_ownership_of_the_page_fragment_identifier_in_the_spec) is just to document that the container currently owns the page fragment, which is appropriate for v0.9.

+1 on this and I've re-tagged the proposal as v0.9

The v.NEXT proposal might be to allow gadget developers to own the fragment.  That would be a new proposal/wiki page.

-Lane

[Lane LiaBraaten (Google)]

We've got 3 +1's here (Scott, Arne, Lane). The proposal is just to
document the current behavior (i.e. the container owns the page
fragment) so I don't think there's any contention here. Anyone else
care to vote?

-Lane

On Nov 25, 11:14 am, Lane LiaBraaten <lliab...@google.com> wrote:
> The wiki page for this was tagged at v.NEXT, but I think the current

> proposal (http://wiki.opensocial.org/index.php?title=Specify_ownership_of_the_p...)

[Maxwell Newbould]

+1
:max

[Louis Ryan]

+1

[Adam Winer]

+1

[Scott Seely]

That’s +5!