Tinderbox Forum

Help with css in exported HTML

Spurred on by the recent addition of ziplinks and the links panel, I have been trying to develop my own “zettelkasten” in Tinderbox. Using @mwra’s wonderful aTbRef-8.tbx file, I have been playing with keeping a css stylesheet at the root level. This is fantastic because it allows me to preview my notes using the “github-dark.css” theme without referencing external files (as done here: Markdown custom themes).

The problem I am now encountering is that I cannot get the “embedded” css stylesheet to “work” when I export my Tbx file to HTML. That is, the HTML pages for my notes are not showing up in the github-dark theme, and I cannot seem to figure out why. I’ve attached a sample document if anyone is inclined to look under the hood and provide some insight (that I apparently lack).

Thanks in advance.

Zk for sharing.tbx (132.7 KB)

The problem child is here:

<link rel="stylesheet" type="text/css" href="^root^^value($CSSTemplate(CSS))^">

in the template. It appears the export process is not exporting the note pointed to in $CSSTemplate. (I cannot tell well, since the document is almost all black to my eyes and impossible to read.)

@PaulWalters thanks for taking a look.

That’s odd because as far as I can tell the style.css note is being exported (in the CSS folder at the root level of the HTML export).

In the meantime, is this more legible?

Zk for sharing light.tbx (147.5 KB)

If the file is exporting for you, but not working, then either the file is at the wrong place relative to the main file that calls the CSS, or the exported link in the HTML is malformed. I would look at whether ^root^ is returning the relative location you think it should.

Thanks @PaulWalters. I apologize for my ignorance (I’m swimming in the shallow end of my knowledge with regards to this HTML export stuff)- how does one check where the ^root^ location is?

What I meant is, check the exported file and make sure the HTML is correct.

See ^root^ here.

I assume you’re looking for someone to fix the HTML for you – maybe @mwra can address that when he’s free. It’s good to dig into the situation and troubleshoot by walking backward from the HTML code that was actually generated to the template terms that created that code. It’s about step-by-step debugging. Good skill to practice.

No intent to condescend, so don’t take it that way. The best thing to learn with Tinderbox is to walk stepwise through things that are not working, use the references, and experiment to find the solution. I pointed you at the section of your code where the reference must be failing (and verified that it fails for me), so that’s the starting point.

Try this as your HTML Page template. It works for me. Sometimes just including the CSS this way is better than attempting to use an external CSS file.

Anyway, this is what my own troubleshooting, as advised above, concluded using your data.

<!DOCTYPE html>
<html lang="en">
<head>
	<meta http-equiv="content-type" content="text/html; charset=utf-8" />
	<meta name="viewport" content="width=device-width, initial-scale=1">
    

<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>
<script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script>
	<title>^title^</title>
<style>
	^include("/CSS/styles")^
</style>

</head>
<body>
<!--   ** Standard Tinderbox Template [section page] **  -->

<h1>^title^</h1>
^text^
^children(/Templates/HTML page/HTML item)
</body>
</html>
1 Like

Thank you @PaulWalters. This works for me as well.

I will look through the template text you’ve provided (with a browser tab open to https://acrobatfaq.com/atbref8/) to better understand what you have done here and why it works.

The “HTML” tab in Window > Show/Hide Text Pane Selector is another, built-in tool for this

Strangely enough I actually created a new simple blog site for myself yesterday using Tinderbox.* Because I find managing relative links difficult outside of my file (I’m just not sure what I’m doing), I actually approached the problem a different way.

In my case, I have a single CSS note which functions as an external CSS file within TBX. But my HTML export templates import that CSS to the <head> element of each page on export.

What this means is that I have all the advantages of an external CSS stylesheet within TBX but when I export pages to post, I don’t have to fiddle with correctly pointing pages to the CSS sheet on the server.

Not a solution for everyone, but for me, it solves a LOT of problems.

Simple Blog Sample.tbx (114.6 KB)

*-The fun one has when stuck at home unexpectedly for two weeks!

I misread @PaulWalters’s last suggestion the first time through. What he suggests is what I do in my file.

1 Like

If you want CSS rendering within TBX and without exporting to hard-disk first, I think you need to use the CSS inline in the templates.

Otherwise, export to HTML at least once so the CSS file exports and then it works. Using @EricB’s sample TB above, once I’ve exported the preview is like

The next question is “why do I have to export”. I the in-app preview doesn’t assume complex multi-file-component HTML pages. Tinderbox is still essentially using a notion of static page export; today’s web pages are far more complex than those c.2001 when the app was first created (IIRC the HTML export want to facilitate blogging—again, blogs then weren’t necessarily run off web databases).

The external scripts work, I think, as they are pulled ‘live’ via the URL. A workaround for the CSS—not texted—is rather than put it inline in the template is to put the CSS at a web URL and call it as with the scripts.

Separately, I’d accord with the above. If a full tests fails, test small and build up adding a single new element (script, css, whatever) at a time.

Many thanks to @PaulWalters, @bcrane, and @mwra for your responses and time on this. In a now deleted post above, I suggested that some of the advice from @PaulWalters could be construed as condescension. I was plainly wrong -the insights and advice provided by such seasoned Tinderbox users have been wrought through a lot of experience and are worth their weight in gold. Lesson learned (and as a byproduct, I also got to learn about HTML export too).

3 Likes

I exported your original tbx file and it works fine in chrome but not in safari

I looked at the html output ( right click–> View source file) and the relative links to the css/styles look fine and all the usual things that trip me up ( css files with

tags, export settings wrong, not using the code prototype to clean the output, wrong template text assignments and loads more that Mark A generally puts right :wink: ) seem to be OK too - what browser were you using?

Screen shot is of the same file with safari on left and chorme on right

Notes_to_WebGenerator_Share.tbx (298.5 KB)

I’ve posted this before but I’ve cleaned it up a bit following Mark A’s advice way back - posting in this thread as covers similar elements discussed here

@Markoconnor I was using Safari. Good idea to try additional browsers. Nevertheless, the solution proposed by @PaulWalters and @bcrane (importing the CSS style sheet into the header of each page) works like a charm.

Thanks for sharing the sample doc. I’m away from my computer now, but will look at it later.

That’s interesting - I’ve no idea why safari is a culprit here…

Have a look when you can - the issue I guess with the solution of importing the style sheet into the header of each page is that it cuts across the fundamental usefulness of style sheets - change one note and a million+ pages are updated instantly - once imported every page would need to be re-exported for changes to be effected

Odd, as Safari worked for me and works in " Notes_to_WebGenerator_Share.tbx", once I’ve HTM-exported the full doc to my local hard-drive. IIRC, in preview mode the app is referencing the exported CSS (guess this reaches back to the fact that originally templates were external files).

Not really, the ‘inline’ CSS extension is suggested for internal preview use. For normal export just stick with the normal method. If you’re exporting, it’s so fast that internal proofing isn’t a big deal not to have.