[Bug 9767] Consider ignoring document.write() when IE ignores it if comes from the network task source

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767





--- Comment #22 from Henri Sivonen <hsivonen@iki.fi>  2010-07-16 09:00:00 ---
(In reply to comment #21)
> I don't understand how the spec is racy with the parse. Can you elaborate?

I didn't read the spec changes carefully enough.

> Your proposal seems to affect far more scripts than necessary. I hadn't
> realised you meant to affect so many scripts. Is that really necessary? Why
> would we want a timeout inserted an external script that uses document.write()
> to be ignored? Surely the ideal here is to have as small an effect on the
> overall model as is possible while still resolving the compatibility problem.

No, that's not the ideal. There are some cases that need write-neutralization
for compat. Presumably, there are other situations that must not be
write-neutralized for compat. 

It's possible that there's a set of cases in between that don't matter either
way for compat. You are going for no change there just in case. My view is that
the ideal is to go for simplicity in the cases that don't matter.

The problem is, of course, that I'm not sure if I have guessed the boundaries
of the "don't matter" cases right.

Do you have data showing that sites depend on document.writes from
timeout-inserted scripts blowing away the document? OTOH, I have seen a data
point showing that it's desirable to write-neutralize external scripts that
have the defer attribute set when they try to write in their owner doc.

While I'm well aware that Web sites depend on all sorts of crazy stuff, it
still seems implausible that sites would depend on being able to blow self away
by inserting a createElement-created external script. (OTOH, it seems totally
plausible that sites are depending on the implied .open() behavior when calling
.write() cross-browsing contexts.)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 16 July 2010 09:00:06 UTC