"Martijn" <[EMAIL PROTECTED]> wrote: > On 6/20/06, Foteos Macrides <[EMAIL PROTECTED]> wrote: >> . . . I don't know if you want >> to use the "de facto standard" rationale for this issue, but since you've >> already done it (and "properly") for innerHTML, it should now be a snap >> to >> make the equivalent available as an xml object. > > So you want a .xml property for Mozilla? > Note that you already can do: > var s = new XMLSerializer(); > var d = responseXML.documentElement; > var str = s.serializeToString(d); > alert(str); > > This was taken from: > http://developer.mozilla.org/en/docs/XMLSerializer
Martijn, Note this statement at the top of that document: XMLSerializer is mainly useful for applications and extensions based on Mozilla platform. While it's available to web pages, it's not part of any standard and level of support in other browsers is unknown. and XMLSerializer existed and was discussed at length back during the thread in netscape.public.mozilla.dom: http://groups.google.com/group/netscape.public.mozilla.dom/browse_frm/thread/6630d3d65310f589/48f8da7a71529c0b?tvc=1&q=Problem+with+DOMParser+for+img+elements#48f8da7a71529c0b during which Boris became motivated to actually act on his bug 155723 https://bugzilla.mozilla.org/show_bug.cgi?id=155723 so that the Gecko innerHTML works "properly" in XHTML documents. IMHO we are still many years away from the day when the great majority of browsers actually in use will have the same serializer with both the behavior AND object names of a W3C standard, and even then there will be the issue of "heritage" documents on the web. Whatever one's personal feeling might be about one organization versus another, I don't see why one organization's "proprietary" objects should be considered sufficient. This is a "portability" issue, not a "capability" issue. Regards, Fote -- _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
