Re: [XHR] SVG WG LC comments

Hi Anne.

Cameron McCormack:
>> Could you mention here exactly what parts of HTML 5 are depended upon?
>> This would help implementations that wish to implement only the  
>> XMLHttpRequest interface, without for example support for clientside  
>> databases and various other things in the Window object.

Anne van Kesteren:
> Since not everything is fully detailed yet in HTML5 this would be an  
> ongoing process that I rather not do. Also, it should be quite obvious  
> that XMLHttpRequest does not depend on database storage.

OK, it is obvious that database storage isn’t required for the operation
of XHR.  But the spec does say:

  A conforming user agent must support at least the subset of the
  functionality defined in HTML 5 that this specification relies upon,
  such as the Window object and serializing a Document object.

and that sounds to me like a conforming UA must support the Window
object, not a subset of it.

>>  │ When the XMLHttpRequest() constructor is invoked a persistent
>>  │ pointer to the associated Document object is stored on the newly
>>  │ created object. This is the Document pointer. The associated
>>  │ Document object is the one returned by the document attribute from
>>  │ the object on which the XMLHttpRequest() constructor was invoked
>>  │ (a Window object).
>>
>> Since the document attribute is actually from the AbstractView
>> interface, I wonder if there’s a neat way you could reference that
>> interface instead of Window for this, to avoid all of the extra overhead
>> that Window has.
>
> Actually, the overhead that Window has, such as browsing contexts, 
> origin, etc. is vitally important to XMLHttpRequest. Especially when it 
> comes to URI resolution and security.

But in HTML 5 browsing contexts are defined in terms of views, not the
Window object.  Origin seems to be defined in terms of the browsing
context and “the active document of the Window object of the browsing
context from which the XMLHttpRequest constructor was invoked”, but it
looks to me like that text should be s/of the Window object//, so there
shouldn’t be a dependency on Window there.  For URI resolution, you just
need the Document pointer, not the Window.

So I still contend that it’s possible to abstract away from Window,
here.

>> 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:
>
>   public-html-comments@w3.org

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.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 12 June 2008 22:25:35 UTC