there is no danger to using html here, and the html case is clearer. We only need to be concerned about html calls where there can be variable input. Literals are not an issue.

I think we can just use html, and just be more careful above about what we allow in. Only prompt_number is input, and we can verity that it's an integer, which is perfectly safe. No need for these shenanigans.

In fact, with encodeURIComponent above, I'm not sure there is anything to change here at all.

Yes, and it should be one of the rare injection point that is tested :-) And I think that like IO, that deal with encode/decode. Escaping should be handled as soon as things get grabbed from the .ipynb not at higher lever.

The problem I have with using .html() in situations where we could get by with .text() is that the content we are passing to .html() today may be safe. But over time, things can creep in-the part of the code creating the content is usually far from the actual call to .html(). I think we should be very aggressive about removing uses of html and all remaining ones should have:

1. A comment about why the content is absolutely always safe....or
2. A call to is_safe to verify the content is in fact safe.

As illustrated by the patch here, this is not actually a case where we can get by with .text(). Escaping the prompt input (already done) and then building html with literals (already done) is perfectly safe.