作者：屈超（Chappell.Wat）
发布时间：March 6, 2012
分类：程式::五代
16 Comments
不知标题是否写得太绕口，
简单地说就是将离线迅雷注册为某些特殊（伪）协议的默认处理程序，
包括“迅雷”、“快车”、“旋风”、“磁力”、“电驴”。
08 年写过一个Firefox 扩展来做“解码”这件事，
现在有了“Web 离线迅雷”和“Web 离线旋风”等吸血利器，
我的 Mac 上连 P2P 软件都懒得装了（惭愧）。
于是去年干脆写了段脚本做了标题所述之事，
当时还顺手写了个油猴脚本，
但一直存在间歇性登录态丢失问题，
于是就搁置了一年未发；
最近研究迅雷联盟时偶有所得，
貌似可以解决上述问题，
于是趁今天有空更新了一下发布出来。
原理简单就不多着墨了，
请自行去阅读 navigator.registerProtocolHandler 的文档。
至于兼容性，
脚本虽是为 Firefox 的 GreaseMonkey 所写，
但所有遵循 UserScript 规范的脚本管理器都可以使用；
Chrome 当然能用，
但貌似它对自定义协议有前缀限制；
而 Opera 则未经测试。
【120324 更新】
虽然 UserScript 本身（作为一种规范）在各种浏览器上都有其实现，
但完全开放 navigator.registerProtocolHandler 接口的浏览器并不多。
目前本脚本只在 Firefox 上测试通过。
【使用方法】
1. 安装并启用该脚本；
2. 访问 http://lixian.vip.xunlei.com/task.html， 请确认当前你处于未登录状态；
3. 浏览器将会提示你是否授权将“离线迅雷”注册为上述（伪）协议的默认处理程序（如下图）；
4. 禁用（或干脆删除）本脚本，开始使用吧。
【更新日志】
[110224] 1.0: 初始发布
[120306] 1.1: 解决登录问题，增加使用说明
【提供下载】
自建项目：http://watsilla.googlecode.com/svn/trunk/userscripts/web-thunder-helper/web_thunder_helper.user.js
脚本官方：http://userscripts.org/scripts/source/127624.user.js
作者：屈超（Chappell.Wat）
发布时间：March 23, 2011
分类：程式::五代
106 Comments
【2011.03.23 更新】
看到有同学留言提到 Chrome 下的 FlashBlock 方案，
我想说的是 Chrome 的 Dev 版已经原生支持了本特性，
开启方法如下：
1. 在地址栏输入 about:flags ；
2. 找到名为 Click to play 的那一项；
3. 点击 Enable 并刷新包含 Flash 的页面就会看到效果。
当然，
Chrome 的这个开关是针对所有插件而设的，
所以如果是 Java 或 Silverlight 的内容也会被要求 Click to play ，
应该算是正中了大伙儿的下怀吧？LOL
【2011.02.21 更新】
谁曾想这个小东西还有不少人在使用呢？
更有热心的朋友写邮件向我报告了 Bug ，
于是上周末在家针对大家的意见做了一次更新，
主要的改进点如下：
1. 支持了简单的白名单功能，
目前仅进行地址的前缀匹配，
比如你要将谷歌音乐加入白名单，
（页面地址：http://g.top100.cn/xxx/html/player.html）
只需要修改 block-flash-lite.xml 的如下代码：
var whiteList = [
'http://g.top100.cn/',
];
每个地址前缀占一行，
被匹配到的页面即不阻拦 Flash 的加载。
考虑到大家对于白名单的理解可能各不相同，
所以目前没有支持正则匹配，
但要支持并不难，
所以大家对白名单有什么具体要求，
（是支持完整的正则？还是简单地仅需要 * 通配符？）
请留言或 email 给我，
在收集意见后我将在下次进行更新。 ：）
2. 调整了 UI ，
由之前的纯文字修改为播放按钮（如图）：
“借”用自 Mozilla 的官网页面，
假如有任何版权风险请告知我予以移除。
3. 增强了兼容性。
特别是一些朋友所反应的
类似“同一个 Flash 被 Block 两次”的问题。
这个问题的出现是页面开发者为了去兼容不同浏览器
使用了传说中被广泛推荐的 The nested-objects method .
其原理是使用双层标签，
外层 object 标签供 IE 所使用，
内层 object/embed 标签则供其它浏览器所使用。
Firefox 自然是属于后者，
我也是按后者的逻辑去做的处理，
但难免会遇到特殊情况，
如果你有遇到，
请留言或写信告诉我。
好了，
所需文件分别是：userContent.css 和 block-flash-lite.xml 。
安装方法可参考下方的旧文，
正在使用 1.0 版本的朋友请直接替换 xml 文件然后刷新页面即可，
无需重启 Fx 哦～
阅读剩余部分...
作者：屈超（Chappell.Wat）
发布时间：November 29, 2010
分类：程式::五代
47 Comments
【2010.12.08 更新】
抱歉，
用原生 IE9 测试后发现 IE9 的判断代码已失效，
研究将继续……
【2010.11.29 更新】
之前的 IE8 检测方式容易被“伪造”，
改为检查 Image 对象是否存在 prototype 的方式。(via)
另外有朋友说 IE8 的探测在 IE7 模式下也通过，
我想说这是我有意为之：
目的就是要探测浏览器本身的真实版本，
具体运行于哪种模式可以通过 doc.documentMode 来获得。
【2010.11.17 更新】
IE9 不知从哪个 Pre 版开始，
又恢复了之前更新时所提到的
非空数组字面量的最后一个元素缺失的问题，
也就是说这个 Bug 又得以“重现”了。
我个人推断是太多线上应用依靠这个 Bug 来识别 IE ，
因此开发团队不得已而为之。
但不管怎样，
本文还得继续。
目前利用了 IE9- 里 toFixed 方法在特定情况不会四舍五入的 Bug 来判定，
具体代码请见正文。
【2010.08.13 更新】
增强了 IE6 的区分能力。
当然更可以使用 IE 自己的条件编译，
只是有的压缩器支持度有限，
不便于日常开发。
【2010.04.18 更新】
更加严格地区分出了 IE 9，
增强了 Opera 的区分能力，
并将 Chrome 的判别特征换成了引擎特性 [via]，
这样你就能看出国内哪些浏览器是从 Chrome 的内核改过来的了，
大家可以动手试试。 ：）
【2010.04.17 更新】
IE 9 在我看来改进非常大：
有我所关心的对 Mutation Events 的支持，
还有事件模型的 W3C 化等等……
本文中我就不多冗述，
有机会再另文探讨。
由于在项目中大量使用特征判断，
IE 9 在这方面最显著的变化是：
之前那则“最短的 IE 判断法”已经失效，
一起被修复的还有一直伴随 IE 的数组 Bug:
非空数组字面量的最后一个元素缺失的问题（即：[null,]），
因此现如今的最短记录保持者（6字节的 !-[1,]）也已然失效。（而且不支持 CC 压缩）
你也不要尝试使用 addEventListener 方法来判别，
因为 IE 9 已经支持了。（事件的改进非常大，这很好）
所以说 IE 已经越来越靠近标准，
如果在项目中有对 IE 进行特殊处理的代码，
你可能需要在 IE9下重新检查一下了。
由于我个人依旧是 XP 的忠实拥趸，
而 XP 又很悲剧地无法安装 IE 9，
所以一些测试是在 Haitao Jia 同学的协助下完成，
在此表示感谢。
也正因为如此，
我没有进行覆盖面太广的测试。
不过目前所发现的唯一“幸存”下来的 IE 系列 Bug 依旧与刚提到的数组 Bug 有关，
微软修复了字面量里的 Bug 却忘了当字符串被 split 成数组后却涛声依旧啊。
虽然判断起来稍微麻烦了点，
但不管怎样这是我目前发现的仅剩不多地可以用来判断 IE 全系列的代码：
阅读剩余部分...
作者：屈超（Chappell.Wat）
发布时间：August 13, 2010
分类：程式::五代
22 Comments
页面里使用 inline-block 元素时经常需要隐藏其文字，
比较流行的方法是将 line-height 的值设置得很大，
然后配合 overflow: hidden 来隐藏文字。
请容许我主观臆断地认为过大的行高会影响渲染效率，
而行高不够又可能在用户对页面进行放大操作时露出“马脚”（即未能被隐藏的部分）。
是否当 line-height:0 时对 Webkit 内核就没有办法了？
我想到利用透明文字来解决这一兼容问题，
并最终整理如下：
font-size:0; /* for firefox & opera */
color: transparent; /* for webkit */
line-height:0;
overflow:hidden; /* for IE */
自测后兼容的浏览器如下：
IE 6-8
Firefox 1-4
Opera 9-10
Safari 3-5
Chrome 1-6
如遇不兼容的情况可以留言。
当然隐藏文字的方法还有很多。
有人说“直接不填文字不就好啦”，
呃……
算我没说，
不过目前公司的产品对盲人阅读器的兼容还是有要求的。
作者：屈超（Chappell.Wat）
发布时间：April 28, 2010
分类：程式::五代
4 Comments
因工作关系我已有些时日没用 YUI 写代码了，
这次由于项目需要我阅读了一些脚本库的代码，
无意间发现了这个 YUI 里 (Dom || Node).getXY() 的小 Bug。
查看了手边的 YUI 2 和 3 的多个版本代码，
均存在此问题。（怀疑其影响全系列）
时间不多，
抽睡前的一点时间写下来吧。
问题描述如下：
当浏览器不支持 node.getBoundingClientRect() 方法时，
我们会选择通过 offset 系列属性一层层向上计算偏移值，
最后得到一个“可能有错误的”元素坐标。
要修正这个错误，
我们需要沿着节点树一层层向上判断是否某个祖先“出现”了滚动条，
如果有，对不起，阉了。
大体的思路是这样没错，
YUI 也确实这样处理了，
而且它也知道元素定位方式中还有一种游离于布局之外的 fixed，
只可惜它没在碰到 fixed 元素时及时刹车，
结果就是在一种较特殊的布局下会多删一次滚动条高/宽度，
导致坐标计算错误。
可叹可叹，
它曾那么接近幸福。
所以当某个有滚动条的页面里存在一个 fixed 定位的元素，
而你又要用 YUI 去取该元素所包含的某个子元素的坐标时，
Bug 就出现了。
文字描述显然不够直观，
请猛击如下链接来查看不才基于 YUI2 和 YUI3 所构建的示例。
（由于该 Bug 只影响不支持 node.getBoundingClientRect() 的浏览器，
请选用诸如 Firefox 2 / Chrome 1 / Safari 3 等浏览器来打开示例，
顺便在这里感谢 IE 团队为我们贡献了如此好用的一个方法）
阅读剩余部分...
- 1
- 2
- 3
- 4
- ...
- 27
- »