Hi everyone - wanted to kick off discussions for creating a standard
templating solution for OpenSocial. We've been discussing templates from the
beginnings of OpenSocial, however we ended up taking it off of the "minimum
subset needed to launch" list. We're now in the process of initial launches
and it's time to reopen the discussion.

Templates will not make it into version 0.8 of the spec, but we want to work
to get a version of templating in developers' hands very soon. Here's a
proposed timeline:

   - April 14th. Kick off
   - April 23rd. Draft proposal submitted to spec group for feedback
   - May 7th. Deadline for issues to be raised
   - May 28th. Resolution on all issues and spec version 1.0
   - TBD. Reference implementation

Although the official spec date is May 28th, we anticipate that developers
will be able to use a prelease version as a JS library much sooner. Once
we've come to a rough agreement on design, we will develop a standalone
library that anyone can include using <script
src="opensocial-templates.js">.

More detailed discussion of the goals and requirements:

   - Overview
   - Developing OpenSocial applications is difficult.
         - JavaScript isn't the first language for most developers.
         - There is no native templating support in OpenSocial, and
         templating is an established way to make it easy to generate HTML.
         - It's extremely easy to have insecure OpenSocial applications.
         String concatenation is one of the most common ways to write
gadgets and
         almost always leads to XSS holes.
      - Developers need a way to to use UI elements and widgets defined by
      the container.
      - Gadgets want to be able to draw standard versions of UI elements,
         from buttons to friend pickers.
         - The gadget.skins library allows sharing a few key/value pair
         style properties with the gadget, but nothing more.
         - There has been general consensus that we should build a standard
      templating solution for OpenSocial.
   - Requirements
   - Easy to develop with
         - Ability to create templates by copying and pasting HTML and
         making minor modifications
         - Assumption is that this means using markup (but open for
         discussion)
      - Secure
         - XSS free unless developers explicitly work around XSS protections
         - Use of innerHTML strongly discouraged and may be prohibited
      - Capable of creating HTML for most applications
      - Should be able to create entire UI using templating.
         - Binds to data returned from the OpenSocial APIs as well as from
         custom variables the developer has defined
         - Can display HTML elements conditionally
         - Can iterate through data and display HTML content for each item
         in a list
      - Plugs into OpenSocial
      - Can render templates on the client in JavaScript
         - Can render at least a subset of templates on the server (required
         for activity streams and messages, useful for performance)
      - Easy to define templates
      - Can implement a template definition using other templates. I.e.: A
         friend picker template might use the standard button template.
         - Can implement a template definition using JavaScript. This might
         only be available for library writers, but many common UI
elements will
         require significant JavaScript functionality to build.

+1 on the idea to get templates roling!

A couple of notes:

   - The auto-html-escaping (or magic-anti-XSS, or whatever you want to
   call it) is something that needs to be dealt with very carefully. Although
   to people that do not develop in HTML regularly, might benefit from the
   extra security, I would think that most gadget developers developed have
   been developing HTML/javascript for some time, and know how to do things
   correctly. It might put them off if all their regular tricks result in
   douple-html-escaping on OpenSocial. I like to compare it to php's magic
   quotes: the first thing I turn off in any php installation. So I'm not
   against the auto-escaping, it should be done with considerable carefulness
   though!
   - A requirement should be that it allows for i18n of content. We need
   to be able to separate any business logic from the parts that are language
   specific; or: business logic should not be duplicated for different
   languages