As Anton rightly points out in issue 90 , some browsers use .text and some use .textContent to obtain a text version of a DOM fragment. This creates problems for cross-browser unit-testing.
It's possible to add a 'text' property to non-IE browsers that points to .textContent, but since the draft of DOM 3 Core is using 'textContent' as the property name then this doesn't seem like a good idea for the long-term.
Unfortunately, the other way round doesn't work -- we can't add a property called 'textContent' to an MSXML DOM.
For now the quickest route is to add support for the XMLSerializer object to IE, and then change the relevant unit-tests to use the serializeToString() method instead.
(XMLSerializer is non-standard, but it's widely supported, so it's a reasonable solution for now.)
Imported from backplanejs Google Code issue 91.
As Anton rightly points out in issue 90 , some browsers use .text and some use .textContent to obtain a text version of a DOM fragment. This creates problems for cross-browser unit-testing.
It's possible to add a 'text' property to non-IE browsers that points to .textContent, but since the draft of DOM 3 Core is using 'textContent' as the property name then this doesn't seem like a good idea for the long-term.
Unfortunately, the other way round doesn't work -- we can't add a property called 'textContent' to an MSXML DOM.
For now the quickest route is to add support for the XMLSerializer object to IE, and then change the relevant unit-tests to use the serializeToString() method instead.
(XMLSerializer is non-standard, but it's widely supported, so it's a reasonable solution for now.)
Owner set to markbirbeck
Priority: Medium Type: Enhancement