[uncle_j]

This is a shame in some ways. Internet explorer was always very strict on how it works.

Anything before 8 was a challenge due to some atrocious bugs.

This had it problems but it really taught you not to write sloppy CSS and JS as it would usually just wouldn't work.

Versions After 7 basically anything that wasn't in the spec supported wasn't implemented so you had to write code pretty much bang on the spec.

Just this Friday I solved a rendering problem with IE where SVG TEXT elements weren't being rendered correctly, I was calling element.innerHTML to set the text which was incorrect. I should have been element.textContent. Using element.innerHTML is incorrect as SVG elements shouldn't have a innerHTML property (they are not HTML). IE11 was actually working correctly, where the latest Chrome behaviour was incorrect.

So spending time making it work in IE has improved my code.

[kyle-rb]

>Using element.innerHTML is incorrect as SVG elements shouldn't have a innerHTML property

Is that definitely the case? Chrome, Firefox, and Safari all return a value for the innerHTML property of an element in an SVG document.

This W3C spec [0] specifically mentions XML documents in addition to HTML documents. And as I understand it, it seems like embedded SVG elements also inherit from the Element interface which includes InnerHTML.

IE11 might also be correct, following an older spec, but I don't think you can jump to the conclusion that Chrome is wrong just because the property is called innerHTML.

[0] https://w3c.github.io/DOM-Parsing/#the-innerhtml-mixin

[uncle_j]

That is interesting.

I assumed that innerHTML must have been wrong because textContent works in all the browsers I have tried it on whereas innerHTML doesn't work. A cursory search textContent vs innerHTML seemed to suggest textContent was the correct way.

It looks like it isn't a simple case of IE11 (I haven't had a chance to test on 9 & 10 yet) being correct and the others being incorrect. Thanks for the info.

[hadrien01]

Totally agree with your conclusion. I remember generating a JavaScript array in a server-side loop, and the code wouldn't work (at first) because of a trailing comma on the last element before a bracket. Firefox would ignore it, but IE 8 wanted a perfect no-extraneous-commas code.