W3C home > Mailing lists > Public > public-webapi@w3.org > August 2007

Re: [XHR2] text/html and responseXML

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 2 Aug 2007 09:40:15 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, "Web API WG (public)" <public-webapi@w3.org>
Message-Id: <F34EABCF-6341-424F-A8F7-478AC622C9FB@apple.com>
To: Anne van Kesteren <annevk@opera.com>

On Aug 2, 2007, at 6:12 AM, Anne van Kesteren wrote:

> On Tue, 31 Jul 2007 01:00:14 +0200, Maciej Stachowiak  
> <mjs@apple.com> wrote:
>>> I'm a little bit worried that if we enable scripts for XHR (they  
>>> are currently disabled in firefox) that sites would break. Though  
>>> chances are probably pretty small. However if scripts are enabled  
>>> we need to define exactly in which context they execute. Should  
>>> they have their own 'window'? If not 'window.document' would not  
>>> refer to their own document.
>> Yes, I'm not really sure if it's a good idea, but we should  
>> consider the pros and cons of both options.
> I tend to agree with Niklas Åkerlund that XMLHttpRequest is for  
> fetching a single resource (of data). If we'd execute scripts in  
> that resource per the HTML parser that would mean that other  
> resources have to be loaded as well. In my current copy of  
> XMLHttpRequest level 2 I have written that the parser should run  
> with support for scripting disabled for that reason. (I'll hope to  
> check in a copy once I've clearly marked outstanding issues, maybe  
> later today.)

Does this mean that the following should also apply:

<link rel="stylesheet"> will not trigger stylesheet loads
<iframe> will not load the linked document
<img> will not load its image contents

The last is particularly tricky, since right now in browsers an HTML  
IMG element always tries to load its image, even when not in a document.

Perhaps a good thing to test would be what thesese kinds of elements  
do if you put them in an XML response in the XHTML namespace, for  
browsers that support XHTML.

Received on Thursday, 2 August 2007 16:40:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:57 UTC