meu entulho querido


Classless Themes

Everybody is familiar with the concept of a “theme”, right? When you have a CMS (or anything that doesn’t call itself a CMS, but is) then it comes with “themes”. There are a lot of themes for CMSes everywhere, from Wordpress to Format, passing through Plone, Mezzanine, Ghost, Nesta, Jekyll, Webhook, CMS Made Simple, October and Wintersmith (I just searched for various CMSes without knowing if they were actually popular or good).

At the same time, any developer wanting to write his own CMS, or any person making his own blog or website without using one of the most popular CMSes, will have a hard time with the theme bit of it. For the developer, his CMS will not be really usable unless it has a lot of themes designed specifically for it; for the person, designing a theme from scratch will be an unnecessary and buggy adventure (with all the responsiveness quirks and other problems that designers face), and porting a theme from another CMS is almost impossible due to templating languages, the way partials are imported and different context variables available.

But still, porting themes from other CMSes looks like a good idea. There are some people doing it. For example, HubPress, a new CMS that renders static blogs on the browser and deploys them to Github pages, is porting themes from Ghost to itself. The system was designed to be compatible with Ghost (which means it cannot be compatible with other CMSes), but, as it doesn’t use the same libraries and technologies and do not have the same data model, it is still not fully compatible and some manual work must be done to reuse Ghost themes on it.

These problems – and the fact that theme porting is not extensively done – should have raised our attention to the huge waste of work that is taking place in the theme design world. Indeed, while all over the programming languages communities there are efforts (some more successful than others) to encourage modularization and code reuse, the don’t repeat yourself principle is very hard to follow if you’re doing CMS themes (or any open-source page design).

What is the cause?

I already said:

templating languages, the way partials are imported and different context variables available.

So, if a “theme” is a combination of CSS, Javascript and HTML templates and “partials”, the problem is the HTML part. CSS and Javascript are not dynamic, never, in all these templates, only the HTML generation is dynamic, depends on context, variables, templating language, predefined filters and expressions, directory structure has room to be problematic and incompatible.

What is the solution?

Pure CSS themes.

By “pure” I mean free of HTML (Javascript is fine). If there was some agreement (on agreement see xkcd) between designers and CMS developers to a common HTML template, sufficiently flexible to support all the normal kinds of pages, that every CMS out there could reuse for generating its HTML, and then we started writing themes for it, all the CMSes and personal websites that used the same basic template could make use of the themes.

CSS alone, when given a well-structured HTML template, can do all sorts of amazing things, as we all know from the examples at the CSS Zen Garden. So what are we waiting to create CSS themes, consisting only of CSS, and have them automatically applicable to HTML documents everywhere?

This is a proposal for a HTML template standard.

How is this standard supposed to be?

I don’t want to design this, this is just a proposal. I don’t have the power to enforce it to anyone, I can only suggest and hope someone joins me on the effort, so then slowly we can reach some point where it is useful.

(Also, on standards see xkcd.)

The only thing that this standard must have is an HTML template, I mean a HTML document with the tags, but not the contents. The contents must be filled by each implementation and each rendering process. The standard template shouldn’t be tied to any “templating system” or language, anything, from Mustache to Jinja2, passing through raw HTML editing, should be capable to reproduce this standard HTML structure, so themes can be applied to it.

In order for it to be useful, I imagine that it must have support for

  • a header – with
    • website name, or the page name, and
    • an image,
    • perhaps also a line for a subheading
  • a side or top menu, with
    • a space for arbitrary listings and
    • arbitrary text
  • a main content element, inside which we would have
    • a metadata box containing a
      • title,
      • date and
      • other arbitrary metadata
    • the main content itself
    • a footer – with room for
      • basic text info or
      • some listings
  • a footer all over there in the page

With this structure, I imagine, we can generate probably all the blogs and personal websites out there, and, with some CSS love, we can build any layout that powers any of these pages. The top menu can be rendered as a side menu, or a bottom menu; the footer can be thrown to the side menu, as well as the header; the metadata can be hidden; the header can be rendered with the post title instead of the page title; the image in the top can be filled with a picture of the author; the first image of the main content can be used as the background image on the header; any element can be omitted; Javascript can be used to do all the fancy things CSS isn’t capable of (I mean, it can move the page contents back and forth and the page will still make sense when noscript clients visit it, since the meaningful structure of the basic source HTML will be there).

When writing coisas, my browser-based static website compiler that deploys to GitHub pages I came up with a model template that would be reused by every people running the software. The ideas was that the users would run everything their your own browsers, and have their content in their own repositories, but the basic HTML template was hardcoded to be fetched, through AJAX, from my repository. Any themes and fancy layouts would have to be done only through CSS editing.

I think this approach was problematic under certain aspects, but overall it was good. However, only while it stayed within the context of my own CMS. Now I want something that not only satisfies me, but that can be used by others (you can say that I want this mainly because I want to reuse others’ templates and it will be true).

So, that’s it. I’ll be writing a CMS and trying to come up with the best template I can, inspired by other CMSes. But I really want some collaboration of souls facing themselves this same problem and wanting to collaborate with the ideal, most flexible and still semantic, template; and to write, port and share some themes to it.

UPDATE: Here’s a first draft of the thing. If you’re interested, open an issue and let’s discuss it.