当前位置:Gxlcms > JavaScript > IE7提供XMLHttpRequest对象为兼容

IE7提供XMLHttpRequest对象为兼容

时间:2021-07-01 10:21:17 帮助过:39人阅读

在IE7的开发中,据说新增加了一个Native对象——XMLHttpRequest。怎么难道开发IE7的"新警察"不知道IE6们都用ActiveX对象XmlHttp吗?XmlHttp出了什么问题,IE7为什么要这么做?原来一切就为了一个简单的兼容而已,但让人感慨颇多。

    IE7提供XMLHttpRequest对象后,当然会继续支持ActiveX对象XmlHttp,这是微软这么几十年来产品升级起码的"素养",丝毫不用我们去担心现在IE上的Ajax应用代码。在Sunava Dutta的blog里,虽然他说了为什么要这么做的初衷,其实就是为了兼容目前的非IE浏览器提供XMLHttpRequest来使用XmlHttp的情况而已。他的一段"蹩脚"的示例代码虽然被一些睛睛火眼的同志挑出了不足,不过我却觉得微软在这些"细枝末节"的问题上,显示出他的真正利害。

    这话又要回到IE和Netscape争霸的岁月,当时如日中天的Netscape是浏览器市场的绝对No.1,微软由于Bill同志起初在互联网战略上打了一个小盹,让那Netscape尝到了一下山中无老虎,猴子称霸王感觉。当Bill发出:我发现互联网上没有微软的文件格式是很危险的,的自省论断后,微软开始了对互联网的进军。当然一个棘手的问题就是绞杀Netscape,当时的Netscape vs. IE就像今天的IE vs. Firefox。前者IE有Windows作为其捆绑的绿色快车,后者有今天大家高举安全、高举W3C大旗的声援呼声,可以说都是对手强大但是来者也都不是善主。

    在这个绞杀战中,微软是比较稳的住气的。因为IE 1.0, 2.0以至3.0(好像NT4.0就带的IE3.0)都完全不是Netscape的对手,就像当初VC++和BCC之间的较量一样,微软是郁闷的。但是微软知道自己当时不敌Netscape,所以在IE的实现做了很多兼容Netscape的设计,因为当时的Netscape也不是软蛋,一手造就了JavaScript,它其实也就是业界的默认标准。这样的情况持续到IE4.0,IE逐渐占据了优势(当然免费+绿色快车的捆绑不是吃素的)而Netscape的衰败已不可避免,这时微软才开始了大刀阔斧的设计自己的DOM,修改HTML解析以及呈现效果,添加新的HTML标签(这之前都是Netscape的活儿),当然对CSS的支持等也就随微软心所欲了。

    今天的IE7支持XMLHttpRequest对象和Firefox死抱所谓的W3C标准形成了一个宣明的对比。前些天,有人在经典的脚本论坛上号召Web开发者抵制Firefox,虽然话语偏激且给人感觉是螳臂挡车,不过他的一些观点我还是赞同的。就是希望Firefox等非主流(其实就是非IE)浏览器,能更多的兼容IE,而不是让Web开发者去想尽办法兼容各种具有细微差别的浏览器。因为从代价上看,由于IE已是不争的胜利者,修改新浏览器的实现是一处修改处处受益的,而让Web开发者去兼容各种浏览器,简直是对广大劳动人民智力、劳力的侮辱。

    当然很多人可能会说标准才是老大,不管什么浏览器都该遵循标准,否则都是bull shit。但现实的情况就是"店大压人、人大压店",其它都是没有意义的。就像今天我们的网络应用技术大多并没有标准而只有RFC,大家不也其乐融融过得很好吗?不扯远了免得成了对标准的讨伐,继续说浏览器的问题。对Firefox这个"后来"这么久的小弟弟浏览器,不管它要想怎么完美支持标准,我都举双手赞成。可是在一些举手之劳的代价上,为什么就不好好的兼容以下目前最普及的IE呢?比如非要用不同的DOM属性名,非要和IE划清界限,你IE独家的什么runtimeStyle、currentStyle等对不起我就是不支持,event也是要搞来和你不一样,反正怎么别扭怎么来。最后效果就是搞的大部分IE里正常的页面,第一次在Firefox里运行都保管歇菜,难道这下大家就都满足了?!

    如果Firefox以及其它非IE内核浏览器,能像微软这样care兼容性问题,那么他们的市场应该更大更有希望。Firefox完全可以提供两种模式来运行,一是标准模式完全遵循W3C,一是IE兼容模式尽可能的兼容IE。这时候用户可以无缝过渡、自由选择,这下它的什么快速、安全的特点才能真正成为压倒性的优势。而在其不同的普及时期选择不同的运行模式来作为默认模式,就可以很好地解决标准推广,和"拉拢"其它IE用户之间的矛盾,而乐而不为呢?

人气教程排行