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
