AOL ModuleT: A Module Transport Microformat Profile

The need to syndicate distinct pieces of content and functionality has led to several complex XML schemas and web services. We feel they're all too complex for the "average" developer to create. We need something simpler, that will lead to a larger adoption by the internet at large, not just CMS developers. This is our attempt at doing that.

This is a first draft, and there are still a lot of open questions about module interaction and what toolset will be provided for more complex modules. How those tools are released, hosted and shared across everyone who may want to import and display modules, among other issues are still up in the air. Feedback is welcome.

There are pieces of this microformat that are required, which isn't strictly specified in XMDP. In all browsers that support CSS, required sections should be red. In browsers that support the :after pseudo-selector, you should see the word "required" in parentheses after the title of that section and/or property. Unless otherwise specified, each element is optional. All required elements have a class of "required" on their dt.

Please send feedback to If you would like to join the list and join in the discussion about the format, please send an e-mail to with subscribe modulet-discuss in both the subject and body of the e-mail.


Use of the Publisher Module Specification is governed by the Specification Copyright and Patent Licenses. Please review these licenses now. By using the specification you are agreeing to their terms and conditions.




Page Structure


The element with the class module should have an id that is the concatenated module name. If your module was named "Foo Bar's Module", the module-name would be "foo-bars-module".

For example, if you're creating an HTML document that has one module on it, and that's all the page has on it, you could use the module-name id on the body element. But, if you were building a gallery of modules, you could put the id on an element that contains that module's information.

Linked Objects

Module may be dynamic. In the event that modules will need to include their own CSS or Javascript files, they should be in the head of the document. Any script or CSS file in the head should be imported into the importing document unless they contain one of the following id's. It is still up for discussion if module importers should ignore any <script> or <link> elements with id's.

The CSS file for stying the manifest. This can be either an author-created, or the default manifest css file.
Some tools may be provided for module creators that don't need to be replicated across
Some default styling for pages or modules may be provided.

Meta Data

Information about the module and module author.

A short, user-readable (ie: not overly technical) description of the module and what it does.
A more detailed description of a module capabilities and requirements.
The version of this module.
The default width
The minimum width the module will fit in.
An <img> element that contains the "thumbnail" image of the module.

Module Properties

Each module has some properties to express what kind of module it is, and some of the rules for displaying it. This list is certainly not complete yet. You can use multiple classes within the body element to declare multiple properties for the module. This section will grow over time as we receive feedback (and we're OK with that).

This section will probably morph into something that falls inline with the existing XOXO microformat for defining key:value pairs with definition lists.

Should be used if the user is allowed to add multiple copies of this module on their page. By default, it should be assumed that modules may only have one instance per page.
The module should expand to fill all usable space (ie: it has no set width)
A javascript function to run when a module is loaded.
A javascript function to run for a module when when the javascript onunload event is fired.

Module Instances

Each module should contain the same basic markup skeleton, this is contained within the block with the id of module.

Container Blocks

The containing block for the module. This block should contain all the other information about the module, including the view, and should have the id defined in module-name.
A container for the modules "edit" interface, if it has one. Modules may just be content, but other may require information like a URI in order to work properly. This profile doesn't try to define how the module and edit interface work together or are connected. Any element with this class must also contain module-name.
A container for the "view" of this module. This is the piece displayed to the end user. Any element with this class must also contain module-name

This should be the same value defined for the module-name id.

This class has multiple uses and locations:

linked stylesheets
Since all link elements must be in the document head, we need a way to link stylesheets to their module. So, all stylesheets associated with a module must have the class
Because you'll need to consistently style a module even when it's embedded in another page, it should have a unique class on it along with "view".
Same reasoning as "view"

Within Containers: Module Pieces

The heading of a module. If your module doesn't have a title or any heading information, it's not required. This should also be a <div>, and if it contains heading text, it should be contained in an <h3>. This class must be within one of the containers: edit or module.
This is the "meat" of the module. Can contain any markup, but it shouldn't reuse the "module", "head" or "body" classes. This class must be within one of the containers: edit or module.
A footer for a module. Must always be within one of the containers: edit or module.

Module Information

Should be used on a link that provides documentation for the module, although most documentation should be contained within the detail section.
A link to the license for this module.
Specifies an url that the module importer will need to proxy for the module to be able to use AJAX. The interface of how to do this inside a module is still being worked on.

Author Information

Author's e-mail address, or support address.
URL of Author's website.
Module support information or contact (could be a mailto link).


Modules can and should support tagging. It's not required, but the more data about a module, the better, right?

Specifies a tag that applies to this module. Should follow the rel tag microformat.


Instead of putting a code example here that we know we'll never update, here are some "live" examples of modules someone might create. They don't exercise every piece of the format, but you get the idea (hopefully).