Donut Age: America's Donut Magazine

From MapView to HTML

[Update (5/28): Damn, I knew I was going out on a limb by posting these ideas without testing them at all. Turns out two of the three rely on a feature of Tinderbox that does not exist: namely, mathematical operations on attribute values. Oops. What's odd is that I was so sure that I had seen this somewhere: I could half-picture a page from the manual with + = / and * on it, but when I went back to check, nothing. I guess I was confusing the fact that you can use computed dates like today+1 week with full-fledged math support. Oh well, I guess this will just have to go on the Wish List for a future version. I think the first option still stands as a possibility (although it was the clunkiest of the three), but I have not tested that one yet either.]

Scott Price (who — I am beginning to think — might be my evil twin, though it is equally possible I am his) has an ongoing thread at (hyper)textuality.org in which he's been transforming "Simplicity," the basic Tinderbox blog template, into fully CSS-driven web design. Step 1 and Step 2 are probably of interest even to non-Tinderbox users as general introduction to CSS-based design. However, Price's latest experiment is just plain cool. He decided to use CSS to export his Tinderbox Map View into HTML. Basically this involved setting up a list of correspondences between the Tinderbox attributes that govern maps and CSS styles. Forty-five minutes' work gave Price a pair of simple templates (now posted) that mostly work, but he's still having trouble with converting Tinderbox Xpos and Ypos attributes into CSS length units.

The problem is that Tinderbox's X and Y coordinates aren't in pixels, inches, or ems-- the units that CSS understands. Trial and error showed that Tinderbox's units are about 3em. But you can't do math in an export, so there's no way to say:
^get(Xpos * 3)^em;

I can think of three waysone way to solve this problem.

  • Jigger the stylesheet font-sizes so that the regular Tinderbox values will be the right size: 1) Set the font-size of BODY to 300%. This should set the value of "1em" to three times the browser's default text size so that the raw Xpos/Ypos values will map out the "right" distances. 2) In addition, change the font-size of block-level elements and custom styles to one-third their previous value (expressed in ems). This should make any text in the map appear the same size it was before. Note, if there are many font-size declarations in the stylesheet, especially ones that are relative to some other style or element, this method could get pretty complicated.
  • Create some new user-defined attributes that correspond to the desired CSS properties (e.g., fromLeft and fromTop for positioning the boxes). Then use Rules (available in Tinderbox 2.4 and above) to calculate appropriate values for these attributes based on the corresponding system attribute: i.e., every note would have the rule: fromLeft=3*^get(Xpos)^; fromTop=3*^get(Ypos)^. Templates could then use the style declarations left: ^get(fromLeft)^em; and top: ^get(fromTop)^em; to create the proper positioning. In addition, fromLeft and fromTop) will update every time notes are moved in Map View since Rules are scanned and applied continuously. The drawback of this approach is that for a large document, that will be a lot of Rule activity that isn't really accomplishing a whole lot.
  • Create a macro to convert Tinderbox units into ems, and then invoke the macro in templates whenever needed. The macro (let's call it convertToEms) definition would be 3*^get($1)^em; and templates could use declarations like left: ^do(convertToEms, Xpos)^ and top: ^do(convertToEms, Ypos)^ to achieve the positioning effects. This might be the most elegant and most flexible solution to Price's problem since one could then tweak the conversion factor (or the unit being converted to) by just changing the macro definition once and re-exporting.)

I haven't tested any of the above ideas yet. There might be a bug or two lurking in them, but at least one of these ought to be able to surmount the positioning problem Price describes. Similar techniques might be applied to replicating some of the other Tinderbox effects that Price's template does not yet support (such as border styles) although once you get past simple numeric conversions it becomes trickier (probably requiring macros with lots of conditionals). But I think the core of this idea should work, and I echo Price's assessment that this exercise shows the power of Tinderbox to be applied in surprising ways.