Front-end web developer——[to be a better man]
文章字体大小Font Size文章字体大小:12px, 14px

其它

Nov 17

因为最近密谋入手notebook,对notebook的各项指标作了些了解。而键盘布局就是我十分关心内容之一,在这点上,我的宗旨是:凡是左侧的Fn键位于Ctrl键之左的品牌一律排除!

为什么?因为规范!在中国,多数台式机采用的是美式键位布局,虽然当中有些标新立异的脑白金式键盘出现,即使是为了销量而出来忽悠消费者,也万变不离其宗:Ctrl键始终放在键盘主区的最底两边!

而对于notebook,我也不知怎么说,但认为设计Fn键也是为了把小键盘也做上,为了方便,但横竖不整齐的伪小键盘会有多少人用?据我长期观察我所认识的notebook长期使用者(上班也用notebook的程序员)看来,多数人直接地使用上而横排的正规数字键。而Fn键及蓝色数字,反而会让人误会:已经有两个人问过我,为什么按那数字出不来?我说你要用Fn键才会出来,结果是,按了Fn键也出不来。

而数字小键盘的使用,除了某些游戏,如魔兽争霸使用物品,除此之外,使用它最多的就是财务了。我接触过一位40岁的财务,她就用小键盘最多,加减乘除全在上面进行。除了财务使用小键盘多,还有就是商场的收银员了,她们都是小键盘的忠实粉丝。也有用notebook做报表的同事,地方交通局的人员在做年终路线统计时,都拿着notebook集中在一起,但没有一个用蓝色键盘的,至少,他们都是“数字”依赖者,最普通而且工作量又最大的用户,所以,他们买了一个外接的小键盘。而notebook本身的Fn键,我认为是一个设计失误。

早期的notebook,Fn键还是很老到的放在最左侧,方便地让人找到,然后告诉大家:notebook键盘虽小,五脏具全。而事实上,这些蓝色的东西基本是鸡肋!所以,像DELL和HP等品牌,已经把Ctrl键放回原位,而为了继承传统,把Fn键放在不显眼的Ctrl右边,与Win键夹着。

其实,这样好不好,也是见人见智,但有一个小编,搞了个什么十大品牌笔记本电脑键盘布局设计评测,简直就是脑残,居然还有N多网站脑残地转载了。此人是如何帮评测的?他说从百度中找了十大品牌的键盘图片,图片看着清晰就行了,然后看图说话,根本就没用过,就说哪个好啊那个不好的,笑死人了;而且从他的行文看出,口水一大堆,啰哩啰嗦的,还学人家搞评分,说什么Fn键在右侧,长期按这样的Ctrl键会让人手痛,笑死人了!你有什么依据吗?没有,简直就是一派胡言,你把手指长期按在哪一个地方才不会手痛啊,还说扣一分呢。麻烦你了,没有根据的话不要乱说好不好,难怪编辑这个职业会被人家说门槛底。从我认识的好些编辑朋友中看,也有干得不错的,没见过那么胡扯的。麻烦你提高一下职业素质好不好,别把编辑的脸都丢光了。

不管怎么说,在“科技以人为本”的今天,人体工程学越来越受注重,容不得瞎搞。我认为notebook在销售时,除了标明性能配置外,还应该标明键盘的各项规格,要不,买回来却用得个腰酸背痛,偶们职业病又重了 :(

Popularity: 9% [?]

Sep 25

今天我为大家讲一道营养餐饮:蚂蚁白粥。

现在,就让我为大家讲解这道营养餐饮的做法,请大家跟着脚步走过来。

蚂蚁白粥,顾名思义,就是用蚂蚁煮白粥,成分就是蚂蚁数只,加大米数两。大米的多少,按个人食量而定,蚂蚁数量,则按天然配方,由蚂蚁自行爬进大米里给配而成,所以说,这里的蚂蚁是由上帝所赐,请大家好好珍惜。

成分:蚂蚁若干(天然配给)、大米数两(按食量和食用人数而定)

做法:把大米放于床底,数日后,自然会有蚂蚁来访。在开始煮的时候,不用把蚂蚁赶跑,直接进行洗米,搓米。

说到这里,我不得不说说蚂蚁的贡献。蚂蚁虽小,但全身是宝,就营养方面,就含有丰富的蛋白质和矿物质。所谓每天一只蚁,强壮中国人!

根据专家测定,蚂蚁不含三聚氢安,而且蚂蚁的便便有排毒养彦之功效,以白粥为引,食用蚂蚁还可以增强抵抗力。据说,某蒙蚁集团已向某偏远山区小学免费赠送一年的蚂蚁!
某NBA明星说:你看我多强壮,是因为我每天都吃蚂蚁。
某NBA教练说:希望中国人多吃蚂蚁,以后有更多中国人来NBA打篮球!
某送蚁大使说:我最喜欢吃蚂蚁了,所谓蚁多蝼死象,蚂蚁的腿强壮有力,又多肉,经油炸后,比KFC的炸鸡腿还好吃。
你看,吃蚂蚁,真是益处多多。说回搓米这样步,我们在搓米的时候要小心,蚂蚁的身体很轻,会浮起来,这里我们应该把蚂蚁狠狠的搓到每一颗大米上,形成了蚁包米的局势。洗好米后,就可以像平常煮粥那样煮了。大约三十分钟后,一顿美味芳香的蚂蚁粥就完成了,是不是很容易呢?
好啦,今天的节目到此为止,谢谢大家观看,一期再见!
幕后花絮:
我——哇,这米有蚂蚁哦,蚂蚁爱大米!
收皮——怕什么,蛋白质多!
于是,粥就做成了。
——————
无聊的时候侃一侃,请看客笑笑了之。:)

Popularity: 41% [?]

Aug 26

Steve has write an article about faster javascript trim . He had collected many implementations of trim in javascript, and take a test to find the most efficient approach. At last, he wrote a new implementation and it is the fastest!

This article it’s great . And I found this is a very interesting subject. I was stuck on it. But Steve didn’t show up the testing codes, so I build one, with the codes here.

My Testing Page:

In this page, you’ll see three textarea at the top of page. Those are Template String list. The methods are all from faster javascript trim.

About Template String:

The string there is including the same leading whitespace and the same trailing whitespace. and these whitespace is including several kinds of characters like \s,\t,\n,\u3000.

In Firefox and opera, these whitespace are all match by \s, but not in IE. In IE, It is different from \u3000 and \s , So I replace all the \u3000 to \s in IE in order to make all the trim methods can work fine.

You can see the details of the temlate strings by making a simple test. Just double on the method or string list to start , or the start button too.

From the detail column of the result table, you’ll see something like this:

[\s28][有限状态机[...]平稳流畅。][\s61].length(898)

What does this mean? From the left to right, they are the length of leading whitespace, the trimed string, the length of trailing whitespace and the total length of the string before triming.

About the String List:

By the name of the string, you will see what the main different they are. And they are all from the template string area, so you can change them too. For example, the _shortStr and _longStr is from the first template string textarea. The different is, the _shortStr is just one time of the template string, but the _longStr 100 times of it.

Notic: the _bigWhiteSpaceStr string is real a big white leading and trailing space, and the length are 28,028 and 61,061!

Thank you.

This is a javascript practice for me,you can right click and view the page resrource any time. And I am still learning how to make codes better and better, please leave a reply if any suggestions, Thank you!

Popularity: 62% [?]

Aug 16

Iframs很多时候,我们会需要改变一个iframe的地址(src属性),或者使用表单(form)的target在指定的iframe进行提交后,在iframe加载完毕(onload)时立即响应某个操作,以提高WEB应用程序的价值。本文讨论了跨浏览器的iframe onload事件的监听方法。

如果你没时间去阅读全文,可以看解决方案的内容概要:

  1. 同域的页面嵌套,最好的是让内嵌的页面调用父页面的函数,如 window.parent.callparentFunctoin()。
  2. 如果是异域,或者子页面已存在且无法修改,那么:在Firefox/Opera/Safari中,可以直接使用iframe onload事件;而在IE中,可以通过定时器测定子页面的document.readyState,或者使用iframe onreadystatechange事件计算该事件的响应次数。

以上内容基于参考文档: Q239638Q188763.

如果你对这个话题很感兴趣,请一定要继续阅读哦。。。

注[1]:为了使问题更集中,本文所述的<iframe>均直接写在父页面中,对使用document.createElement(“iframe”)或者其它方式建立的iframe不作讨论,因为这样会使问题在IE下变得更加复杂,但只要使用本文的结论,无论何方式下建立的iframe,问题仍然会得到解决。

一个简单的包含iframe的父页面将是如下样子的:

<!DOCTYPE ...>
<html xmlns="...">
  <head>
  <meta ... />
  <title>Iframe</title>
  <body>
    <iframe name="iframe1"  id="iframe1" width="300" height="50" src="#" ></iframe>
    <script type="text/javascript">//codes here</script>
  </body>
</html>

开始:

让我们从一种简单的情形和解决方法开始:

1.window.parent 对象

1.1 调用父页面对象

<!–This is an inner page in the iframe–>
<script type=”text/javascript”>
window.onload=function{ window.parent.iframeCall();}
</script>

在网上找到的方法中,最令人开心的一个,莫过于在能子页面中调用父页面的对象了:

window.parent.callFunciton()。

不过我想:可能这点全地球人都已经知道了。只是这个方法有一个缺点,那就是子父页面必须在同域中。

还有一点,就是前端工程师们需对子页面有修改权;或者,可以请负责此子页面的同事为我们添加一段代码:

<script type=”text/javascript”>
if(window.parent!=window) window.parent.iframeCall();
</script>

把它放到window.onlad中,或者直接放在</body>之前。

注[2]:在对iframe或其它窗口性质的前端编程中,同域名是最完美的先天条件。只要在同一域名中,各个窗口间的对象是共享的,我们完全可以自由发挥,在不同的窗口间来回驾驭。总之,只有想不到,没有做不到。

1.2 异域

在不同域名的页面,浏览器出于安全考虑,几乎完全封锁了页面间的对象来往,这里没有鹊桥,牛郎和织女只能远远想望。当然,用iframe嵌套页面还是可以的,毕竟还可以思念。

面对家族的封锁,罗密欧还是很想见朱丽叶,他在夜里架起梯子抓到朱丽叶的窗前与她见面;在异域的页面嵌套中,子页面总是可以直接改变父窗口的location以防止被嵌套,但父页面对这个一点办法也没有。

当然,子页面除了仅仅永恒地拥有父窗口.location的修改权外,也没有其它了。例如,在IE下,子页面只能直接修改父页面的.location为另一个源:

<script tyle=”text/javascript”>parent.location=”http://anotherPage.com/”;</script>

但无法访问其它对象,如window.name,document等,连location.href等location的子属性就无法访问。当然,在防止嵌套方面,使用top.location会更强大。

但Firefox中,似乎还可以为top.location添加一些东西,但这是在我不严谨的测试中出现过的情况,未经找到相应的权威文档哦。

2. iframe onload 事件

在Firefox/Opera/Safari中,直接使用frame元素的onload事件即可:
document.getElementById(“iframe1”).onload=function(){
//your codes here.
};
只可惜它在IE下经常无效,因为在IE下它最多只能被激活一次,而且无论你有多少个iframe,被激活的也只能是最后一个的。更详细的描述请看:Q239638Q188763

原因
这些事件是在IFRAME内的文档对象模型中激活的,而不是父页面的。在IFRAME加载完毕的时候,这个事件就被激活了,而且ReadyState已经是“完成”状态。所以你无法通过这个事件来查检一个IFRAME是否加载完毕。

为了得到更好的表现,我们再稍稍研究一个问题:IFRAME递归。

3.IFRAME 递归

在处理IFRAME时,浏览器应该有一个基本规则,那就是防止递归,防止页面无限的自我加载,使客户端设备崩溃。事实上,文中出现的几个浏览器均做到这点,只是不同的浏览器有不同的处理方式。请分别尝试以下代码:
<iframe src=”” onload=”finish()” name=”iframe1”></iframe>
<iframe src=”#hashonly” onload=”finish()” name=”iframe2”></iframe>
<iframe src=”?search” onload=”finish()” name=”iframe3”></iframe>
<iframe src=”http://anotherPage.com” onload=”finish()” name=”iframe4”></iframe>
执行的结果是,在父页面加载时,上面的iframe onload函数在IE/Opera/Safari中均会被激活,Firefox对第二个没有反应。这主要因为他们在防止递归方面的处理是不同的。
对于#hashonly和?search这样的URL,浏览器会解释为页面本身。但hash和search的不同之处是,改变 search可以组成新的源,而改变hash不会。通常地,浏览器一遇到同源的iframe内页即会停止加载,但Safari却会加载多一次。
假如把finish()函数写成如下:
var finsh=function(){alert(”onload from :”+this.src);}
运行时分别弹出的消息弹出框的次数如下:

ifm/brw:    IE    |    Firefox    |    Opera    |    Safari
iframe1:    1     |       1       |      1      |      0
iframe2:    1     |       0       |      1      |      1
iframe3:    2     |       1       |      2      |      2
iframe4:    1     |       1       |      1      |      1

再结合页面所呈现的内容,可得看出这些浏览器在处理递归问题上的一些细则:

  • Firefox 不会在iframe中加载任何东西和激活onload事件(可能是任何事件)
  • IE和Opera不会在iframe中加载页面,但会激活onload事件。
  • Safari(windows版本)会在iframe中加载页面一次且仅仅一次,并会激活onlaod事件且仅激活依附在父页面上那个iframe的onload事件。

关于本节,如果仅把iframe用于页面嵌套,那意义不大;如果用于动态加载/呈现内页,或者用于良好用户体验的form target表单提交处理(不是Ajax),并且要求较高的浏览器兼容性时,作用才会显示出来。根据本节结果,为了提高兼容性,最好事先把iframe指向一个空页面——blank.html,因为它在4种浏览器中的表现是一样的。如果不想事先加载页面,那就得花多点心思去判断浏览器类型了。

4.代码实现

4.1Firefox/Opera/Safari,直接使用iframe onload事件

document.getElementById(“iframe1”).onload=function(){
    //your codes here.
};

4.2在IE下,定时器测document.readyState或者注册iframe onreadystatechange事件

4.2.1定时器以及document.readyState

var fm1=window.frames["iframe1"];
var fmState=function(){
  var state=null;
  if(document.readyState){
    try{
      state=fm1.document.readyState;
    }catch(e){state=null;}
    if(state=="complete" || !state){//loading,interactive,complete
      //onComplete();
      return;
    }
    window.setTimeout(fmState,10);
  }
};
//在改变src或者通过form target提交表单时,执行语句:
if(fmState.TimeoutInt) window.clearTimeout(fmState.timeoutInt);
fmState.timeoutInt = window.setTimeout(fmState,400);

为什么要延时400毫秒?因为javascript对DOM的操作是异步的,我们必须等待脚本对DOM落实执行后才开始下一步。400秒这个数取决与客户端的设备和浏览器的响应速度,好的设备的响应速度能在10毫秒以内甚至更快,但100毫秒左右可能比较大众化,400毫秒应该是十分保守的了。总之,较大的毫秒数能适合更多的用户设备状况,并能减少了客户端设备的工作量。

至于document.readyState,指的是iframe内子页的docuent.readyState,而不是父页面的。只要允许,即在同域情况下,document.readyState会返回5个状态:

uninitialized 对象未初始化.
loading 对象正在加载数据.
loaded 对象已加载完数据.
interactive 在这个状态下,用户可以参与互动,即使在对象未加载完毕也可以
complete 对象已完成初始化.

为什么使用try和 catch?因为在异域的情况下,当iframe的子页到达interactive状态时,父页面就会失去访问权,所以最多只能返回到loaded这一步,因此IE出一个未知错误——其实就是没有权限,所以try和catch,让这个错误沉默下去。

幸好这个方法只针对IE(目前我能使用到的版本:IE6/7),否则麻烦大了:Opera不等页面加载完就开始交互了,而IE会等页面加载完毕才进行交互,所以感觉用Opera打开网页的速度相对比IE快。

4.2.2.onreadystatechange 事件三步曲

var stateID={};
var fmStChange=function(){
  if(ifFirstLoad) return;
  stateID[this.id]=stateID[this.id] ? stateID[this.id]+1:1;
  switch (stateID[this.id]){
    case 1:
      //state loading
      //onComplete(STEP1);
      break;
    case 2:
      //state interactive
      //onComplete(STEP2);
      break;
    case 3:
      //state complete
      //onComplete(LASTSTEP);
      break;
  }
  if(stateID[this.id]&gt;=3) stateID[this.id]=null;
};
$("iframe1").onreadystatechange=fmStChange;
//if you want to ignore the parent page load
//add the following two line
var ifFirstLoad=true;
$("iframe1").onload=function(){ifFirstLoad=false;}

每当iframe加载页面,过程内会激活onreadystatechange事件三次,相应的状态分别是loading,interactive和complete,而最后一次才是complete,所以我们得计算一下,直到第三次才算是完成。

注意:这个方案中的stateID在状态判断时非常重要,要进行必要的修正和保护,如在每次应用iframe时,把stateID[iframe_id]复位为null,或者在第三次响应完成之前,不要对iframe进行新轮页面加载,或者在新一轮的页面加载前消除之前的事件并复位。

Popularity: 73% [?]

Jun 18

感谢对我病情关心的人,特别多谢今天晚上来探望我并带来了苹果、梨和桔子的阿Ken,又要你破费了,这已经不是你第一次为我破费了,十分感谢!这次,除了聊些日常生活话题,还谈及好些工作的细节问题,总之跟阿Ken聊天真是长见识。

还有阿贵,在发现我没踪影后,马上去寻人了解情况,真够兄弟,谢谢!

还有今天在公车上的给我让座的MM,我还是头一次受人让座,迫于当时的情况,我二话没说座了下来,还没来得及给你说声谢谢,我现在要补回:谢谢!

公车上的事是这样的:乘公车去医院,上午10点多了人却还很多,挤压得厉害,空气挺混浊,未到中途便感觉想吐。为了不影响大家,只要公车一停我便下车去吐。畅快!上下一班车继续,以为会好点,结果人还是没少下来,捂着鼻子皱着眉心,支持不住眼看快倒下去,旁边一MM马上招呼我过去,让出了自己的位子。谢谢你,你是我见过的又一个美丽的天使。虽然我对你的容貌已记不清楚,又或者我说出来会让别人认为我很丢脸,但正是这个一座位,让我能坚持1小时的车程到最后,去到了医院,所以,我必须感谢你,在以后的日子,我除了养好身子,还要向你学习,随时向有需要的人伸出缓手。

最后,谢谢所有关心我的人,你们的关注已经成为我最大的动力,谢谢!

Popularity: 54% [?]

Jun 12

上次在异丁烷那里发表评论,输入像这样的代码:<a href=“#”>this is</a>,但Wordpress自动转了,而且在评论显示时变成了一个真正的链接this is,而我只想显示原原本把代码展示给他,害他很辛苦的把诸如“<”这样的符号转换成实体的<了,于是他列了个实体字符表。我说:

这些字符我都知道,只是我很懒的,真希望评论编辑器中会自动转换呀,或者要转换时就转换,不要转换时就不转换。嘻嘻。

他又说:可以反馈给Wordpress开发小组,或者自己写个插件。

于是萌发了写这个插件的念头,到现在也其功能也基本实现了,但要想成为插件,还得做好些工作,而从设计到程序,我已经花了很多心血上去,已经迫不及待地应用到我的博客上,把它展示出来:

点击这里进入评论可看到实物

这个东西目前还支持Ajax Comment Edit插件哦,大家快玩玩吧。

特别说明:

阅读全文(Read the rest of this entry) »

Popularity: 82% [?]

Jun 06

分享网络2.0中看到了Flock,说这是一个基于Firefox核心的浏览器,里面集成了RSS、社会性网络、图片分享以及离线博客编辑等数多具有Web2.0特性的辅助功能,哇,好像很爽的样子,我居然现在才知道!好,马上下载来试用,果然很爽,而且还很酷!

你在看的这篇文章就是直接用Flock的博客编辑器写的,请看截图:
screenshoot

这里从左边可以看到你正在使用的WEB2.0服务,只要你在Flock中进行登陆,Flock就会记录下来。哟,地球上的WEB2.0的服务商还真多呢,选几个用得最上手的挂着吧。 :)

Blogged with the Flock Browser

Tags: , ,

Popularity: 65% [?]

May 31

网站中同样或相似外观的链接应该保持一致,否则就应做些特殊的指示。

8box.cn

8box.cn基本满足了我单纯的听歌需求。我已经使用上好几个星期的时间了,但在播放器中,在我想播歌时,总让我犹豫一下,怎么去播这首歌啊?

Popularity: 51% [?]

May 18

一夜之间,SPAM暴增。明明我的博客PV很少,为什么总是被SPAMER盯上,而且是老外居多,中文的SPAM偶尔才两个。而且以往也是一个星期两三条,没试过一个晚上就几打的。虽然一晚几打很少,因为那些牛人的博客都是一天上千SPAM的,但我宁愿没有。

在WP中删除这么多SPAM虽然不算难,但在GMAIL中就方便多了,通过快捷键进行选择操作:先用”J”键(向下移动光标)然后”x”(选中),就这样来来去去的几次”j”->”x”,很方便的选中了邮件。嘿嘿,偶也是GMAIL快捷键高手了。

还有,发现以往的SPAM中总有这么的一条:一串数字,和一个GOOGLE搜索这串数字的地址。(如下图)

但在GOOGLE上什么也搜不到,难道有什么玄机吗?

Popularity: 56% [?]

May 17

听说使用IMAP方式在客户端软件中收取邮件很传神,做到邮箱同步!可就在今天第一次尝试就很不爽。不爽就在于我宿舍的网速太慢了,读一个邮件需要N久,也因为读邮件,经常假死。

(某人说:Gmail在半年前推出的东西现在才用,还好意思说-_-!!)

不过它的好处挺多的,与邮箱同步,不用全部下载所有邮件,点哪个下载哪个,读过与未读等操作做到与邮箱同步。但邮件的下载实在太慢了,而且在wmail中我识别不出哪个是下载过的,只有已读和未读标识,这点wmail做得不够好。

而且我发现一个新问题,就是wmail自动给gmail添加几个标签了(看右图)。

想不到Gmail的Labels也会用在这里,我发现它是这么使用的: 阅读全文(Read the rest of this entry) »

Popularity: 44% [?]

Pages: 1 2 3 4 5 Next