In the send() algorithm:

 │ ↪ data is a Document
 │
 │     Let data be data.innerHTML as defined by section 2.5 of HTML 5.
 │     Encode it using data.inputEncoding or UTF-8 if
 │     data.inputEncoding is null. Re-raise any exceptions the
 │     data.innerHTML getter algorithm raises. [HTML5]

The innerHTML getter algorithm requires that an explicit xmlns=""
attribute is present for elements in no namespace, instead of relying on
the fact that if there is no xmlns= attribute one of the
ancestor-or-self::* elements that it defaults to being in no namespace.
This means, for example, that the following:

 var doc = document.implementation.createDocument(null, "test", null);
 var r = new XMLHttpRequest();
 r.open("somewhere");
 r.send(doc);

would send the string '<test xmlns=""/>' (or something equivalent, but
the xmlns="" would have to be in there).  Do (m)any existing XHR
implementations serialise the document in this way?  Is there any
benefit from requiring this?  The rest of the innerHTML getter algorithm
looks fine (where it deals with unserialisable nodes).
This seems like a comment that should be directed at the HTML WG:

  [EMAIL PROTECTED]

No, it’s specifically a comment about XHR.  For HTML this behaviour
makes sense, because people want to do

  x.innerHTML = y.innerHTML;

and have the serialisation returned by innerHTML not dependent on
context for namespace declarations.  This isn’t an issue for XHR, and
since existing UAs don’t do this (Opera 9.5, a nightly WebKit, Firefox
3rc1, but untested in IE since I dunno how to create an XML document
without using document.implementation.createDocument()), it seems to be
needlessly incompatible.  Perhaps XHR can say that that requirement of
the innerHTML serialisation algorithm (explicit xmlns="") need not be
followed.

I wonder if this can be fixed in the HTML5 spec to say that when serializing a whole document, no xmlns="" attribute needs to be inserted.

/ Jonas

Reply via email to