I have a note I want to export that contains many other notes.
Several of those contained notes contain snippets of HTML intended as example code. This HTML needs to be escaped for rendering.
So, I’ve set HTMLQuoteHTML to true on each of these notes — both the container I’m exporting, and the contained notes that have sample HTML.
When I preview the output — either in Tinderbox’s Preview or Export tab, or via Export Selected Note and viewing in browser — it’s clear that my HTML is not being escaped. The Export tab shows all my tags un-escaped.
Is there something more I need to do, to get Tinderbox to escape my HTML (substituting entity codes for the angle brackets)? What might be causing Tinderbox to suppress the escaping behavior?
If you are seeing the tags unescaped , e.g. <b> as opposed to <b>, isn’t that what you wanted. If not, please give an example of the the code as typed in your $Text and the same text as visibly rendered on screen.
I’s also suggest you see my article on exporting code samples. aTbRef uses a lot of code examples, not just HTML. I’ve found the approach in the article easiest—in short, I don’t use $HTMLQuoteHTML but simply encode all left angle bracket characters (<) in the source $Text as <.
My recollection is $HTMLQuoteHTML dates from early Tinderbox back when HTML—and web browsers—were less capable. The need for HTML-encoding things like accented characters fell away, leaving the thorny problem of the left angle bracket which starts tags in HTML (and many other mark-up languages). the article above discusses how that is handled.
But if I look at the HTML output, I should be seeing entity refs around the P tags on my paragraph in the CODE block.
Looking at your “exporting code samples” page, I see this:
Tinderbox respects the tags <code> and </code> when they appear within notes. HTML between these tags is always encoded so it appears as you see it, instead of being passed unchanged to the browser.
This suggests that the behavior I’m seeing isn’t to spec. Regardless of whether I set $HTMLQuoteHTML, the behavior I’m seeing doesn’t match this description. I can wrap my sample code in CODE tags or PRE tags or nothing, with $HTMLQuoteHTML on or off, and in all cases Tbx is passing the HTML through un-escaped, contrary to the above quote.
However, I also see that the section “Opening angle brackets of tags” contradicts that first part about CODE tags, suggesting that we’re to manually rewrite all our less-than signs as character entities. Surely that can’t be necessary? That’s a bit horrifying. There’s got to be a way to just paste a chunk of code into a note, wrap it in something that does quoting/encoding, and trust that that’ll work. Having to manually encode every less-than sign is a recipe for mistakes…
Thanks. Most help full. Test #1 is easily fixed if you apply the non-optional encoding of tag openings, as I described up thread and in linked articles.
In the second case, I think HTMLQuoteHTML no longer works—possible as it was designed for HTML use as it was c.20 years ago. Simply use the method above.
I’m uncertain if $HTMLQuoteHTML is actually working. As I recall, the support for <code> and <pre> arose to give more flexible support for code inclusion—of any type of code. The need for manually HTML-encoding < characters pertains not to code so much as code that uses angle-bracket-enclosed tags.
Anyway, I’m just a fellow user describing how it works currently. Requests for changes in functionality need to be raised directly with Tinderbox support at tinderbox@eastgate.com.
Tinderbox respects the tags <code> and </code> when they appear within notes. HTML between these tags is always encoded so it appears as you see it, instead of being passed unchanged to the browser.
If you’re in control of this document, I’d suggest at least removing the second sentence (and possibly the whole bullet list it’s part of); as we can see from these little experiments we’ve just run, it’s not Tinderbox’s behavior.
Ah, I thought you were referring to the $HTMLQuoteHTML article. I’ve also tweaked the article on Exporting code samples. That article does explain, in detail, the need to pre-encode the opening < of tags. I’d assumed people would read the whole article. But, to address your problem, I’ve added extra text telling the user to see the section re encoding <.
In the note, I’m deprecating (informally) $HTMLQuoteHTML because it both doesn’t seen to work and is less flexible than <code> use. As legacy usage, and because it is mentioned also where I still need to mention the attribute. I have, however, severely trimmed the old article for that attribute whilst pointing to the article of exporting code samples.
