我想在写这篇文章之前,已经有无数的难友被IE折磨得痛苦不堪了.
下面就将我自己用IE的问题作个小结:
1.div 无法覆盖select 表单的问题
痛苦指数
解决办法:
各路大仙真是仁者见仁,智者见智,归纳起来主要有两种
a. 隐藏法
计算select附近的div,如果发现div重叠,就赶紧隐藏select,典型代表 : www.dynarch.com/projects/calendar/
b.替换法
干脆用div + table 重写个select得了
Ext做得不错,提供了对select的refresh方法 www.extjs.com
2.缺少有效的脚本调试支持
痛苦指数
对于B/S的 B端开发人员来说,脚本调试器简直就是小李手的小刀.
相对于firefox下的firebug addons.mozilla.org/firefox/addon/1843
IE的解决办法就是安装庞大的 InterDev , 或者目前的.net frame,就算是这样的庞然大物,
程序无响应也是经常的事情.
解决办法:
偶的解决办法,就是写跨浏览器的脚本,在ff下调试完了再往IE下移。
如果只在IE下出问题咋办? ———alert!!!!!
3.低性能
痛苦指数
如果你用过这个 www.scbr.com/docs/products/dhtmlxTree/index.shtml
如果你的书有上千个节点, 一定就会有所体会了,
在同一个页面里将几个图片重复利用几千次?
对不起,在IE中你不得不等待"xxxx"个图片正在下载。
我就弄不懂,同一个页面里的对同一个img的url引用,有必要每次都去检查更新么??
解决办法:
把访问策略设置为“自动”吧,第一次的慢嘛只好忍受了。
提及低性能,有个有趣的实验一定要做——将几千行的纯文本粘贴到 IE 的textarea中试试看,
一定会给你一个惊喜。
4.自作主张
痛苦指数
如果你调用getElementById,而ie未发现此id,那么它就会去找name为此id的元素并返回给你,不报任何错误。
解决办法:
写程序小心再小心
5.内存泄漏
痛苦指数
在页面中通过js反复创建和删去Div,ie6会出现内存泄漏,甚至重启ie仍然无济于事。
这个真是RIA的噩梦啊!!
RIA常用的手段就是利用div模拟窗口,因此div的创建和释放是最基本的操作。
解决办法:
参考Ext的destory机制
我的办法就是div复用,建一个就不放,重复利用。就算这样,由于窗口内容的刷新同样需要动态建立和释放html元素,
仍然存在内存泄漏。
6.兼容性差
痛苦指数
这个问题是前一段在客户那里发现的,微软2003拼音输入法,与ie下textarea的刷新冲突。
大家可以用下面这个最简单的页面看看效果
当使用微软拼音2003的逐词提示,ie无法正确判断出刷新区域,干脆就将整个页面从背景到各层div逐个刷新的一遍。
导致屏幕狂闪。
让人哭笑不得的是,在firefox下居然一切正常。
7.容错性差
一个utf编码的页面通常有如下两句开头:
天天用firefox但每次回家依旧无耻的用ide的家伙报道。
主要是用web迅雷下片,还有在qq空间给mm留言
对了,还有开心网有个争车位。flash在firefox底下显示不出来
是的是的.我以前用linux一年.后来实在坚持不下去了.原因就两个:网银不能用.淘宝旺旺不能上.
别拿欧洲说事.这里是中国.只要在IE上跑起来,很少有客户会挑毛病.
你的这个说法是以自己的臆想代替真实的数据。
得,用w3m上网就好了,啥都不封装。
兼容,谈何容易...
可是客户用IE的还是比较多。。。目前都是FF调试,最后以IE为主,如果不行兼得...IE为主
javaeye的情况,我们问robbin吧!
同意,我就经常那么做
关于调试工具,我一直用office自带的MSE7,感觉还好
<br/>
能解决Java Applet 总是覆盖div的问题么:<br/>
一个弹出的div窗口总是被java applet覆盖,fx和ie下都有这个问题
我之前用YUI试过一个次,总共有几万个节点。火狐和ie都死了。
其实,当你需要用树状结构来显示大量信息的时候。就应该想想有没有更好的方法?
我后来改用别的方法了。因为在一页面上弄那么多节点出来,用户用起来根本就不方便。
下面就将我自己用IE的问题作个小结:
1.div 无法覆盖select 表单的问题
痛苦指数
解决办法:
各路大仙真是仁者见仁,智者见智,归纳起来主要有两种
a. 隐藏法
计算select附近的div,如果发现div重叠,就赶紧隐藏select,典型代表 : www.dynarch.com/projects/calendar/
b.替换法
干脆用div + table 重写个select得了
Ext做得不错,提供了对select的refresh方法 www.extjs.com
2.缺少有效的脚本调试支持
痛苦指数
对于B/S的 B端开发人员来说,脚本调试器简直就是小李手的小刀.
相对于firefox下的firebug addons.mozilla.org/firefox/addon/1843
IE的解决办法就是安装庞大的 InterDev , 或者目前的.net frame,就算是这样的庞然大物,
程序无响应也是经常的事情.
解决办法:
偶的解决办法,就是写跨浏览器的脚本,在ff下调试完了再往IE下移。
如果只在IE下出问题咋办? ———alert!!!!!
3.低性能
痛苦指数
如果你用过这个 www.scbr.com/docs/products/dhtmlxTree/index.shtml
如果你的书有上千个节点, 一定就会有所体会了,
在同一个页面里将几个图片重复利用几千次?
对不起,在IE中你不得不等待"xxxx"个图片正在下载。
我就弄不懂,同一个页面里的对同一个img的url引用,有必要每次都去检查更新么??
解决办法:
把访问策略设置为“自动”吧,第一次的慢嘛只好忍受了。
提及低性能,有个有趣的实验一定要做——将几千行的纯文本粘贴到 IE 的textarea中试试看,
一定会给你一个惊喜。
4.自作主张
痛苦指数
如果你调用getElementById,而ie未发现此id,那么它就会去找name为此id的元素并返回给你,不报任何错误。
解决办法:
写程序小心再小心
5.内存泄漏
痛苦指数
在页面中通过js反复创建和删去Div,ie6会出现内存泄漏,甚至重启ie仍然无济于事。
这个真是RIA的噩梦啊!!
RIA常用的手段就是利用div模拟窗口,因此div的创建和释放是最基本的操作。
解决办法:
参考Ext的destory机制
我的办法就是div复用,建一个就不放,重复利用。就算这样,由于窗口内容的刷新同样需要动态建立和释放html元素,
仍然存在内存泄漏。
6.兼容性差
痛苦指数
这个问题是前一段在客户那里发现的,微软2003拼音输入法,与ie下textarea的刷新冲突。
大家可以用下面这个最简单的页面看看效果
js 代码
当使用微软拼音2003的逐词提示,ie无法正确判断出刷新区域,干脆就将整个页面从背景到各层div逐个刷新的一遍。
导致屏幕狂闪。
让人哭笑不得的是,在firefox下居然一切正常。
7.容错性差
一个utf编码的页面通常有如下两句开头:
xml 代码
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- title>费力佩五世巧克力壶</title>
这样写是没有问题的,可以如果调换这两句的顺序,ie就整个晕了,不仅分析不出title不说,
后面的分析也全乱了,由于不知道编码,报出乱七八糟的错误.
高版本的ie6解决了此问题,我的ie6.0.2900.2180存在问题.
总结到此,欢迎大家补充!
当然以上问题出现在目前应用较广的ie6上,ie7已经解决了大多数问题。
但试想如果没有那只火狐狸捣乱,我们能指望用上ie7么?
反过来也是一样,如果当年netscape一枝独秀,情况怕也好不到哪里去。
所幸世界正在向着多元化的方向发展。
评论
58 楼
easyroom 2008-08-22
引用
kamiiyu 写道
我想只要坚持用ff一星期的人,这辈子不会再用ie
firebug的确很好用
firebug的确很好用
天天用firefox但每次回家依旧无耻的用ide的家伙报道。
主要是用web迅雷下片,还有在qq空间给mm留言
对了,还有开心网有个争车位。flash在firefox底下显示不出来
能拯救IE的只有微软.
我能做仅仅是在页面上放上一句话:
Firefox下降获得更好效果
并加上Firefox的下载链接.
而对于问题...............硬着头皮调试吧,问狗吧.......
我能做仅仅是在页面上放上一句话:
Firefox下降获得更好效果
并加上Firefox的下载链接.
而对于问题...............硬着头皮调试吧,问狗吧.......
深有同感
关于树的问题 我自己写的树 在ie上极限是7000节点 ,主要瓶颈就是图片,原来图片放在包里,写个缓存机制服务端客户端都缓存,发现最快的还是静态图片链接,由容器直接处理,而火狐却依然很快,我也没有再测
网上的梅花雪树“一次性”加载却没有懒加载的要求,像csdn上的树就是用它做的,感觉怎么那么一点就很慢似的
关于树的问题 我自己写的树 在ie上极限是7000节点 ,主要瓶颈就是图片,原来图片放在包里,写个缓存机制服务端客户端都缓存,发现最快的还是静态图片链接,由容器直接处理,而火狐却依然很快,我也没有再测
网上的梅花雪树“一次性”加载却没有懒加载的要求,像csdn上的树就是用它做的,感觉怎么那么一点就很慢似的
真是严肃的问题,做了些日子跨浏览器程序开发都要疯了。在ie8下的,在ie6
下怎么都出错。
做ie开发就要本着没有特效,没有脚本,没有firefox兼容。
下怎么都出错。
做ie开发就要本着没有特效,没有脚本,没有firefox兼容。
总结的不错
1、大量的节点,需要ajax,至少也要是延迟加载
2、js调试,.net带了一个调试器,很棒,一级棒,可以断点,监视,条件,单步,查看所有变量,甚至可以倒退(这个一般言语的开发IDE都没有)。
缺点:目前好像只能调试IE,而且不能查看com对象或是activex的属性。
1、大量的节点,需要ajax,至少也要是延迟加载
2、js调试,.net带了一个调试器,很棒,一级棒,可以断点,监视,条件,单步,查看所有变量,甚至可以倒退(这个一般言语的开发IDE都没有)。
缺点:目前好像只能调试IE,而且不能查看com对象或是activex的属性。
48 楼
mooniscrazy 2008-01-12
引用
拯救个p,c语言写的东西,从头到尾都是垃圾。ie需要用c#重写,才可能真正安全。
据最新的测试表明,貌似IE7的Javascript性能很好,而且,又有消息指出,IE8的Strick模式已经完全通过了Web标准化测试。
如果说有人可以左右“标准”,那么,我想它应该会是“IE”。此外,既然连IE都在往标准的道路上靠近,我们就更加没有理由不想信它会做的很好了。
如果说有人可以左右“标准”,那么,我想它应该会是“IE”。此外,既然连IE都在往标准的道路上靠近,我们就更加没有理由不想信它会做的很好了。
yueguangyuan 写道
IE令人讨厌之处就是自己封装了太多东西,搞个什么ActiveX,Linux上最反感的就是那个令人伤心的网银,刚好黑客最喜欢黑ActiveX。
还有就是国内更多的网站都是IE Only,很多网站都显式不正常,这个只能等待国民素质慢慢提高,盗版少了,自然而然的IE的统治地位就会下来
我们公司开发时都是先兼容FF,然后才会考虑IE
还有就是国内更多的网站都是IE Only,很多网站都显式不正常,这个只能等待国民素质慢慢提高,盗版少了,自然而然的IE的统治地位就会下来
我们公司开发时都是先兼容FF,然后才会考虑IE
是的是的.我以前用linux一年.后来实在坚持不下去了.原因就两个:网银不能用.淘宝旺旺不能上.
BaSaRa 写道
FF在欧洲推广速度很快,某些地方甚至到达49.7%的市场占有率,当然这个数字可能有假,但是还是建议兼容FF
别拿欧洲说事.这里是中国.只要在IE上跑起来,很少有客户会挑毛病.
IE上运行的JS性能低下,以及内存泄漏等,主要原因是由于IE的内存垃圾回收机制问题造成的,创建的对象越多,速度就越慢。
http://ajaxian.com/archives/garbage-collection-in-ie6
所以在IE上,尽可能少的创建对象(尤其是DOM对象)才是解决效率问题最关键的手段。
如果无法避免创建DOM对象,自己总结了几点:
1、IE提供了许多非DOM标准的方法,有些方法的效率要比标准DOM方法高很多,尽可能使用这些方法。
2、对象使用过后及时释放(将变量设为null),可以减少内存泄漏,也可能帮助提高性能。
http://ajaxian.com/archives/garbage-collection-in-ie6
所以在IE上,尽可能少的创建对象(尤其是DOM对象)才是解决效率问题最关键的手段。
如果无法避免创建DOM对象,自己总结了几点:
1、IE提供了许多非DOM标准的方法,有些方法的效率要比标准DOM方法高很多,尽可能使用这些方法。
2、对象使用过后及时释放(将变量设为null),可以减少内存泄漏,也可能帮助提高性能。
IE下也有类似Firebug的Dom Inspector,一个叫ViewPage的插件,还不错.不过感觉还是先FF再移向IE比较好.
mcpssx 写道
没有FF之前,兼容什么?
虽然我也基本以FF为主,
但这个做法明显是以自己的喜好代替大众的选择!
虽然我也基本以FF为主,
但这个做法明显是以自己的喜好代替大众的选择!
你的这个说法是以自己的臆想代替真实的数据。
yueguangyuan 写道
IE令人讨厌之处就是自己封装了太多东西,搞个什么ActiveX,Linux上最反感的就是那个令人伤心的网银,刚好黑客最喜欢黑ActiveX。
还有就是国内更多的网站都是IE Only,很多网站都显式不正常,这个只能等待国民素质慢慢提高,盗版少了,自然而然的IE的统治地位就会下来
我们公司开发时都是先兼容FF,然后才会考虑IE
还有就是国内更多的网站都是IE Only,很多网站都显式不正常,这个只能等待国民素质慢慢提高,盗版少了,自然而然的IE的统治地位就会下来
我们公司开发时都是先兼容FF,然后才会考虑IE
得,用w3m上网就好了,啥都不封装。
笨笨狗 写道
我们的目标就是,尽量兼容ff和ie……
兼容,谈何容易...
可是客户用IE的还是比较多。。。目前都是FF调试,最后以IE为主,如果不行兼得...IE为主
32 楼
daminggege 2007-10-18
引用
都是挺现实的问题, 最近做的工作, 画图, ff有<canvas>, ie没有用vml模拟, 用excanvas做桥, 在作者的blog上看到性能差6-7倍, 当图的内容bt点ie就像20帧的cs了, 彻底没法玩
31 楼
yueguangyuan 2007-10-15
引用
厄,扯远了吧,讲功绩,微软还不是靠的捆绑,打倒NetScape,而且Mozilla前身不就是NetScape么?
微软自己罢着浏览器最直接的后果就不思进取,xmlhttp是它搞的没错,但它搞出来又没发挥什么价值,直到别人都用了,它自己才缓过神来追
微软自己罢着浏览器最直接的后果就不思进取,xmlhttp是它搞的没错,但它搞出来又没发挥什么价值,直到别人都用了,它自己才缓过神来追
ls的别那么说,要是没有ie其实mozilla也就出不来了,更别说firefox了,要是没有ie引入xmlhttp什么的,那估计gmail什么的也就出不来了,你说不是吗,可以说没有ie6就没有web的今天,我看是这样的,当然我也是很希望ie6今天彻底消失,大家都ie7,哈
29 楼
yueguangyuan 2007-10-15
引用
IE令人讨厌之处就是自己封装了太多东西,搞个什么ActiveX,Linux上最反感的就是那个令人伤心的网银,刚好黑客最喜欢黑ActiveX。
还有就是国内更多的网站都是IE Only,很多网站都显式不正常,这个只能等待国民素质慢慢提高,盗版少了,自然而然的IE的统治地位就会下来
我们公司开发时都是先兼容FF,然后才会考虑IE
还有就是国内更多的网站都是IE Only,很多网站都显式不正常,这个只能等待国民素质慢慢提高,盗版少了,自然而然的IE的统治地位就会下来
我们公司开发时都是先兼容FF,然后才会考虑IE
afcn0 写道
但是象gmail google maps这些普通应用,ie肯定还是主流,至少6成,上javaeye估计ie也得6成
javaeye的情况,我们问robbin吧!
27 楼
network-eagle 2007-09-18
引用
大数据量的树型菜单 推荐用xtree吧...可以实现分布加载.并且二 三次运行都是先读的缓存.数据就快多了
客户群存在导向,google reader或者使用分类服务,客户很大程度了解web,知道ff的东西要比ie6支持更多,很可能使用ff来使用一些web应用,自然70%就很正常,其实象meebo google word calender这些统计下useragent分布,估计ie占少数,这些应用估计都很在乎useragent统计分布吧
其实关于调试,现在来说已经不是什么很大的问题了,在IE中可以在脚本中用debugger,然后使用VS2005来调试,很直观的。我现在利用DOJO开发项目,对于它里面的那种异步加载进来的脚本文件也能很好的跟踪,但是在FF下用FIREBUG就跟踪不了
最近透露出来的信息,google reader 70%的用户使用FF。而google reader是目前占市场份额最大的在线feed阅读器。
可以得出一个结论,用户群体存在一个割裂的现象。而如果你估计你的用户群体与google reader比较接近,那就绝对不能忽略FF,否则肯定死的很惨。
可以得出一个结论,用户群体存在一个割裂的现象。而如果你估计你的用户群体与google reader比较接近,那就绝对不能忽略FF,否则肯定死的很惨。
FF在欧洲推广速度很快,某些地方甚至到达49.7%的市场占有率,当然这个数字可能有假,但是还是建议兼容FF
D-tune 写道
关于你的第一个问题,可以在div后面创建一个大小完全一样的iframe来遮盖select。
同意,我就经常那么做
关于调试工具,我一直用office自带的MSE7,感觉还好
14 楼
dennis_zane 2007-09-09
引用
没有哪个用户会去完全关注一万多个节点提供的信息?我觉的这个设计是失败的,应当进行内容的细化
我觉得一个当一个页面包含了太多信息的时候,这个页面从设计上来讲就是失败了,我想没有哪个用户有心情或者有耐心来从一大堆数据中查看自己关心的吧。
另外关于applet覆盖div的问题,是否能够用iframe作为底衬解决,我没有遇到过该问题,所以不太清楚,但是从原理上讲应该是可以的
另外关于applet覆盖div的问题,是否能够用iframe作为底衬解决,我没有遇到过该问题,所以不太清楚,但是从原理上讲应该是可以的
可能还是分组,就象google reader并不是所有的rss都一次读近来,而是滚动进入你的viewport才load文章,可能大量节点也得应用类似的方法的
D-tune 写道
至于第二个问题,建议使用js的IDE。<br/>
getElementById和div的释放只能从提高自身代码质量来解决了,其他的IE本身bug,只能期待IE7快出sp吧
<br/>
getElementById和div的释放只能从提高自身代码质量来解决了,其他的IE本身bug,只能期待IE7快出sp吧
<br/>
能解决Java Applet 总是覆盖div的问题么:<br/>
一个弹出的div窗口总是被java applet覆盖,fx和ie下都有这个问题
sp42 写道
据报道,超过5000节点浏览器就会很慢。。
我之前用YUI试过一个次,总共有几万个节点。火狐和ie都死了。
其实,当你需要用树状结构来显示大量信息的时候。就应该想想有没有更好的方法?
我后来改用别的方法了。因为在一页面上弄那么多节点出来,用户用起来根本就不方便。
<br/>
<strong>chen4w 写道:</strong><br/>
<div class='quote_div'> <br/>
3.低性能<br/>
痛苦指数 <img src='/javascripts/fckeditor/editor/images/smiley/msn/cry_smile.gif' alt=''/><img src='/javascripts/fckeditor/editor/images/smiley/msn/cry_smile.gif' alt=''/><img src='/javascripts/fckeditor/editor/images/smiley/msn/cry_smile.gif' alt=''/><br/>
如果你用过这个<a href='http://www.scbr.com/docs/products/dhtmlxTree/index.shtml'>www.scbr.com/docs/products/dhtmlxTree/index.shtml</a><br/>
如果你的书有上千个节点, 一定就会有所体会了, <br/>
在同一个页面里将几个图片重复利用几千次? <br/>
对不起,在IE中你不得不等待"xxxx"个图片正在下载。<br/>
我就弄不懂,同一个页面里的对同一个img的url引用,有必要每次都去检查更新么??<br/>
解决办法:<br/>
把访问策略设置为“自动”吧,第一次的慢嘛只好忍受了。<br/>
提及低性能,有个有趣的实验一定要做——将几千行的纯文本粘贴到 IE 的textarea中试试看,<br/>
一定会给你一个惊喜。<br/>
<br/>
<br/>
<br/>
<br/>
深有感触啊!刚在项目里面设计了一颗树,节点层次很深,数据量也大,我都做成ajax异步取数据了,但是,但是……<br/>
当子节点打开数量一多了,点击父节点隐藏二级菜单的时候,那个停顿真让人受不了,唉,firefox一点问题都没有,怎么会这样?<br/>
<br/>
<span lang='EN-US' style='font-size: 10.5pt; font-family: Wingdings;'><span style=''/></span></div>
<br/>
<br/>
<br/>
<strong>chen4w 写道:</strong><br/>
<div class='quote_div'> <br/>
3.低性能<br/>
痛苦指数 <img src='/javascripts/fckeditor/editor/images/smiley/msn/cry_smile.gif' alt=''/><img src='/javascripts/fckeditor/editor/images/smiley/msn/cry_smile.gif' alt=''/><img src='/javascripts/fckeditor/editor/images/smiley/msn/cry_smile.gif' alt=''/><br/>
如果你用过这个<a href='http://www.scbr.com/docs/products/dhtmlxTree/index.shtml'>www.scbr.com/docs/products/dhtmlxTree/index.shtml</a><br/>
如果你的书有上千个节点, 一定就会有所体会了, <br/>
在同一个页面里将几个图片重复利用几千次? <br/>
对不起,在IE中你不得不等待"xxxx"个图片正在下载。<br/>
我就弄不懂,同一个页面里的对同一个img的url引用,有必要每次都去检查更新么??<br/>
解决办法:<br/>
把访问策略设置为“自动”吧,第一次的慢嘛只好忍受了。<br/>
提及低性能,有个有趣的实验一定要做——将几千行的纯文本粘贴到 IE 的textarea中试试看,<br/>
一定会给你一个惊喜。<br/>
<br/>
<br/>
<br/>
<br/>
深有感触啊!刚在项目里面设计了一颗树,节点层次很深,数据量也大,我都做成ajax异步取数据了,但是,但是……<br/>
当子节点打开数量一多了,点击父节点隐藏二级菜单的时候,那个停顿真让人受不了,唉,firefox一点问题都没有,怎么会这样?<br/>
<br/>
<span lang='EN-US' style='font-size: 10.5pt; font-family: Wingdings;'><span style=''/></span></div>
<br/>
<br/>
<br/>
至于第二个问题,建议使用js的IDE。
getElementById和div的释放只能从提高自身代码质量来解决了,其他的IE本身bug,只能期待IE7快出sp吧
getElementById和div的释放只能从提高自身代码质量来解决了,其他的IE本身bug,只能期待IE7快出sp吧

本文总结了在使用IE浏览器过程中遇到的问题及解决方案,包括div覆盖select表单、脚本调试困难、低性能表现、自作主张行为、内存泄漏、兼容性差和容错性差等方面,并提供了解决办法,旨在提升开发人员在IE环境下的编程效率。
359

被折叠的 条评论
为什么被折叠?



