Comment by xg15 | Hacker News Reader

Comment by xg15 | Hacker News Reader

So, question for those who are following the JS ecosystem trends more closely: Is innerHTML now officially "ok to use" again?

I remember way back (when XHTML was still on the table) that innerHTML was effectively deprecated: It was still around but you weren't supposed to use it for anything new because support might be dropped at any point in "the future". It was also non-standard. Instead, you were supposed to use the DOM APIs (createElement etc) for any kind of DOM modifications. (Not even talking about the risk of performance issues or XSS vulnerabilities if you used innerHTML naively)

Now "the future" has come around and innerHTML is still supported basically everywhere. It's clear that implementing innerHTML correctly adds substantial complexity to browsers (they have to parse and serialise arbitrary HTML fragments on the fly, synchronously, without stalling the event loop. The result also has to interact well with all the other DOM manipulation/inspection APIs. Not to mention if the HTML string contains its own bits of JS...) - however, there seems to be so much "legacy" content that dropping the API seems infeasible.

So, does anyone know what the official state of innerHTML is in terms of standard compliance and future support?

Whether or not it is widely supported is academic - you shouldn't use `innerHTML` for the same reasons you shouldn't use `eval`, the most important being that it is a security risk.

> I remember way back (when XHTML was still on the table) that innerHTML was effectively deprecated

I had heard that document.write is discouraged but not innerHTML. In fact, browsers have doubled down, by adding insertAdjacentHTML (originally only in Internet Explorer).

> Instead, you were supposed to use the DOM APIs

I tried that in an app. It turned out that IE 6 was faster with innerHTML, like literally 1,000 times faster. This was surprising because I assumed the DOM APIs were closer to the metal. Not so, at least with Internet Explorer. (With Chrome, the DOM APIs and innerHTML were about the same speed).

> standard compliance and future support

It will be supported forever, because browsers refuse to break the web. You can see them saying so when they discuss syntax for new features.

Mozilla's documentation tells you when a feature is deprecated (again, usually for a feature that was experimental and never widespread). It carries no such notice on its page for innerHTML. It does, however, carry a warning: "Warning: If your project is one that will undergo any form of security review, using innerHTML most likely will result in your code being rejected." --- https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...

To me, innerHTML is sometimes useful and no more dangerous than server-side rendering. Rather than deprecating it, I wonder why browser vendors have not added a native escapeHTML function (or even better, a very short syntax) to make innerHTML safer.

The DOM draft [1] seems to include it. Legacy content is better slow than unusable, however, so it’s better off being discouraged – by linters, dev docs and a warning in the console. FWIW, this is currently linted in TSlint but not JSlint.

It would be nice to have this (via regular or template strings) compile to DOM objects, wrapped with a couple of pointers indicating where strings or elements are placed. I guess for now the best course would be to budge that into transpilation, raising an error if it does anything kooky like work at the boundaries of elements.

(.innerHTML setting is sugar for a HTML parser being initialised on the element, so such a transpiler wouldn’t be removing functionality per se)

[1] https://w3c.github.io/DOM-Parsing/#dom-innerhtml-innerhtml

Don’t use innerHTML with data that you got from a user, directly or indirectly. But if it’s all your data, it’s great.

Reply on news.ycombinator.com