When 1999 renders a page, as part of the process, it passes the text through the pagetable.
The pagetable is a JavaScript object with names and values. For example, pagetable.title might have the value Test post or pagetable.authorFacebookAccount might be bull.mancuso.
As the page is rendered, [%title%] would be replaced with Test post, and [%authorFacebookAccount%] would be replaced with bull.mancuso.
Here's a snapshot of the pagetable for a page I rendered on my test server. Any of those values could be used in the template for the page.
The pagetable is built from a variety of sources. Some of them come from the server, like the name of the product, and the address of the API server and WebSocket server. Some of the values are stats kept by the editor, such as ctStartups, or prefs such as flAutoSave. Most of these wouldn't be too useful in a template.
Some of the values come from Twitter, when we authenticate. For example, personName and profileImageUrl.
The pagetable is also available to JavaScript code running in the rendered page. It's a global called pagetable.
This is the information the default page code uses to put up the prev and next arrows, and the elements in the footer.
If you open up the JavaScript console you can inspect it. Or you can type viewPagetable () to get a JSONified rendering of the table.
You'll see that there's more information accessible here, because the pagetable contains objects. Information about the prev and next story pages. All the information about the item behind the rendering as an object.
Here's a snapshot of the runtime version of the pagetable for the example page.
The pagetable has been in all my web CMSes going back to 1996 and the first website framework.
It works beautifully as a way for values to be passed from the editor through the rendering process and into the page at runtime.
I haven't ever come up with a better way to do it. ;-)