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

Re: [XHR2] text/html and responseXML

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 30 Jul 2007 16:00:14 -0700
Cc: Anne van Kesteren <annevk@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-Id: <C40E8FC0-71E3-472F-ACFC-465413CAB0BC@apple.com>
To: Jonas Sicking <jonas@sicking.cc>


On Jul 29, 2007, at 1:27 PM, Jonas Sicking wrote:

> Maciej Stachowiak wrote:
>> On Jul 28, 2007, at 4:04 AM, Anne van Kesteren wrote:
>>>
>>> Jonas already mentioned it in another e-mail and this feature was  
>>> indeed planned (by me 8-)) for XMLHttpRequest level 2.  
>>> responseText already follows text/html rules for encoding  
>>> detection etc. but for parsing we probably need to state that it  
>>> needs to run with support for scripting disabled which affects how  
>>> <noscript> is parsed etc. I'm wondering if we should do it like  
>>> that or have scripts not run and parse <noscript> as if scripting  
>>> was enabled. (I'm not sure whether HTML 5 has an option for the  
>>> latter, but that's for instance how html5lib currently works.)
>>>
>>> Any opinions on this? Anything else I should pay attention too  
>>> when adding this feature?
>> I would guess a popular use would be to grab HTML fragments and  
>> insert them into the current document, in which case it would be  
>> desirable to parse as if <noscript> was not disabled. I'm also not  
>> sure that scripting needs to be disabled, at least in the non-cross- 
>> domain case. I could imagine interesting uses for either.
>
> The author always has the option of not including <noscript>  
> elements in their response, so I think the usecase is still supported.

The author of the page using XMLHttRequest may not be the same as the  
author of the page being requested. I'd guess a common use would be to  
grab the HTML of existing pages, not ones custom-authors just for XHR  
access.

> 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.

Regards,
Maciej
Received on Monday, 30 July 2007 23:00:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:58 GMT