2010-01
27

挽救杯具

By xrspook @ 20:35:55 归类于:烂日记

昨天,知道了原来我们粮库也有网站,迫不及待地去观摩一下。汗!我用的是FF,结果呢?中国人做的网页就是对IE以外的浏览器水土不服,于是,汗,再汗……

网页是个需要测试测试再测试的东西,内容当然很重要,但如果不同用户不同浏览器出来的效果不一样呢?杯具……在中国人设计的网页中,非IE不可是习惯性真理性的,比如说大名鼎鼎的备案网站,又比如同样如雷贯耳的网上支付网站,巨汗!地球人都知道IE的安全性不好,速度不优秀,但,勤劳勇敢机智过人的中国人就喜欢用系统自带原汁原味,甚至还没经过升级到7或8的IE,果然是微软的忠实粉丝啊!

但,我们某些人的思维是发散的,面向的是世界各地的盆友。在外国盆友设计的网页中,基本上FF横行,是推荐用浏览器,比如说我用的WP模板的作者。显然,他老人家视IE为无物。请看下图:


这是IE的截图。


这是FF的截图。

左图是我千辛万苦经过修改后的IE适应版,右边是原版。杯吧,原版在IE下,3栏的设计都变成2栏了,2个侧栏“被迫”挤到了一块,肯定是和背景不搭调的,揪心啊!

为了挽救这恐怖的杯,我首先请来了Firebug大人。


模板,显然,是div的,样式肯定是CSS的,而问题就发生在content-body、content-sidebar-2和content-sidebar里。首先,我在content-sidebar的CSS里加了一句“float:right;”,解决了content-sidebar在IE里跟在content-sidebar-2屁股后面的问题,实现右置。但为什么升不上去呢?难道因为太窄?我尝试修改过很多宽度都不行,看来不是位置不够的问题。会不会是content-sidebar里有“clear”的命令呢?应该不会。如果有的话,在FF就不会正常了。中间部分三栏设计,我们可以用3个float来解决问题,于是我试探性地在content-sidebar-2里加一句“float:right;”惨了,占到了最右方,当然,因为它的层在content-sidebar之前,理所应当占最右边。那如果改为“float:left;”呢?我的设想是它或许会正常,如果content-body已经设定为“float:left;”的话,怪异的是,在IE下正常,在FF下content-sidebar-2抢到了正文的左边。问问Firebug,虫子说content-body里有个“float:none;”的设置。怎么可能,我已经把CSS文件里所有content-body都加上“float:left;”,怎么有可能还是“float:none;”!!!!但如果不存在,Firebug不可能爬虫出来,到底在哪里呢?无计可施之下,找起了网页源文件,居然,居然被我在网页头部找到这等东西!!!


实在太杯具,灰常杯具啊!文件头,居然放在文件头,无语了。在WP的header里找,没找到,最后终于在function里找着,我的老天,该死的“none”!于是,终于用3句float解决了IE怪异的效果,让中国人看到的效果和外国人相似。

哎,如果大家用订阅的话,版面什么个鬼样又有什么关系呢。

2010-01
14

累但快乐着

By xrspook @ 23:59:58 归类于:烂日记

昨天晚上我是凌晨一点回去睡觉的。

今天晚上我是凌晨一点离开办公室的,还没洗澡,躺在床上的时候已经是凌晨一点半。

我很累,在上班时间里被检验、文档排版、数据抄写榨干。下班后,成为小村屋群的义务核心技术员,被代码转化和CSS修整榨干。CSS修整本是很简单的事,FF+Firebug+css code就能得心应手,需要做的就只是修改和刷新,但是,偏偏某村友的blog用的插件却把该死的CSS可视化了,分开一小段一小段,加上说明,却不显示最最原始的代码,还得让你一个个翻,要多按好多次保存,还经常会找偏。结果最后我气了,直接用Firebug去找我要找的地方,在自定义的CSS里敲打一番,嘿,终于可以了,真邪恶!

今天的重头戏是帮一位有困难的村友搬家,听村屋首领说他帮忙搬的时候失败了,于是,在危难的时候,当大家有需要我的时候,xrspook挺身而出了!接到从BlogBus弄出的代码,马上用Python转换,得出如下结果:


很诡异,我之前遇到的错误代码可不是这样的哦。我第一个反应是时间有问题,应该是某个设定的时间不对劲,但到底在哪里呢?94、268、371、376(此数字为行数)我都排查过,没有。于是,我第二个反应是人肉排查替换。把376以前的先删掉,转换后面的。OK,没问题。再把前面的转换,同样结果。接着,把94-376的删掉,转换94以前的,一切正常。然后,把94-376的转换,嘿!还是那个界面,但现在根本就不存在376啦!所以我意识到从那些行根本不会找到突破口。重复以上操作大概3、4以后,剩下3篇文章,卡住。剩下2篇!最后一篇!肯定是这里的问题。村友们,你知道我发现什么了吗?见下图:


LogDate包围的日期居然是0000-00-00 00:00:00!!!!难怪Python会报错!而这等事情是怎么发生的呢?fish故意的吗?不是,是BlogBus可以算bug也可以不算bug的地方。为什么这么说呢?因为我是那种在记事本写完日志往blog上贴的人,记事本时间提取是用F5,只有yyyy-mm-dd hh:mm,而BlogBus的格式是yyyy-mm-dd hh:mm:ss,所以,我就要把前面的粘上去,留默认的秒数,但如果我一不小心粘错粘漏了呢?BlogBus会默认把时间设定为0000-00-00 00:00:00!于是,发现新文章不见了的xrspook就会翻到日志的最后一页把那个莫名其妙的日期改回来。大概当时fish没发现这等问题,以为是自己出错了就没去理会,所以,导出数据中就存在了个那么匪夷所思的日期。程序是认规律不认人的,它觉得年一定是从1开始,月只有12个数,日是1-31,若超出范围,它就笨蛋不懂了,前提是,它不会BlogBus的日期潜规则,若有人让它增强读取BlogBus的潜规则并把那个诡异数转化为转换当场时间的话,杯具就不会发生。所以,看来很严重的问题,把几个0改为正常数就行。解决方法很简单,但查找就异常曲折。成功那一刹那我是多么的高兴啊!!!

信心满满地把转换好的数据传给村屋首领,却又出现怎么都导入不了报错的现象。难道fish就那么背?在多次尝试,包括重装WP之后,首领提出会不会是导入.xml的格式不对,解释错误导致报错?接着,我发现他装的居然是2.8.5,我转换用的是2.8.6啊!转出来的数据适用于2.8.6后(即2.9系列),新数据导入老系统,不错就见鬼了。于是,我把经过一层转换的导进去,问题解决。大功告成,村友们,我们狠狠地拥抱一下吧!

以前都是自己解决自己的问题,或者请求别人解决自己的问题,但这次居然是xrspook帮助他人解决问题,真让人有飘飘欲仙的感觉。几个即时通讯工具闪个不停~~~

妹爱的不是钱,妹爱的是成就感!

于是,你知道我为什么乐了:)

Page 1 of 11
COPYRIGHT @ 我的天 | Theme by xrspook | Power by WordPress | Valid XHTML 1.1 and CSS 3 Go to top