←back to thread

Element: setHTML() method

(developer.mozilla.org)
249 points todsacerdoti | 1 comments | | HN request time: 0s | source
Show context
evilpie ◴[] No.45674985[source]
We enabled this by default in Firefox Nightly (only) this week.
replies(2): >>45675933 #>>45681848 #
spankalee ◴[] No.45675933[source]
I'll be very excited to use this in Lit when it hits baseline.

While lit-html templates are already XSS-hardened because template strings aren't forgeable, we do have utilities like `unsafeHTML()` that let you treat untrusted strings as HTML, which are currently... unsafe.

With `Element.setHTML()` we can make a `safeHTML()` directive and let the developer specify sanitizer options too.

replies(2): >>45676099 #>>45678737 #
somat ◴[] No.45678737[source]
So that's why template literals are broken. I am not much of a JS dev but sometimes I play one on TV. and I was cursing up a storm because I could not get templates to work the way I wanted them to. And I quote "What do you mean template strings are not strings? What idiot designed this."

If curious I had a bright idea for a string translation library, yes, I know there are plenty of great internationalization libraries, but I wanted to try it out. the idea was to just write normalish template strings so the code reads well, then the translation engine would lookup the template string in the language table and replace it with the translated template string, this new template string is the one that would be filled. But I could not get it to work. I finally gave up and had to implement "the template system we have at home" from scratch just to get anything working.

To the designers of JS template literals, I apologize, you were blocking an attack vector that never crossed my mind. It was the same thing the first time I had to do the cors dance. I thought it was just about the stupidest thing I had ever seen. "This protects nothing, it only works when the client(the part you have no control over) decides to do it" The idea that you need protection after you have deliberately injected unknown malicious code(ads) into your web app took me several days of hard thought to understand.

replies(4): >>45679163 #>>45681911 #>>45682081 #>>45682879 #
normie3000 ◴[] No.45679163[source]
I've written a fair number of custom template literals, and I don't understand what your complaint is. Can you share more details?
replies(1): >>45679954 #
somat ◴[] No.45679954[source]
js can't use a string as a template.

my example: a table to lookup translated templates. most translation engines require you to use placeholder strings. this lets you use the template directly as the optional lookup key.

simplified with some liberties taken as this can't be done with template literals. Easy enough to fake with some regexes and loops. but I was a bit surprised that the built in js templates are limited in this manner.

    const translate_table = {
      'where is the ${thing}':'${thing} はどこですか' ,
      }

  function t(template, args) {
    if (translate_table[template] == undefined) {
      return template.format(args);
    }
    else {
     return translate_table[template].format(args);
     }
    }

    user_dialog(t('Where is the ${thing}', {'thing', users_thing} ));
I even dug deep into tagged templates, but they can't do this ether. The only solution I found was a variant of eval() and at that point I would rather write my own template engine.
replies(2): >>45680705 #>>45680770 #
1. normie3000 ◴[] No.45680705[source]
I think I understand what you're suggesting, and I think it can be achieved with javascript template literals. It might be easier to understand with a usage example instead of an implementation example.

The only restriction may be that variable placeholders in additional translations might need to be positional rather than named.