[KLUG Members] Win32 IE vs MacIE and standards compliance isues.
Justin Buist
members@kalamazoolinux.org
Thu, 16 Jan 2003 18:16:49 -0500
Forword: I originally intended this to be a short example, but it kind of
exploded. If you're intersted in MSIE oddities and how frustrating they can be
read on, if not, just skip this one.
------------------------------------------------------------------------------
While I'm spitting out anecdotal MSIE stores, here's a fun one for you, and it
come right from MSIE's tendency to let developers do things that it shouldn't.
Take the following HTML/JavaScript sample:
<html>
<head><title>Hello, IE!</title>
<script language="JavaScript" type="text/javascript">
function recalc(i) {
alert(i + 2);
}
</script>
</head>
<body>
<form>
<input type="button" onClick="recalc(2);">
</form>
</body>
</html>
One would think that upon clicking the button the recalc() function would
run and you'd see an alert box with 4 in it, right? It does in Mozilla, but
why won't IE run recalc()? It doesn't even toss out an error!
Ohhh... MSIE likes to match functions against document. in the DOM first, as
most developers are too lazy to fully qualify their objects. So, MSIE will
call document.recalc() for you, because that's what you -really- wanted, which
just re-parses the HTML tree and refreshes the DOM model of the page.
That took a couple of hours to figure out. Finally discovered it when I
renamed the function to "whythefuckwontthiswork" and it magically began working
in IE. And no, we didn't push the code out the door with my colorful name :)
Nobody really knows the order with which IE begins looking for unqualified
elements in your DOM either -- at least nobody that I've ever worked with, nor
have I found an authoriative reference it on either.
Semi-related, a while back MS released a patch for IE to keep JavaScript from
hopping up the DOM and back into another document's properties for security
reasons, so code like:
parent.frame[0].document.frmLogin.txtPassword couldn't be accessed. Funnily
enough, a few days later an update to the patch was issue further fixing the
issue. Apparently the MS team never thought somebody would try:
parent.frame[0].Document.frmLogin.txtPassword. That one worked until the 2nd
update. Crikey. Makes you wonder though, just how well the whole patch was
really done. I suspsect somewhere non-security violating code that had been
written with a Document suddently stopped working. Looks like they just put in some magic string filters in their JavaScript engine than fix the real problem, but nobody knows for sure.
Justin Buist
On Wed, Jan 15, 2003 at 11:23:41PM -0500, Bryan J. Smith wrote:
> I understand differently. It's just that the Mac version is not only
> missing the Win32-only components, which are the default preference on
> Windows. Again, MS IE 5.x at the core is very standards compliant. It
> just refuses to use them unless it absolutely has to.