[Moo] IE (argh!) and ixmldomnodelist

[Eric Patrick]

I have a large number of ASP.NET web services that feed data-driven
content to Mootools-based AJAX requests; most of them return ASP.NET
XmlNodes (XHTML).

Using Request.HTML works great in non-IE browsers. Unfortunately, IE
interprets the XmlNode structure as ixmldomnodelist, instead of a
traditional DOM object.  Not a problem for the most part, until we get
to Element.empty().

Here's the sequence:

- Initial page draw includes: <div id="mytag">.</div>
- Invoke Request.HTML with an update: 'mytag' option set
- server returns an XmlNode / XHTML (the relevent part here is, I
believe, an XML declaration as the first line)
- Request.success calls document.id[this.update].empty().set(...)
- The div tag now contains the full XHTML returned (including the XML
declaration)

(so far, so good)

- Invoke Request.HTML to refresh the content (update: 'mytag' again)
- server returns same content
- Request.success calls document.id[this.update].empty().set(...)
- an error is thrown, since IE casts document.id[this.update] as an
IXmlDOMNodeList

I had a few possible workarounds:

- override Request.success to call document.id[this.update].set(...)
  - bypasses empty, which fails to destroy objects elegantly, so I run
the risk of memory leaks
  - currently using this
- override Element.empty to explicitly handle IXmlDOMNode issues
  - more work, and I'm lazy
- override Element.set() to trap for xml declarations, and "convert"
to traditional DOM
  - probably the best, but again, I'm lazy
- rewrite several hundred web service methods to return strings
  - not viable; we have clients who bind to the WSDLs and expect
XmlNode instead of a string

Any thoughts or suggestions on the best approach?

Eric

[Sanford Whiteman [Mobile]]

Bottom  line:  you're  trying  to  shoehorn an XML fragment, including
declaration, into the HTML DOM. There is no reason to expect it should
work -- no standard dictates so.

This  is  redolent  of  another  recent  post about returning non-HTML
elements into the HTML DOM. My recommendation is the same as I made to
the  other  guy  (Manu):  massage  out  the invalid HTML (in his case,
namespace   non-standard  tag  names;  in  your  case,  take  out  the
declaration),  create an Elements collection, manage the updates using
your own wrapper.

If  this problem befell me, I would probably massage the XML stream on
the  fly  using a proxy server setup. But we already have such a proxy
server  in  place  -- if you don't, then fixing it up on the client is
likely a better choice.

-- Sandy

[Eric Patrick]

Actually, there is a standard that dictates XML declarations are
allowed in XHTML; see: http://www.w3.org/TR/xhtml1/

"XHTML document authors are strongly encouraged to use XML
declarations in all their documents"

(I supposed one can argue the intent of the W3C r.e. this line and
whether it would be applicable to injecting XHTML into another XHTML
document via AJAX; my point is merely that what I'm doing should not
be considered all that unusual.)

Since Mozilla and Web Toolkit handle this elegantly, I chalk this up
to an IE bug (thus the "argh").

I would be surprise if others have not encountered this, given a very
common use case of AJAX is injecting XHTML into the DOM.  Thus the
post here.

My initial reaction is to handle this situation by override
Request.success, and if we're dealing with IE, strip any
declarations.  I can certainly do this for my situation, but figured
it may be a value-add to the MooTools community, so I figured I'd
foster some feedback :-)

Off to override Request.success; let me know if anyone else has pros/
cons/alternative suggestions and if they would find such an extension
useful.

Eric

[Fábio M. Costa]

why dont you generate e normal html document with text/html header and inject it into your document by innerHTML?

--
Fábio Miranda Costa
Solucione Sistemas
Engenheiro de interface

On Thu, Oct 29, 2009 at 10:44 AM, Eric Patrick <[hidden email]> wrote:

Actually, there is a standard that dictates XML declarations are
allowed in XHTML; see: http://www.w3.org/TR/xhtml1/

"XHTML document authors are strongly encouraged to use XML
declarations in all their documents"

(I supposed one can argue the intent of the W3C r.e. this line and
whether it would be applicable to injecting XHTML into another XHTML
document via AJAX; my point is merely that what I'm doing should not
be considered all that unusual.)

Since Mozilla and Web Toolkit handle this elegantly, I chalk this up
to an IE bug (thus the "argh").

I would be surprise if others have not encountered this, given a very
common use case of AJAX is injecting XHTML into the DOM.  Thus the
post here.

My initial reaction is to handle this situation by override
Request.success, and if we're dealing with IE, strip any
declarations.  I can certainly do this for my situation, but figured
it may be a value-add to the MooTools community, so I figured I'd
foster some feedback :-)

Off to override Request.success; let me know if anyone else has pros/
cons/alternative suggestions and if they would find such an extension
useful.

Eric

[Sanford Whiteman [Mobile]]

> (I supposed one can argue the intent of the W3C r.e. this line and
> whether it would be applicable to injecting XHTML into another XHTML
> document via AJAX; my point is merely that what I'm doing should not
> be considered all that unusual.)

No  "argument"  need be made! Specs are not magnetic poetry: you can't
take  the existence of a spec for a full document, flip it around, and
assume that allows you to nest entire documents inside other documents
of that type, ad infinitum.

Most  blatant  here,  a  document declaration is only allowed once per
document.  Period.  There  is  no  way  to  have a well-formed X(HT)ML
document  that  has  a  declaration  hanging  out in the middle of the
document.  It  is not simply a question of an out-of-place declaration
being  ignored:  the  construction  <?xml ?> is totally invalid markup
anywhere else.

You're  also  trying  to  use  DOM  2 (X)HTML to work with generic XML
documents,  an  additional  mismatch. The behavior of DOM methods when
dealing with invalid (X)HTML is specifically left up to the User-Agent
in the DOM 2 HTML spec.

In  sum,  it *is* unusual to try to shoehorn (invalid) well-formed XML
structure *inside* an existing HTML document, and there is no standard
way  that  you  should  expect  browsers to behave. That IE decides to
interpret  your  injected document as a special XML object has its own
consistency.  Not  that I agree with it -- I think a hard error should
be  thrown  in  all  such cases -- but it is allowed to. You say other
browsers deal with this "elegantly." Really? What do they do with your
declaration? Do they silently delete it? What if the injected document
has  a  different encoding from the parent -- does the parent encoding
change  to  match  the newest content? Which DTD is used? Whatever you
think  is  elegant is just non-standard guesswork, and may not conform
to a particular user's expectations any more than IE's behavior does.

-- Sandy