jQuery 中文文档XML版以及CHM版发布

我相信很多人在等待CHM版的发布。
这次发布采用了XML版生成分散的文件。由于花了点时间在原先的HTML转XML上,以及一揪回家等因素,这次的CHM版姗姗来迟。但值得庆祝的是,以后的CHM版会很轻松地发布~

如果有兴趣看我如何把jQuery文档从HTML转成XML的,可以看这个jqapi2xml
需要Firefox 1.5以上或者使用Mozilla Gecko 1.8以上引擎的浏览器或者其他直接支持E4X的浏览器才能使用。

新的XML版文档可以点击查看XML版。我简单写了一个XSL。其他同学如果有需要可以自行拿这个XML写其他的XSL。
这里是英文的XML版文档。使用了同一个XSL,只是语言不同而已。可以发现这回不再是双语版了,对双语版有爱的同学我只能说对不起了,由于精力有限,无法同时维护中文版以及双语版中的英文部分。如果实在有爱,可以写脚本把上述英文版XML中说明加入中文的XML之中,并自行修改XSL。

最后,CHM版可以直接从Google Code下载:
http://code.google.com/p/jquery-api-zh-cn/downloads/list

CHM版和XML版均提供查找更新功能~
HTML版今日(2009-1-29)发布最后一版,增加2个函数以及修正些小问题。也可以从上面的地址下载。以后不再更新,请同学将收藏夹中的地址改成上述的XML版地址。

另,据测试下来,可能有些同学会出现点击任何页面都出现下载的情况。如果这样请先使用HTML版。如果情况比较多,下一版将会采用XML+XSLT转HTML后再编译成CHM格式。据网友汇报,确认下HKEY_CLASSES_ROOT\.xml 下的Content Type是否是text/xml 再试试找到文件夹选项,文件类型里的XML处,点”还原”,可以解决这个问题

关于jQuery xml版英文文档的一些事

其实去年年底,jQuery 1.3尚未发布的时候就已经盘算着将中文文档以xml的形式发布了。这样有个好处,就是页面结构可以用xsl随便换。各位同学想做不同的发行版可以随便换着玩~实际上我现在愈发觉得css的局限性了,很多时候所谓的css为了后期维护方便,可以任意修改布局而无需动页面结构之类的话语已经觉得难以置信了。我就不信有多少同学遇到过改版的时候只改css而不改html的。当然也有可能是我的局限性而非css的局限性。

所谓的圣杯布局双飞翼布局确实在很大程度上能解决布局(Layout)上的问题,但别忘了,开发工作可不只是布局,还有排版(Typography),数据结构和页面表现结构交织在一起的时候,想崩溃都觉得老板会从地域里拖你起来。

xml+xslt这种手段其实我几年前就看到过,当时也曾为之心动,无奈当时技术水平有限无法体会其中精妙。然借此jQuery 1.3文档大改之际便又萌发了尝试的冲动。

xml+xslt好吗?很好!居然ie 5就开始支持了,ie 6支持的程度也很不错,基本上没有遇到什么兼容性问题,比起万恶的ie6对css的支持度好多了。目前我除了发现document()函数在ie中表现的跟其他浏览器不一致之外,以及Firefox居然不支持disable-output-escaping=”yes”,并且争论长达7年多尚未有解决的迹象。除此之外似乎没发现更多问题。

实际上让一部分处理页面的逻辑放到了前端来做,后台只负责输出数据,这种数据(XML),结构(XSLT),表现(CSS),行为(JS)4者相对分离的状态是十分有利于这个前端产业工业化发展的。随着前端工种的进一步细分,我觉得这里大有可挖。好处显而易见,如果要大面积改版(即便是小范围),由于后台只负责输出数据而没有HTML格式,高度分离的情况下,基本上只需要前端小组改一下即可。即便是对后台语言完全不了解都可以(我承认这不好)。
此外,xslt支持include/import等语句,包括上面提到的document(),可以很方便的实现页面各个部分的模块化。

但随之带来的问题也显而易见,数据过于结构化,页面内容轻易被人抓取而后分析(都不用分析……直接解析……)
此外,很多pda,手机之类的可能对xslt无法解析,但我估计屏幕阅读器应该没问题,因为很多屏幕阅读器都是基于现有浏览器的,也就是说现有浏览器支持,他也就支持。
还有上面提到的模块化问题,一不小心就可能导致连接数过多。每个模块的粒度得把握好。

解决这些问题的一个简单途径是,xml+xslt在服务器端解析生成。服务器端可以通过检测浏览器来判断直接输出xml+xslt还是输出生成的页面。这对于pda和手机之类的能提高很大兼容性。而对于一般浏览器又无需消耗服务器资源。
网上有篇流传甚广的文章XML在B/S架构开发中的应用,正是描述了此类情景。我考据下来可能是原著地址(我找到个更早的地址但上面的写的作者也是他,请宽恕我的网络考古情结)。

其中也提到了http://xml.apache.org/cocoon/ 似乎可以直接使用,没深究。

好了,得回到正题了。jQuer现在弄了个专门是放api的地址:http://api.jquery.com。说实话,我一直很不喜欢他现在弄的样子,当我需要在不同的方法之间切换的时候很不方便。有喜欢的可以自己尝试。另外,分析代码发现原来这个api也是从wiki里扣出来的xml进行解析得来的。另有air版,喜欢的可以自己下。扣的程序是Python 2.4写的,遗憾我这里只有Py3k环境,执行失败,且自己道行过浅,无法改成3.0版以供自己用。忘有此能力的同学能帮我改一下,可直接从jq的svn里拿到,点击下载。没有达人帮忙其实也没事,见到还有地址可以在线生成,前面在线生成的地址如果不加参数则可以直接查看这个生成器的文档。用urllib.request.urlretrieve(url,path)直接下载真的是很惬意的事情,Python真的是很强悍啊……
我随便写了个xslt,可以直接浏览jQuery 的英文文档。暂不提供下载,喜欢的就自己另存为吧……不喜欢的就自己写一套吧……
暂时计划是将中文文档转换成xml(这步已经在前天完成,转的我残念……请原谅我能力有限只能用这么离奇的办法转格式……)。不过之前写这个的时候还没有看到上面那个wiki2xml生成器(其实早就见过了,被我无视了而已……),所以对应的标签以及格式还不是很对上号。改天整整。另外,单个xml拆分成散件的xml的py脚本也写完了,实验成功,现在生成chm版的文档只差单文件xml的校对和chm文件的目录以及索引之类的编辑工作了。不用太期待……一揪回家了……新年饭局又多……饿……大半夜的吐槽可真不好……睡去了……

我为什么使用Google CDN

自从之前jQuery 1.3版起,就已经没有提供pack版了,而我也十分赞成使用Google CDN进行代码托管。

这样做有以下几个好处:
1,更小下载量。
都知道jQuery 1.3 pack后有38k之多,如果当然可以删除版权注释以获得更小的代码,遗憾的是这不仅无耻且只节约1个k都不到。而同样利用Google APIs 提供的GZip过的Min版,只有18k,对用户来说下载量更小。

2,减轻服务器压力。
虽然现代浏览器都有了缓存,但以前我看到过资料说某大型网站发现他们70%的访客缓存都是空的(哪位同学能帮忙找到资料请下面留言,不胜感激~)。所以,让Google为我们提供服务,而不用自己操心自己的流量~少个库可以少个连接数,何乐而不为。

3,多个网站共享缓存。

如果用户访问的多家网站都使用Google提供的jQuery,那么对于用户来说,只需要缓存一次后即可只读取缓存中的数据!而不是每个网站都要重新下载一份。对此进一步加快用户访问速度。

4,更快执行速度。
jQuery 1.3.1发布的发布信息中,为jQuery不提供pack版给出了官方的解释。除了不易debug,在Adobe AIR和Caja-capable等环境下无法使用之外,更重要的是因为执行速度问题。随着jQuery逐渐变“胖”,用pack压缩后在浏览器端“解压缩”所需要的资源越来越大。想象一个超大的字符串多次replace后再eval的情景……这不比直接读取一个不需要解压缩的min版来得快。John给出了一些数据,有兴趣的同学可以看看。

反对的声音:
“不安全”、“没安全感”、“放别人的机器太危险了”、“他们服务器倒了呢?”、“以前刚开始的时候就down过”

我认为(晕……怎么我觉得我在写四六级作文……)Google服务器down的几率与我们自己服务器down的几率不会有显著性差异(抱歉,我又空口无凭说话了……不过如果哪位同学能给出数据来拒绝我的零假设,认可备选假设的,欢迎提供,再次不胜感激~)。所以就放他们那边吧,挺安全的。

另外我还听到关于不能让整个世界为着Google转,Google阴谋论,Google威胁论的声音。实际上Google确实正朝这个方向发展,让整个互联网围着他转。可以看他提供的一些服务,什么云计算,什么App Engine之类的,都企图让人们的应用都建立在Google至上,当Google成为了空气的时候,他已经无处不在了。这点来说,值得担忧。

万恶的弹窗广告

或许是我孤陋寡闻,但我在国内第一次看到弹窗的复兴是从淘宝开始的。在各大浏览器纷纷将未经用户交互而弹出的广告封杀的时候,淘宝采用了给document绑定click事件的方式调用window.open来弹出广告。

当然,淘宝还算文明,弹窗放到了后头,并且似乎一天只弹一次。我这里也不是为了谴责淘宝的前端们,也能理解他们也实属无奈。

自从那时起,神州大地便四处开花。各个网站的站长似乎找到了救命稻草,弹窗广告又活了!大有“我胡汉三又回来啦”的气势。我见过最离谱的是直接给document的mousemove事件帮上弹窗广告,你鼠标只要移到页面内就会弹窗!而不像淘宝那样等你点击了才弹窗。

注意,我写此文的并非告诉各位同学新式弹窗的秘诀。相信各位同学也都是非常反感弹窗的。如果哪位擅自将上述秘籍用于实际项目必将遭受广大群众的谴责!请三思。

此问真正的缘由是:近日我经常光顾一些垃圾站点,弹窗之猖獗实属罕见,一怒之下写了脚本将window.open劫持,看谁还敢弹广告~嗯哼~

继续阅读万恶的弹窗广告

jQuery 1.3 升级指南

jQuery 1.3提供了很多新特性,不少同学也纷纷更新到了jQuery 1.3,也有同学升级后发现有些功能失效了。这里就简单写一下jQuery 1.3的升级指南。如果这里没有提到的而你却遇到了并且解决了,欢迎留言告诉更多人。如果没,所好能写个简单测试样例以说明问题。

这里不涉及任何新增特性,只有关于修改过的内容。要看新增特性,请参考这里

翻译了通篇文档,主要发现以下几点容易导致升级失败:

1,取消了属性选择器的@前导符号。这点会造成升级失败。虽然这个@符号在jQuery 1.2中已经不推荐使用了,但由于种种历史原因还是有很多人用。修复这个问题的方法很简单,只需要简单删除那个@符号即可。

2,trigger()方法触发的事件会冒泡了。这点可能在某些重要的功能上发生偏差。尤其是一些大项目上。要解决这个问题,需要在事件处理函数里加上e.stopPropagation() 或者函数返回false即可。

3,这点实际上并没有在发布信息中提到,但却也是很重要的问题。[attribute!=value]这个属性选择器在jQuery 1.3之前是这样的:”匹配那些没有指定的属性的元素,或者指定的属性不等于特定值的元素。”,这等价于:not([attr=value])。而在jQuery 1.3中是这样的:匹配所有含有指定的属性,但属性不等于特定值的元素。
这个改动是为了符合w3c的标准。虽然有点绕……
要解决这个问题,上面也已经提到了,有选择得使用:not([attr=value])代替即可。(但目前这个似乎在ie下有bug,依然跟以前的表现一样,ff和chrome下符合这个描述)

1.3.1中又改回来了……[attribute!=value]依然等价于:not([attr=value])。如果要找含有特定属性且不等于指定值的请继续使用[attr]:not([attr= value])

更多的问题尚未发现,如果各位同学遇到了请不要吝惜提出来~谢谢。

jQuery 1.3 中文文档发布

jQuery 1.3自从2009年1月14日发布后,后引来了各界的关注。我们也随即投入到翻译文档的工作中来。经过4天的努力,终于完工了。这个版本更新了不少东西

changelog:

2009-01-21 20:23:38 +0800
* #4 关于1.3版的日期 (感谢liushuang630)
* #5 die()的标题误为toggle() (感谢dadao5.com)
* queue([name],callback) queue([name],queue)少参数 (感谢Horatio)

2009-01-19 00:00:10 +0800
+ offsetParent()
* closest() 说明

2009-01-18 16:06:52 +0800
* triggerHandler 进一步说明
* trigger 进一步说明

2009-01-17 22:37:11 +0800
* live() – 与bind()不同的是,live()一次只能绑定一个事件。
* [attribute!=value] jQuery 1.3中意义改变
* load 的data参数在jQuery 1.3中也可以接受String
+ ajax的error回调的第二个参数可能值”timeout”, “error”, “notmodified” 和 “parsererror”
+ ajax参数xhr
* animate 的duration为0的问题
* show, hide, toggle, slideDown, slideUp, slideToggle 在jQuery 1.3中,padding和margin也会有动画,效果更流畅。
* jQuery(html,[ownerDocument])等效于$(document.createElement(“span”)
* is支持复杂表达式

2009-01-17 18:31:10 +0800
+ jQuery.support.scriptEval
+ 原 Dimension 插件功能(1.2.6版加入jQuery核心)

2009-01-16 19:11:10 +0800
+ jQuery.fx.off
+ toggleClass( class, switch )
+ toggle( switch )
+ toggle(speed,[callback])
* 修改queue和dequeue方法的参数和说明

2009-01-15 22:31:02 +0800
* jQuery(html,[ownerDocument])
+ jQuery.selector
+ jQuery.context
* 效果下的queue和dequeue搬到核心下
+ live()
+ die()
+ closest()
* stop( [clearQueue], [gotoEnd]) 增加两个参数
+ jQuery.support
+ jQuery.isArray( obj )

感谢Cloudream的热情帮忙。还要感谢一揪制作chm版。这个版本还加入了检查更新的功能。如果有需要的同学可轻松查看是否有更新的中文文档(chm版中的检查更新也将同步升级)。目前chm版尚未完工,请稍候。
继续阅读jQuery 1.3 中文文档发布

live不是万能的

众所周知,jQuery 1.3版中有个很重要的功能是新增了live方法,这个方法可以为现在以及将来出现在页面上的元素绑定事件。
而这个live方法的原理是什么呢?

根据官网上live的文档上找到了这样一个地址
进去一看才知道,所谓神乎其神的方法,其实就是事件冒泡+e.target
跟我先前关于事件重复绑定的文章中的方案二如出一辙。进一步求证,查看jQuery源码,可以在2854行发现如下代码

jQuery(document).bind( liveConvert(type, this.selector),
this.selector, proxy );

这下就明白了,原来live其实就是给document绑定了事件处理函数,这样所有新增的元素的事件都能够冒泡到document上,实现了事件的动态委派的过程。这样极大得简化了本来需要自己管理的冒泡+e.target代码,都交由jQuery来管理了。

但这却会有一定的局限性:e.stopPropagation,对,聪明的你一定想到了,就是这个方法会失效。即使是普通的click的事件,想不让他冒泡都是不可能的。因为事件处理函数就是等事件冒泡到document上之后才触发的,此时再阻止冒泡已经为时已晚。所以,当遇到此类事情的时候,各位同学没办法……只能重复绑定或者用clone(true)咯……
live虽好,但不能乱用,视情况而定才是王道。

不过,幸运的是,e.preventDefault依然可以使用。所以可以说,在事件处理函数中,return false并没有完全废掉。