Clojurescript HTML-entity decoding

I’m bringing in XML that comes with things like &rsquo; and &gt;; I want these decoded to display properly in a string as their entities (“smart” quotes, < and > signs). How can I do this, preferably without either including a library or resorting to a big decoding map?

Note that I do NOT want to generate HTML content on the page; I just want to see the characters. So far I made it as far in Closure as safehtml, but I don’t know if I’m barking up the wrong tree (Closure digging can be an arduous task).

As a further explanation, these html codes are being place into a data html argument which is rendered in a content: field by the CSS. In other words, I think i’m looking for a way to convert html-entities into css-entities. This is on-topic, if not a solution: https://www.w3schools.com/cssref/css_entities.asp

Further find: it looks like .net has this covered with CssEncode. Strange nothing is forthcoming in Closure/Clojurescript.

This sounds like two problems: (1) parsing input, which is XML, (2) formatting output, which is CSS.

The browser can parse XML into a DOM, right? Which would leaves you only with the question of how to find the applicable DOM node, nab the string from inside, and format that string as CSS.

for ClojureScript, maybe you import a package from npm https://github.com/mdevils/html-entities#usage ?

There’s no going around a big decoding map. You either write it by hand or you import a library that has it already defined.

I agree though that it’s a blind spot, even in the JVM.

For clojurescript, use javascript interop with the textarea trick:



or the he library:

For Clojure, use Jsoup, which decodes html entities even when you don’t want it to :upside_down_face:

EDIT: Sorry, missed the bit about needing to encode to css entities. I’m not sure how to do that part.

That blind spot is really stunning on the front-end, where I would expect both HTML-entities and CSS-entities to be handled with ease…

I believe we are in this situation because browsers have continually limited when and where they‘re trying to be smart about stuff that gets „evaluated“. Very little of all the web APIs is particularly developer friendly, the primary focus is stability/backwards-compat and integrity (on technical as well as user-intent levels).

1 Like