Neither of these ways of updating an HTML page has an XHTML equivalent and so to get such code to work with XHTML instead of HTML will require that the code be completely rewritten.
The standard HTML DOM contains commands for adding HTML into the web page such as createElement() and setAttribute(). These commands often require more code than the prior two methods since you need a separate command to create each element to go in your page and then a further command for each attribute to attach to that element. Creating an element does create both the opening and closing tag (where a closing tag is required) so you at least save yourself having to worry about that tag. Also using these methods does add the elements into the DOM where subsequent calls can then interact with it just as if it were a part of the HTML in the page in the first place.
The big difference between the HTML DOM and the XHTML DOM is that an XHTML page can contain elements from more than one namespace and it is therefore necessary when you are adding elements to the page to specify which namespace you are adding them to. This means that instead of using createElement() the XHTML DOM uses createElementNS() where the namespace is specified as the second parameter passed. This allows the JavaScript to interact not only with elements in the xhtml namespace but it can also interact with elements from other namespaces.
To convert code that uses the standard HTML DOM to use the standard XHTML DOM instead may be as simple as converting to sing the namespace versions of those methods that have a namespace version and specifying the xhtml namespace in the second parameter. This means tat one additional benefit of using the HTML DOM properly in the first place rather than one of the alternate non-standard methods of updating an HTML page is that it will require less changes to make it work with XHTML.
The problem is that having changed your code to work with XHTML it will then no longer work with HTML and if you don't change your code it will not work with XHTML. This will not be a problem if you always serve your web page as either one or the other but it will create problems if you try to serve it as XHTML to those browsers that support XHTML and as HTML to those that don't since the DOM calls will then be broken when the page is served using the wrong one based on your JavaScript. Probably the only solution to this that will allow your JavaScript to work both ways will be to have two copies of the JavaScript and using the same server side processing that determines which Content-Type header to use between text/html and application/xhtml+xml will also select which of the two scripts to attach into the page. This will of course make maintaining your JavaScript more difficult as you now have two versions to test but as far as I am aware there is no way to test from JavaScript as to whether it is attached to an HTML or XHTML web page so as to select which version of the commands to run.
The other issue is where you are using third party supplied JavaScripts. Unless they supply two alternate versions for you to choose between you will usually only have a version that works with HTML available for you to use.
For these reasons it is usually best to stick with using HTML for your web pages where you want to use JavaScript with the page since all browsers will support an HTML page and matching JavaScript while XHTML is still not supported by all browsers. The additional complexity in trying to serve XHTML to browsers that support it may be worthwhile for pages that do not use JavaScript but one JavaScript is involved you are making a lot more work for yourself for no noticeable benefit if you take that approach.
