Written: January 27th 2010
A couple of posts ago I asked what the difference was between themes and plugins. Here's why:
To my mind, a theme is a collection of web pages (or template files) which may have some extra functionality bundled with it and a plugin is extra functionality which may have web pages (or template files) attached.
The key difference in real terms is that it is assumed that most template pages will exist in the same place (for a particular theme) and have certain pre-defined file names because, in a system with pre-defined content types, you can pre-judge what pages will be needed to display that content.
Taking WordPress as the example we know a home page will be needed, a page page, a single page, a category page, etc.
In a system which starts without any content types or a system that actively encourages new content types there may however be different needs that suggest alternative ways of dealing with themes. For example, even though you might not know what kind of content will be used you can still pre-define item.php, item.{type}.php, item.{type}.multiple.php, taxonomy.{type}.{name}.php and so on, but the chances of these being able to deal with even the simplest content type are remote.
The question is, in this kind of environment should themers just try their best to cope with the most likely scenario: pages, posts, images, etc, or are there ways for the system to organise theme content to make it easier for plugins that create new content?
A follow up to this is, if there are ways to organise content, would any of these things be useful in existing platforms such as WordPress?
The first step is probably to remove responsibility from the theme for assembling the actual page. There seems to be little reason for a themer to need to create any content that sits outside the body of the page. CSS and Javascript files can be registered for inclusion by the code, page titles can be set in code, you could if you wanted provide options to choose the doctype and encoding, although I think standardising these might be preferable.
Another possible option is to try and standardise as much of the HTML as possible; for example, the HTML for most menus tends to be the same. If the themer doesn't have to worry about creating a menu, instead just inserting one where he wants, then all menus can have consistent skeletons that themers can add skin to. The same might be true of the html for creating columns and other variable features.
This is not radically different from the way child themes operate, although it would have to be more flexible. In addition, WordPress already does this in a few areas such as the comment form, and some HTML that originated in the Kubrick theme.
Finally, if plugins add the ability to use new content types they should probably also specify a default HTML template and layout, using mostly standardised class names, for that type. Ideally a theme should be able to call $item->output() or similar and be presented with the appropriate HTML and CSS. Standardising on HTML 5 would make the styling issues much simpler as well as a themer would not need to worry about which level header was used for the title etc.
Whether or not these specific ideas, none of which are new, are the best way of dealing with it is one question; however, they are all generally a variation on standardisation of content with a view to removing the amount of actual HTML a themer produces. Ideally they would produce none, although in the real world it is almost certain some would be required.
This leads back to the original question about the difference between plugins and themes. If a theme can be produced without writing any HTML (or writing only a few layout pages which components slot into) and it can be skinned using the equivalent of a child theme containing nothing but CSS, then the difference between themes and plugins disapears and presentation becomes just one more thing you can write a plugin for.