Fog Creek Software
Discussion Board

Knowledge Base
Terry's Tips
Darren's Tips


I would like some "macro" that can be processed, wherein the internal contents would be HTML encoded, something like:

{$ htmlEncode This is<br>HTML! $}

Which would output:

This is&lt;br&gt;HTML!

The reason I want this is that I'm jumping through hoops right now with RSS. The problem is that I want my teaser to be in my RSS <description> tag. It really needs to be encoded. I have used the CDATA suggestion as per the KB article, but many RSS readers seem to ignore anything in a CDATA block, thus making it useless. For the time being, I'm populating "Extra 1" with an exact copy of my teaser, except that I'm hand encoding the HTML. Yuck.

So, as a result, I REALLY want to do this instead:

  <description>{$ htmlEncode {$ x.teaser $} $}</description>

Not sure if that construct is even legal right now in your script parsing system (or whether it's obvious and/or usable), but that's generally what I'm after...

Brad Wilson
Tuesday, February 26, 2002

Can't you just type
"this is <br> html" in the extras pane?

If you type those exact characters the actual html behind it will be
"this is &lt;br&gt; html"

this is because typing a < or a > in the WYSIWYG editor gives you the corresponding &lt; or &gt; in the source view.

Isn't that what you need?

Michael H. Pryor
Tuesday, February 26, 2002

Michael, the trouble is that we surround paragraphs with <P>...</P> (for example) and if your RSS reader doesn't understand CDATA, it will think this is XML, and it will choke.

As an aside, RSS readers that don't understand CDATA are (in my opinion) completely broken; that's a fundamental part of XML.

Joel Spolsky
Tuesday, February 26, 2002


Yes, I'm doing precisely that right now (pasting a copy, and hand-editing it afterwards). I mentioned that.

But it's still a manual (time-taking, mistake-prone) process. Why should it be? CityDesk should be able to give me the "raw" HTML (ala {$ x.teaser $}), or "encode" it for me (ala {$ htmlEncode {$ x.teaser $} $} or maybe even {$ x.teaser encoded $}) so that I don't _have_ to waste both the Extra1 field and my time to completely duplicate a piece of information that is already available.

<br> is not such a big deal. Links really suck. At this point, I've just removed all the links, because I don't want to bother typing in <a href="blah blah blah"> for all the links. Again, you see why I'm saying, CityDesk should be able to do this for me, so that I don't have to manually edit every single article to make RSS functional?


RSS readers aren't choking on the CDATA; they're ignoring it. It's because that's the way XML DOM works... you don't get your CDATA blocks back when you ask for the text value of the element. The CDATA block is handled separately and out-of-band (at least it was the last time I did XML DOM programming, which was admittedly at least a year ago).

Brad Wilson
Tuesday, February 26, 2002

I still think the RSS consumers in question are stupid. Honestly, it doesn't even make sense to have RSS that doesn't include marked up valid HTML in the fields. (What RSS readers are we talking about here? point fingers! I tested CDATA against the validator at UserLand and it was perfectly happy.)

Joel Spolsky
Wednesday, February 27, 2002


Anything you place in a CDATA block is ignored. Instead now I put escaped HTML into my <description> tag, it and it works great (by the way, Radio puts escaped HTML in as well, not CDATA sections, if you want to cite authority ;).

You can test it with my feed:

Brad Wilson
Thursday, February 28, 2002

Hey, this is a feature I would like too, but for a different purpose. I would like to pass {$x.teaser} to a javascript for status bar display or tool-tip. But now I get errors when there are quotes or so in the teaser.

The (almost) opposite would be nice too: a macro to strip all formatting codes (e.g. color, font, paragraph, italic, strong)  (but not special characters). Similar reason.

Adriaan van den Brand
Tuesday, March 19, 2002

I've been using AmphetaDesk lately and it seems to correctly interpret the CDATA designators and properly display text that includes HTML tags.

Brian Cantoni
Monday, April 29, 2002

*  Recent Topics

*  Fog Creek Home