The problem

One thing that bothers me on the web these days — and it must bother many other people, because I see a lot of “web 2.0” sites going to lengths to work around this — is that we use a lot of media (which implies a lot of stuff for the client to download), and significant loading and rendering time, to build what could be best described as “decorations” around our main content. Look at my blog; I have relatively little - a logo, the menu of previous posts, a banner ad, a small attribution button, and an optional frame around the post (it goes away if you click on it, in case you haven't found that out yet; click on the post title to get it back). Still, my historic menu requires a non-trivial chunk of data, and it would be a waste to get it from the server on every page load.

Alas, the blog — and the “web 2.0” sites I was talking about — don't really do page loads that often. When you click on a post on the menu, I do an “AJAX” request and load the new post in the frame, without having to rebuild the whole page. Even if you use one of the subject filters, by clicking on the small subject items near the posts, you still don't have a full page load.

But that comes with a price. The page that the URL above points to, doesn't actually have any real content - which means my banner ads end up not being targeted, which means they get a lower CTR, and I get less money. Okay, I don't blog to make money, but if I can make some, why not?

And then, if I want search engines to index me, I have to go trough wild contortions. (In the case of this blog, I just don't bother, since they already index the planet.) And finally, to have unique URLs that you can bookmark for each post, I have to subvert my URLs and use them in ways the Gods never meant them to be used.

On the other site I'm working on, I go with the opposite (and more common) approach; I just do the decorations on each page, and hope that if your computer and connection are fast enough, you won't notice the whole window being discarded and new decorations, identical to the old ones, being drawn on the same places. But this not only can look bad (when things are not fast enough), it's also rather wasteful, in terms of bandwidth, CPU/memory usage, and raw page size. I still believe a webpage should have only the actual content, and some very minimal metadata — if that metadata includes links to scripts, stylesheets and whatever else is needed to make the content purty, then that's fine by me.

Hmm. Whatever else? What about having the decorations themselves as one of those separate resources?

Yet a third approach, which I use on dotplan, is to serve just the content, and build the whole user interface bells and whistles with javascript. I'm aware of quite a few sites that go that route — Gmail for one. What I'm proposing is a variation of this approach — or maybe, rather, a formalisation.

Enter: Lining

Let's call it “lining”; it's a word as good as any other, it's a moderately good mnemonic for what we're actually doing, and I don't believe it's already in use as a (software) technical term.

So we'd have four “component categories” to a web page; actual content (xhtml, images, whatever else you need to show), scripts (defines dynamic behaviour, including that of the lining), styling (defines what the content and lining actually look like - you can have alternate styles for the user to choose from), and lining (a set of widgets that put the page in the context of your site, and helps the user make the best use of the site).

Like scripts and styles, lining can go as a separate resource (<link rel="lining-def" ...) or inline (using XML namespaces, like you would embed a piece of SVG).

There are a few obvious optimisations there; for one, lining would by default not be rendered at all, on print media. If you want a letterhead logo on the prints, maybe also an ad, you'd have to explicitly give it a display property in a @media print block.

A browser that supports lining would behave just like it does now, when displaying a page with no lining. The interesting thing would happen when you're seeing a page with lining, and you click on a link or submit a form (either on the content or lining), or do any other action that would normally cause the page to unload. In this case, the browser would proceed like this:

first, make the network request.
- if it fails, check if the lining has a "onRequestFail" event handler. If it does, call it and stop.
if it succeeds, check the content-type. If it's something that can't possibly have lining (eg, a PNG), unload the current page and proceed as usual.
if it can have lining, load enough information to discover it. On xhtml (and that's the only format for which lining is defined as yet, though I can imagine SVG being useful too), that would be up to the end of the head element.
check if the set of lining-defs is identical. For linked lining, that would be a simple URL comparison; for inline, textual. If they differ, unload the current page and proceed as usual.
if the lining-def sets are identical, then unload the content, and replace it with the new one; don't touch the lining.

Lining widgets are not considered to be in the body; rather, they are in the lining. So, if you happen to have a table element in your lining (I'd rather not, but you could), you can affect only lining tables or only content tables on your CSS, with something like:

lining table {
  border: 3px dotted pink;
}

body table {
  border: thin solid blue;
}

Lining definition and lining data

To make that even more useful, we could parametrise the lining. Essentially, this separates the lining information in two sub-categories; definition and data.

The lining definition just sets up all possible widgets that may be used anywhere in the site. (No information on what they look like or where they're drawn; this goes in the style.)

Then the lining data says which widgets will get used, and what information they will display.

Uh, that's too abstract, example please!

A typical example is a contextual navigation menu. Let's use this blog as an example. All blogs in this site would have the same lining definition, which defines a widget for the category description (used when a filter is set — I call it the “abstract”, if you check my source), one for the historic menu (parametrised by the actual historic, which is different for each blog), and the frame around the actual content, which is not parametrised at all. This could be linked from the top of the blog pages, with <link rel="lining-def" href="/media/lining/blog.wall" />.

Then the data for the abstract box would just not be supplied by the pages, which makes the widget not be shown; if you ever set a filter, the appropriate javascript would then provide this data, which would cause the widget to show up. If the filter is reset, the script would clear the widget's data, and it would disappear again.

(Actually, I'm half-lying here; my abstract box never disappears in the current implementation — if you have no filter set, it will say “All posts by lalo:”. But let's pretend it disappears, to make the example more interesting.)

The data for the menu itself would be the same for all pages in a given blog; so, the blog template could link to it on the header - something like <link rel="lining-data" href="/blog/$USER/menu-data.wall" />. One last piece of data could be provided inline: which entry on the menu should be highlighted as active. Or you may just have your javascript figure that out.

Backwards compatibility

Tricky, but not impossible.

If a page has lining, events like onLoad, onUnload etc — plus new events, something like onContentLoad / onContentUnload — would be sent to the lining element, never to the content body.

Then, an implementation of the lining system can be written completely in javascript. If the language for definition and data is XML, then it wouldn't be too hard.

Finally, you can do this on your pages (after loading the javascript lining library, of course): <body onload="setup_lining()">. And there you go; not complete functionality, but the basics.

Of course, you'd still get full page reloads; but at least, the site would be completely usable by any browsers that support JS and CSS. And for those that don't, you're probably better of not showing the lining at all, anyway.

(If it was possible to alter document.location without causing a reload, then it would even be possible to get complete functionality. Maybe it is possible, and I just haven't found how yet.)

Such a javascript implementation would not only help with compatibility, but also be the best way to prototype these ideas.

Caveats

Since the links to the different sections of your site would (presumably) be in the lining, they wouldn't be discovered by search engines (although if this gets popular, I wouldn't be too surprised if at least Google added support to it in their crawler). So you'd better put up some sitemap-style file in your site.

Alternatives

Rather than lining, layering. You can think of this one as a weird mutant child of frames. The idea is to allow multiple pages to be displayed at the same time, on top of one another. Communication between them would have to be in javascript, but clicking on a link in one could load a page in another, using the existing target= attribute. The location in the url bar would be that of the page containing the element where the focus is.

This would do the trick, it's possibly easier to do, and doesn't require yet another new language. But I think it's conceptually just too ugly to be seriously considered. Besides, a new language is not necessarily bad; it's about time (x)html stopped being used for layout.