kevin at lawver.net
Tue Sep 27 09:38:30 PDT 2005
I filled in the formats (on the brand new widget-examples page) we could
find when we went through this exercise, and added the example markup I
found (or created).
I think the possibility for a microformat around modules is not so much
in the actual module content, but the information around it (the stuff
in the plist file in a Dashboard widget, for example).
At AOL, we're trying to create a standard way to transport "modules" (or
widgets or portlets), and are almost done with our draft. We're still
working on the details of getting it released to the public, but we'd
love to help with both hWidget and the plist format someone suggested
Aside from transport, I think there are benefits of defining a spec
(maybe not a microformat) for modules themselves separate from the
transport. We found in the AOL Channels work (see
http://sports.aol.com) that we needed some dependanble pieces of markup
in order to style all the modules on the page in a reasonable way. I
think the same thing applies to the importing of content from other
sources (your blogroll from bloglines, location data from plazes, a
Flickr gallery). It becomes a lot easier to do when you can depend on
some markup, even if it's the container, being uniform.
One of our major goals is to make it easy for developers to produce and
share modules with the web. Our thinking is that if the transport
format is also the easiest way to develop a module, we'll get the meta
data we need about the module, and the developers have a good way to
debug their modules. If not, you get afterthought information like you
find in the Info.plist files in Dashboard widgets.
I'm hoping to have any approvals we need to release our draft in the
next week or so. I'll post to the list when it is. In the meantime,
I'd love to help with the plist and hwidget (or whatever it is it
Tantek Çelik wrote:
> On 9/26/05 6:35 PM, "Chris Messina" <chris.messina at gmail.com> wrote:
>>I'm with Ryan on this. Developing an hWidget standard out of the blue
>>that doesn't reflect current practices can result in a lot of spunt
>>Instead, start by documenting Dashboard Widgets, Microsoft Gadgets,
>>Konfabulator widgets and DojoToolkit widgets. They all have their own
>>formats, so they're a great place to begin your research.
>>From there it seems we can start to develop the discussion around a
>>sensible microformat, if indeed one is necessary.
> Precisely. This would be a good application of the microformats
> methodology/process towards solving this problem.
>>The one issue I see, however, is how you think this might be used?
>>Most microformats to date have been designed to represent visible data
>>that previously wasn't marked up in such a way as to identity the type
>>of content being expressed.
> That's right.
>>Applying this axim to widgets seems a
>>little peculiar to me, since widgets are typically interactive
>>elements that often have little embedded semantic content.
> This is also true.
>>In the clock example, it seems like, though you could use standard
>>classes for your component elements, the entire script lives in the
>>only microformatting you've proposed is in your <link> tags, which
>>are already standardized as <link rel=stylesheet> and <script
> Chris is right, there might not be a need for anything more than that.
>>I guess this is something for Ryan and Tantek to mull over, but
>>initially -- though I love the idea of standardizing on semantic
>>classes and attributes for widget-like XHTML -- I'm just not sure that
>>microformats were intended for this particularly computer-focused
>>Ryan, Tantek? Any thoughts?
> In general, there has been a lot of mileage gained from standardized
> *formats*, but less often from standardized *APIs*.
> This seems to be due the nature of data being something you care about
> keeping around for a long time (thus the format matters), whereas
> applications are upgraded, thrown-away, switched-to/from all the time.
> Nonetheless, it certainly seems worthy of experimentation, and I'm certainly
> not going to dissuade anyone of that.
> The big difference is that this wouldn't be a "microformat" per se, since,
> as Chris noted, it wouldn't be used for expressing human *data*, but rather,
> it would be used for expressing aspects of an application.
> However, in as much as microformat methodology can be applied to solving
> this problem, I'm certainly curious to see what you come up with, and have
> no opposition to using this list and the wiki to do so.
> E.g. http://microformats.org/wiki/widget-examples
> So widgeters - have at it (and I recommend postponing the "naming" of it,
> hWidget or otherwise).
>>On 9/23/05, Ryan King <ryan at technorati.com> wrote:
>>>On Sep 23, 2005, at 8:35 AM, Kevin Lawver wrote:
>>>> I just joined the list yesterday, but have had an interest in
>>>>microformats for a while now, and have been promoting them within
>>>>my company (AOL) for a while now. We're working on our first
>>>>"serious" microformat, which smells a lot like hWidget. I've read
>>>>the whole thread on hWidget, and the only example I see is the
>>>>ticking clock. Is there a profile for it yet, or is that example
>>>>the whole of hWidget?
>>>To be honest, hWidget is actually a bit out of line with the typical
>>>process we use for developing microformats [http://microformats.org/
>>>There was no documentation of current behavior, nor analysis of
>>>current schemas (explicit or implicit).
>>>> I'll hopefully be releasing the first draft of our profile in
>>>>the next week or so (if I can get everyone to sign off on making it
>>>>public). I'll be sure to send it to the list, and I'd love your
>>>>feedback on it, and help making it as suitable for general use as
>>>You might want to take a look at http://microformats.org/wiki/process
>>>for ways to go about this.
>>>Thanks for your interest and welcome to the group.
>>>ryan at technorati.com
>>>microformats-discuss mailing list
>>>microformats-discuss at microformats.org
>>microformats-discuss mailing list
>>microformats-discuss at microformats.org
> microformats-discuss mailing list
> microformats-discuss at microformats.org
More information about the microformats-discuss