Either a bug or an undocumented feature using HTML in Component Description

SU Pro allows you to put a restricted set of HTML in the predefined “Description” field in the Component Options box.

I wanted my “Description” to have some angle brackets surrounding some of it:
Like <this>

First, I tried just typing them, then I realized that SU saw the left angle bracket (aka “less than” sign) as the beginning of an html tag. So I tried replacing it with “&lt;”. At first, it seemed to work just as I wanted it to. But then, I went back into the description to put another word in angle brackets - and my first word disappeared! Here’s an animation:
Component Description Field and Entities.mp4 (2.0 MB)

It appears to me that, if I put an HTML Entity (ampersand-code-semicolon) into the description, SU displays it correctly, replacing the entity with what it represents. But SU ALSO replaces the entity with what it represents in the Description field! So the NEXT time you edit the field, it again interprets the left angle bracket as the beginning of an HTML tag!
So EVERY time you edit the Description field, you must replace ALL left angle brackets you want to appear verbatim with the &lt; entity!

It’s not nice behavior. However, since entities aren’t listed as “allowed” in Dynamic Components supported HTML tags help article, I suppose (charitably) that using entities even once is just an undocumented feature - thus (charitably again) making this issue --not-- a bug.

I’m going to work around it for now - by keeping a notepad window open where I’ll compose and edit my Description, then copy/paste the entire description into the Component Description field - replacing all the previous content - every time I need to make an edit.

PS: I tried to embed the attached animation so that it actually displayed for you, but couldn’t figure out how to do it. Suggestions are welcome, but please reply as a linked topic!

You didn’t use a balancing ">”. If you do, then things work as expected.

Of course, what I wrote didn’t show up here! I wrote these characters next to each other: & g t ;

With the & l t ; before the text, and the & g t ; after the text, it gets parsed correctly, and you can have as many of them as you like.

Unless I’m missing something subtle, as Colin has observed, this seems to be basic HTML markup. HTML tags start with < and end with >. So you can’t use either of those characters per-se in your text, you have to use the escaped &lt;, &gt; sequences instead, otherwise the markup engine will try to process them as tag boundaries and will mess up. In you video it looked like you were trying to type the closing > as such and not via the escape.


For the “balancing” greater than sign, I’ve never needed to use an entity, I assume SU only “looks” for a greater than sign to close a tag. If there is no opening less than sign, then SU interprets the greater than sign as a regular character.

Nonetheless I tried what you suggested: I replaced my “greater than” signs with &gt; and it worked correctly - seemingly!

But then I went and edited the description AGAIN - and my angle bracketed text disappeared - SU had changed the text in the description field IN THE COMPONENT ATTRIBUTES to have the actual brackets instead of the entities. So the NEXT time you edit them, they are treated as tag delineators. THAT is the really nasty behavior.

What SHOULD happen: If you put an HTML entity into the description, it should be saved in the component ATTRIUBUTES field as the full entity (&lt;, &gt;, etc.) and only DISPLAYED in the component OPTIONS box as the character it represents. That way, if you have to edit it again, you don’t have to redo all your entity-ification (is that a word? It is now!)

Typing in the closing > instead of the escaped entity works just fine. I think SU only looks for a “>” if there is a corresponding opening <, otherwise it treats it as a regular character.

In any case, the problem is that SU replaces the entity with the character it represents not only in the displayed result (in the component options box) but also in the description field in the component attributes. So the NEXT time you edit it, you have to redo all the entities. EVERY TIME YOU EDIT IT!

Yes, the balancing gt can be either the & version or the symbol > itself. But as you say, it gets parsed into the real characters, and then a second edit will see those as html characters, causing the word to vanish.

Do your description editing in another program, and copy and paste it across!

you just need to use the proper html escape…
not the shortcut…

< try this >

&#060; try this &#062;

BTW: <br /> doesn’t work in my tests, use </br>


I’ll try that tomorrow. For now, I’m off to my Sister’s - to roast a Prime Rib for my Niece’s birthday!


I brought my laptop with me to my sister’s place as there’s lots of downtime once the roast is in the oven.

Your solution works! And will thus keep me from having to keep a .txt version separate for editing.

With that being said, I still think it’s bad behavior for SU to translate the shortcut into the stored description. Shortcut or hex character code, it should be translated ONLY for display!

I’m guessing that’s due to the fact that SU is doing the parsing - by fairly strict rules to restrict the available HTML. In another thread, I tried to embed a (small) image in the description, but no variation of the <img> tag worked.

I started a thread to report errors in the DC extension Ruby code.
Ruby Errors in Dynamic Components