sandboxing, widgets, iframes – visit from @premasagar and @jamespadolsey

2 Mar

(super-brief notes… this is more about Prem's work on Sqwidget and related things, which James is also picking up. I blogged it earlier (http://softwareas.com/not-your-grandpas-framesets-premasagar-rose-shows-us-iframe-2-0), but now I'll repeat myself and refine based on my further understanding.)

* The central theme here is Sqwidget, a very lightweight, unobtrusive (in the sense of not imposing grand standards), framework for widgets which are embedded into a "host page", e.g. a blog (the host page) showing a twitter badge (the widget). The widget might be third-party or it might be provided by the host page.

* Normally, widgets are just a third-party providing a script tag, which document.write's an iframe pointing to a URL on the third-party site. That's do-able already, so how does Sqwidget help? Variously, but Prem's main point regards rich interaction, e.g. doing things like lightbox effects or iphone-like sideswipe effects, which wouldn't be possible with an ordinary iframe. He also sees the possibility of widgets interacting with the host page, e.g. to do things like resizing. Several Sqwidget-powered widgets on the page at once might have interesting interactions with each other. You might pull up a lightbox for one widget, and you'll see a dropdown showing all the widgets on the page, so you can immediately switch the lightbox over without having to close the lightbox. Or Sqwidget might change the way it presents widgets depending on the environment its in, e.g. for a mobile browser, it provides a launch button instead of showing the actual content.

* Compared to something like OpenSocial, Sqwidget widgets are just plain-old HTML – a single file containing all the HTML, CSS, Javascript, and images. (It used to be that a SPA was HTML/CSS/Javascript – now, thanks to the MHTML image hack, we have a new permanent fixture.)

* There are several related projects here (see http://github.com/premasagar)

– Sqwidget itself – a library the host file includes, which will augment all widgets with special sqwidget attributes with the actual widget (performing an on-demand load according to a widget URL specified in those attributes). It will also allow widgets to be conjured up and placed via programmatic means.

– Apple of my iFrame – a library that's all about iframe injection. $.iframe("<b>some stuff for the new doc</b>").appendTo("body"). Whereas traditional widgets use iframes to get around cross-domain restrictions and ensure security, Prem and James are using them for a primarily different reason: Sandboxing of CSS and Javascript state. Stuff injected into an iFrame has its own styling (although use of the iframe's allowTransparency attribute, and background "transparent" lead to interesting transparency effects) and a separate global (window) object. Apple of My IFrame handles tricky issues like moving the iframe to different parts of the DOM. (Should be easy, Isn't.)

– Sanitising – not something Prem's working on, but a Caja type thing in JS (see also FuseJS) would be great for Sqwidget to hook into, to ensure what it injects into the iFrame is secure. (The host page would probably set some flag to indicate it wants sanitisation to take place, versus saying it trusts the widget provider.)

– CleanSlate – what I think of as "extreme CSS resets". Lets you say "from this element down, apply this CSS and only this CSS". So it wipes out any inheritance from above, and also any rules that specifically targeted these elements. This is an alternative to Apple of my iFrame, which might be better in some circumstances.

Today, I made a tiny POC cloud IDE using the tool. (basically $.iframe($("#html").val()).appendTo("#output"); ) and we then spent a long time discussing the "embed code", i.e. what does it look like when the owner of the host page embeds a widget. We had several considerations:

* Shouldn't be blocking, so a script tag is ruled out. (Can't rely on browser features like "async" and "defer".)
* We spent a long time deciding how to hold the widget parameters, e.g. for an RSS widget, the host page would need to pass in the RSS URL. This was way more complicated than we expected, because we wanted the programmatic interface to match up with the one where the spec is embedded in the DOM and automagically widgetified upon startup. As an attribute, you can only really have a simple string, which the guys intend to ensure is a comma-separated list of key-value pairs; whereas if it's a Javascript argument, it can be any arbitrary data structure. The decision ultimately was to support both means, though this does lead to problems with the simple attribute model – typing is ambiguous, and nested data structures are impossible. So it may be that the widget provider receives only key-value pairs, where both key and value must be strings.I think Prem and James are still talking this issue over.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: