Most likely this wasn’t an envisaged use case. Original Tinderbox design was for small notes, albeit ones which could be composited to larger notes during export. Here, we are talking about internal web-previewing large un-exported notes which is a significant difference when it comes to how/where styling information is accessed.
The styles.css in the App Support folder is pretty simple:
body{
font-family: HelveticaNeue,Helvetica,Arial,sans-serif;
margin-left: 7.5%;
margin-right: 7.5%;
line-spacing: 1.4;
}
This just gives some minimal non-web-browser-default setting, most importantly a bit of left/right margin whitespace. My hunch is thus that the app’s ‘built-in’ Markdown engine expects/uses a styles.css and that this is loaded before any CSS added in-line or loaded from other CSS files. Unless using inline <style> CSS tags (now a generally deprecated HTML usage) the options are to add to or replace the content of styles.css. I’m not sure how you link to a different CSS file form within your TBX, i.e. before doing any export.
Sidenotes:
I can’t agree enough with @PaulWalters post about making (unintentionally) false steering assumptions about what Tinderbox app is simply based on what we wish it to be—normally based on heavy use of different apps—rather than what this app is. A hammer is good for nails, but not screws: not all sharp pointy things put into wood are nails, even if one is very used to using hammers. It’s easy to misread that as snark, which it isn’t - most of the unhappiest thread starts here are to do with untested false assumptions about how the ‘should’ work.
I’ve not contributed much in this thread simply as I’m no Markdown expert whilst other regular contributors are. That said, I’ve done some fairly gnarly export work with Tinderbox export code. Once the basic Markdown set-up is agreed, along with sensible modification alternatives like different CSS, I’m happy to add to my currently limited aTbRef documentation on this.