Erratic HTML export and deletions (Version 11.0.1 (b737)) (solved)

[ShawnMichaels]

edit 7.4.2026:

Summary note after resolving the issue:

The export problem was solved by modifying the SVG file. Further details can be found in my first post from April 7, 2026.

</edit>

Hi!

I have created a website with Tinderbox, but I am now finding that the HTML export is faulty — and completely erratic.

Without changing anything in the TBX file, the export is sometimes (rarely) perfect, and at other times full of errors. For example, the CSS is not interpreted correctly (wrong or no font is loaded, page layout is messed up, etc.). Export codes are not processed, and suddenly things like ^include(xyz)^ appear directly in the HTML output. The code also contains an SVG file as text, which is sometimes rendered correctly and sometimes completely broken.

And as mentioned, the errors vary even when I do not change the TBX file at all.

I am also experiencing instabilities while working directly in Tinderbox. The worst issue was that the content of notes was deleted. At first I thought I had made a mistake, but then the deletions happened erratically again and again. Now I know that I did not make a mistake — Tinderbox itself deleted the note content. Fortunately I had a backup, but serious work is impossible for me under these conditions.

My current version is 11.0.1 (b737) — this is the version with which I am experiencing these problems. With version 10.2.0 (b717) I did not have these issues.

So I did the obvious thing and opened the TBX file in Tinderbox 10 and exported it. And indeed: no errors. Nothing was deleted while working in Tinderbox either.

I am not using any Action Code in this TBX file — only HTML, CSS, export templates, one SVG graphic, a very small amount of JavaScript for a drop-down menu, and one PNG. Nothing special at all.

Is this behavior known?

And what can I do against it (without falling back to Version 10)?

[mwra (Mark Anderson)]

@ShawnMichaels

Is this behavior known?

As a long time heavy user/tester of HTML I’d say ‘No’, at least not in the way you describe. HTML export is not inherently fault nor erratic. Unwitting user error in use of export is the likely cause. I stress ‘unwitting’ as this isn’t a blame game. As a heavy user of HTML export my first cut of a complex export often results in … not what I expected. Careful review and teardown then flushes out unstated assumptions that often turn out to be wrong^†.

To delve further we’d need to see a document that demonstrates the issue. Given that HTML export generally does work, and reliably so, we need to see what is braking it. Several things catch my eye:

@ShawnMichaels

CSS is not interpreted correctly

If you take the CSS from your not(es) and place it a static, manually created HTML page does it work? As well as the CSS syntax being valid, if it is not correctly mapped to the right elements (and inheritance borne in mind) ‘wrong’ renders can occur.

@ShawnMichaels

suddenly things like ^include(xyz)^ appear directly in the HTML output.

Either something in the page’s export before the ^include()~ call is ‘breaking’ export code processing or the object xyz is not identified in a manner the app understands. Is xyz identified by $Name and if so is that title unique and have no problematic characters in it, etc.? Id having issue with the latter consider using $ID or $IDString to indicate the desired object. When using includes be mindful of context (this vs. current) and what template applies in what context.

@ShawnMichaels

The code also contains an SVG file as text, which is sometimes rendered correctly and sometimes completely broken

If you are placing raw SVG code—actually any computing code—in a document’s $Text, I’d strongly recommend using either/both <pre> or <code> to enclose the text. Even in such code also watch for < characters which need to be entified as < or < (also see Exporting code samples).

HTH

†. Occasionally, an export design may assume a method approach that doesn’t exist but which, when discussed with the developer has resulted in export enhancements. I can see plenty of export features that track back to past projects of mine and the developers willingness to explore new features.

[mwra (Mark Anderson)]

Re angle brackets, a simple example from a current task. This is the output render:

This is the $Text:

Note the entification of the left angle bracket inside the <code> section as <. The HTML being:

<p>The following <code>&lt;tab></code> tag attributes

Otherwise, if the character is left as a literal < the render is this:

The HTML being:

<p>The following <code><tab></code> tag attributes

The ‘tab’ is treated as an HTML tag, not a recognised element so rendered use the tag’s name ‘tab’ as literal text..

[ShawnMichaels]

Hi Mark,

thanks for your reply.

This is what I’m going to do now:

1. I will examine the code again, taking your tips into account. It will either get better or it won’t. If it improves, I’ll write here what the issue was.

2. However, if it still doesn’t get better, then I will make the file available.

I don’t want to claim that my code is 100% error-free, but I am still surprised that the export works completely without problems in Tinderbox 10 and in Tinderbox 11 it is erratic and unusable (by which I mean that the errors cannot be reproduced at all; with every export completely different errors appear. I don’t understand how that can be).

Until later!

[eastgate]

@ShawnMichaels

I have created a website with Tinderbox, but I am now finding that the HTML export is faulty — and completely erratic.

This part of Tinderbox is quite well tested and is not likely to be either faulty or erratic. (Some very new features, chiefly involving markdown processing, were introduced in this version, but nothing you write suggests that you’re encountering those.)

@ShawnMichaels

For example, the CSS is not interpreted correctly

Tinderbox plays no role whatsoever in interpreting CSS. That’s your browser. (Exception: the preview pane is a WebKit browser; are we talking about that?)

@ShawnMichaels

Export codes are not processed, and suddenly things like ^include(xyz)^ appear directly in the HTML output

This could occur if you turn off export markup processing.

@ShawnMichaels

am also experiencing instabilities while working directly in Tinderbox. The worst issue was that the content of notes was deleted

I believe this is the first and only report of such a circumstance we have received in the past five years. I have never seen such a thing. Of course, if you have an action that is deleting text on your behalf, that’'s a very different thing.

---

The best way to diagnose problems in HTML export is to compare the exported HTML to what you expect. This is most readily done by identifying an apparent problem in an exported note and making a copy of that note. Simplify the problem note so that the discrepancy is obvious; at this point, you will either understand the problem or you will have an excellent illustration that you can upload here or email to tinderbox@eastgate.com

[mwra (Mark Anderson)]

@ShawnMichaels

I am still surprised that the export works completely without problems in Tinderbox 10 and in Tinderbox 11 it is erratic and unusable

What is not stated (I’m not implying deliberately ) is whether you are exporting the same note content ($Text) as under v10.

If you’re happy to post all the templates used, it should be easy to check those for errors/best practice and see if they are the cause or a factor.

If the templates worked before and don’t now it is most likely (given others don’t report this) that you have either changed some setting (q.v. @eastagate’s point above) or added something into the $Text of a note that Tinderbox expert isn’t expecting.

I don’t know if you are exporting the whole document, but another thing to look for is where export seems to go awry as likely a note ($Text) just up-$OutlineOrder of that point may be the source of badness.

Tinderbox is extremely forgiving of older code—I think support for #-query codes (the old pre-v4.6 method, replaced by action code March 2009) was only recently dropped 17 years later—reinforcing the notion that the ‘content’ being exported is a likely factor.

Another approach I use in scenario like this is to make a ‘manual’ HTML page use the HTML code expect from output and comparing it with code from the Export tab of the text pane. Bar the odd line break, for the same $Text source, both should match. If not the discrepancies merit further review.

Also, the app Help file and aTbref have per-release change logs that are easily consulted for an edge case export changes.

[ShawnMichaels]

Hello,

I’m getting back to you. First of all, thank you very much. The problem has been resolved. However, I still don’t know exactly what caused it. In any case, the file now runs smoothly in TB11 as well.

What did I do?

I followed your suggestions and was able to fix the issue that way. Therefore, there is no need for me to post the TBX file here.

@mwra

If you take the CSS from your not(es) and place it a static, manually created HTML page does it work?

CSS in a separate file instead of in the notes I didn’t change that. So that wasn’t the cause.

Is xyz identified by $Name and if so is that title unique and have no problematic characters in it, etc.?

Yes and yes. I have indeed experienced in other projects that Tinderbox can produce unexpected results when there are multiple notes with the same name that are addressed via $Name. Switching to the ID solved the problem back then and everything ran stably again. In this case, however, I didn’t change that and am still addressing the notes by their names. Good hint from you, but that wasn’t the cause here either.

If you are placing raw SVG code…

This seems to have been the problem! I reduced the SVG code to the absolute essentials. Now the image is embedded stably. The only question remaining for me is why the old SVG code caused no problems in TB10 but did in TB11. This is important because I still have older projects that also contain SVGs with bloated code, which could potentially cause issues in TB11. I haven’t had time to test that yet, though.

@eastgate

MarkBernstein:

The best way to diagnose problems in HTML export is to compare the exported HTML to what you expect.

That’s exactly what I did. In the process, I also noticed a few sloppy bits in my own HTML code (for example, unnecessarily complicated nesting), but nothing that modern browsers couldn’t handle. I’ve cleaned those up as well, so the code is now better.

I believe the export problem was apparently caused by the SVG file. After I simplified the code manually, the issues disappeared. Note: Originally, I had simply copied and pasted the SVG text. Only by consulting an LLM did I gradually figure out what was an essential part of the SVG text and what was unnecessary.

I believe this is the first and only report of such a circumstance we have received in the past five years. I have never seen such a thing. Of course, if you have an action that is deleting text on your behalf, that’s a very different thing.

I know — this was the first time I experienced it too, and it surprised me a lot. And honestly, as far as this text-deletion problem is concerned, I can’t imagine that the SVG file was responsible.

However, something else occurred to me that might have been the cause. In that case, the problem wouldn’t be with Tinderbox at all, but would be Apple-specific and could perhaps be classified in the broadest sense as user error — even though I didn’t interact directly: I have another Mac here that is logged in with the same Apple ID. I can no longer reconstruct it, but it’s not impossible that another person did something on the other computer (for example, typed or deleted text) and used the Delete key, which then affected my machine. It has already happened before that someone was on my iPhone, copied something there, and at the same time I pasted something and ended up inserting exactly what the other person had copied on the phone — so there is interaction between the devices. If that happened, it can lead to unpredictable events.

Perhaps — though I don’t know for sure — that was the reason for the erratic deletions. It hasn’t happened again since then. If that was the case, then it naturally had nothing to do with TB. But it is another potential source of errors that Apple users should keep in mind.

Thank you both once again for your quick and comprehensive help.

[mwra (Mark Anderson)]

Storing SVG inline in $Text. What we can do±because we aren’t stopped—and what we should sensibly do may differ. Given the seemingly g complexity of some of the SVG you describe it is unlikely you want to read the raw code in $Text. Rather, I assume it is there because it arrived into Tinderbox inline in text from [sour outside source].

Were it my file, I would de-interleave the SVG code from actual text:

• add template named ‘tPlainText’ whose code is just ^value($Text)^, i.e. it sets the literal value of $Text with zero e-processing. Template .
• add the built-in code prototype
• make a container ‘SVG files’ with an $OnAdd of $Prototype = "Code";
• for the note containing SVG:
  • make a new file in the ‘SVG files’ folder. Here we’ll call it ‘XX’ but yo’ll need to figure out your own coding system. We assume ‘XX’ is/mist be a unique $Name value.
  • cut/paste the SVG code from the source note into the new note using ‘paste and match style’. You should now see only SVG code in a monospace font form.
  • in the source note, where the SVG was add an include: ^include("XX","tPlainText")^.
• before doing all files, check HTML export for this one one works correctly
• assume the above test works, for the additional note containing SVG, repeat the above process.

Now when the original note is imported, the literal content of note XX (or whatever name) is inserted without any processing into the HTML export.

Note: for actual work rename template names, storage locations, etc., as you want. Of course make sure the new names are called correctly in code. The names above are there simply to allow you to follow through the basic rubric before possible adoption.