Friday, February 16th, 2007

W3C Widgets 1.0 Requirements

Category: Standards, W3C, Widgets

Marcos Caceres is the editor of the Widgets 1.0 Requirements from the W3C (mentioned previously).

Following the publication of the W3C Widgets 1.0 standard the W3C’s WAF working group has republished a requirements document for Widgets 1.0. The new document attempts to embrace the movement towards making widget engines available on mobile devices and the opportunities that opens up.

We asked Marcos what this is all about:

As it’s a requirements document, it is really an open call to the community to give us feedback on what they would want to see in the final spec. In particular, we are looking for suggestions on what parts of the Widget APIs should be standardised.

Personally speaking, I guess cool things include standardising how services on a device are accessed. Services include things like the camera, SMS, voice, and location information to make widgets which are more personable and location-aware. Another aspect that we are looking at is what kind of security model we put around widgets; the key being to have a model that allows developers the flexibility to do interesting things like mash-ups but not to be overly restrictive and not to put both the user and the device at risk.

Let the community know your thoughts.

Posted by Dion Almaer at 10:13 am

3.8 rating from 34 votes


Comments feed TrackBack URI

Did I miss something along the way? If every widget system that’s been developed by a major house has to support a core group of features, you’ll suddenly lose the features specific to a platform.

I can see making something like this for websites where you can easily install the widget on a website, be it for mobile, desktop or otherwise, but to think you can do this for a platform outside of the browser?

They’re talking of being able to create one widget that will work with websites AND operating systems, but how do you create something that’s robust and agnostic? I think the features lost trying to create this one spec to work on all platforms, web or otherwise, isn’t going to have a large impact. People are going to want their platform specific features.

Comment by Andrew Herron — February 16, 2007

Nice but know but how long will it take for vendors to implement let alone follow them. Pass botched examples, SQL, javascript, HTML, CSS. You can probably name some more!!!

Funny thing is someone always has to be the forerunner before standards even start.

Comment by Manny — February 16, 2007

these devices are all converging to have the same featureset anywyas. i think standards could only encourage more people to step into the widget space. knowing they can write once, and deploy on opera/iphone/osux/openmoko/etc

Comment by carmen — February 16, 2007

No. No. No.
You cant start specifying stuff for technologies that haven’t even been fully developed yet.
That’s like standardizing the car before it was even invented.
Have everyone gone completely bonkers?

Comment by mikael bergkvist — February 17, 2007

not developed yet??? My Mac’s Dashboard is no fantasy. It would be terrific to be able to customise/create my own widgets for whatever device I have and whatever service I desire…. eventually, I imagine a set of custom interfaces made up of networked widgets working with and from each other… for and on behalf of me. Ultimately supporting and sustaining my participation in MY work, social, private, creative networks (LIFE). Hopefully this spec is a start.

Comment by deb — February 17, 2007

I mean it’s not a mature technology yet, a lot of things remains to be seen in regard to innovation.
Apollo from Adobe havent been officially released yet for one thing.

Comment by mikael bergkvist — February 18, 2007

My, the guys at Opera would be disappointed to read these comments! The W3C widget specification is nothing else than an attempt to standardize the Opera Widgets (implemented since version 9.0). So a full implementation has been out for “only” 8 months. And speaking of Mac Dashboard widgets, aren’t they based on the same technologies, namely HTML, CSS and Javascript?

Comment by Felix PleÅŸoianu — February 19, 2007

Felix, you are right that the the widgets spec was an input from Opera. The requirements, however, were developed independently by active members of the WAF working group. So it does not mean that Widgets 1.0 will exclusively follow Opera’s work. Far from it. We are looking at as many widget engines as possible to get consensus on features as well as establish best practices. We are also looking forward to widgets in the mobile space where I personally think widgets will really come into their own.

Comment by Marcos Caceres — February 19, 2007

That’s good to know, Marcos. A wider consensus on widgets should help adoption a lot. Hey, even with the current state of the market, widgets are quite popular. Once everyone agrees on a format… wow. I can only dream of the possibilities.

Comment by Felix PleÅŸoianu — February 19, 2007

Mikael, I agree that the widget 1.0 spec should not attempt to standardize everything related to widgets as, like you said, we have not seen complete maturity of this technology. However, widget engines are pseudo standardizing features on their own (using JavaScript, Zip, HTML or XML, etc). I believe it is a good time to start capturing that in a spec. However, the spec needs to be built in such a way that it does not stifle innovation. That is why we are writing it in an open manner; so lots of people can keep an eye on what we are doing so it does not go astray or try to do too much.

Comment by Marcos Caceres — February 19, 2007

Andrew, by no means do we want to limit platform specific features. We are trying to come up with a solution to exactly that problem. All suggestions as to how to overcome this issue are welcomed.

Comment by Marcos Caceres — February 19, 2007

IT Should Start soon. Earlier the better

Comment by Indiamobiles — July 6, 2007

Yes I agree
IT Should Start soon. Earlier the better

Comment by Tribulus — October 1, 2008

Leave a comment

You must be logged in to post a comment.