Escaping implementation seems to be a glaring LAYER VIOLATION, methinks.

[andim2]

Hi,

"I think you got it all wrong" ;)
Well, no, quite possibly not everything, many things seem nice, but this particular part here........

http://trailblazer.to/gems/cells/api.html#html-escaping

Logically, IMHO "escaping" (or, possibly much more correctly: "transcoding") ALWAYS is
a matter of protecting (against conflicts vs. control characters space of a specific protocol!) raw payload (usually: raw strings) within a specific foreign-protocol container - the very moment that the raw string starts needing to be used within that container format protocol, that is, and not a blink of an eye before!
Thus, it's the task (and, intimate implementation detail knowledge!!) of an OUTER container layer which
is to escape (transcode) adopted raw payload content right when ([OSI] LAYER TRANSITION activity!!) embedding that payload element content into a containing container (whichever way that container might be defined, be it HTML, XML, binary format, ...).

Thus, having any signs of escaping whatsoever attached to any supposedly "simple" payload type whatsoever:
class CommentCell < Cell::ViewModel
include Escaped

is a protocol-extensibility-breaking (what will happen if you [are forced to] change to a wholly different container spec??) LAYER VIOLATION and thus WRONG - at least from my (domain-specifically very unexperienced - perhaps this framework is indeed actually doing it right somehow...) POV.

Docs part "You can suppress escaping manually." seems to be a tell-tale sign for existence of that layer violation (one very likely shouldn't be in need of such questionable weak-toggle-disabling if handling were properly layer-designed...).

I.e., operation style should actually be something like

MyString rawString("--> here");
myHtmlDom.RenderHeader(rawString);

inherently/implicitly/automatically presented as:

<h1>--&gt; here</h1>

HTH!