幹壞事是進步最大的原動力
最近在研究頁面速度時想到的方法，這個方法對於之後的 JS engine 應該會有幫助，另外也可以解決一個常見的鳥問題。
國外應該有人有提過這個方法，不過我用 Google 翻了一下翻不到，等之後找到再收到 delicious.com。
程式碼的精神很簡單：
var a = function() { /* slow code */ };
setTimeout(a, 1);
這樣的好處是：
抱怨一下，IE 的 JS 速度實在是不怎麼樣…
jQuery 的大魔頭 John Resig 在他的 blog 上討論了各瀏覽器對 Sub-Pixel 的處理方式：Sub-Pixel Problems in CSS。
在他文章裡，他產生了一個 50px 的 div，裡面包著四個 div，設定寬度為 “25%”，然後丟到 Opera 9、Safari 3、IE 6、IE 7、Firefox 3，以及 Firefox 2 裡測試。另外用 Javascript 去抓 DOM 裡面的寬度。這個問題也可以解釋為什麼某些站台的 Navigation Bar 在不同的瀏覽器下會有奇怪的「殘影」。
微軟以「安全」理由打算在 2/12 時強迫使用者升級至 IE7，如果不想要升級的使用者必須手動設定。
對於 IE6 only 的網站來說，這當然不是什麼好消息。微軟的這項行為等於是強迫他們要處理 IE7 相容性問題。對於使用者來說，在所有的網站都必須讓 IE6 可以正常運作下，用 IE6 的問題反而會比較小。
但對於網頁開發者來說，能夠僅快把 IE6 的市佔率壓低到可以忽略的程度，功德無量…
IE8 內部測試版本已經通過 Acid2，一個很有名的 CSS 的測試了：Internet Explorer 8 and Acid2: A Milestone，接下來是時間的問題了，離 IE6 與 IE7 消失還有很長一段時間，不過畢竟總是要有個頭。
Firefox 3 會不會 delay 到成為最後一個支援 Acid2 的主流瀏覽器？(真的發生的話也不意外，只是會有很多人笑得很開心)
當 innerHTML 還是太慢的時候的解法：When innerHTML isn’t Fast Enough…。
在作者的文章裡面，你可以看到在非常極端的例子裡，用改寫過的 replaceHtml() 在 Firefox 2.0.0.6 裡 destroy 與 replace 的速度各快了 473 倍以及 50 倍。而在 Safari 3.0.3 beta 上則是 create 100 倍，replace 50 倍。
在 jQuery 的 Google Groups 上面可以看到兩個作者 (jQuery 的作者以及上面那篇文章的作者) 討論把這個功能放入 jQuery 的一些問題：Faster then innerHTML。
先看這頁：jquery-animate.html，用 Firefox 以及 IE 各看一次，然後游標試著在兩個段落上移動看看，在 IE 上應該會變成這樣：
找了資料以後確定這是 IE 的 bug，也有解法：MSIE animated fade problems，解法是設定 background 屬性 (不確定設成底圖可不可以，不過確定 “transparent” 不可以)。經過測試發現可以在 Javascript 裡面設定 background，而不用事先在 CSS 裡面設。
對 IE 的 browser detecting 也很簡單：(Ref：Using the navigator object to detect client’s browser)
if (navigator.appVersion.indexOf("MSIE") != -1) {
// ...
}
目前看起來沒有問題，不過 background 屬性不能是 transparent 還蠻麻煩的…
受到 SlickSpeed 的刺激，這一版的 jQuery 大幅改善 CSS Selector 的速度，jQuery 官方的測試結果比 1.1.2 快了 800% (也是以 SlickSpeed 測試)：jQuery 1.1.3: 800%+ Faster, still 20KB。
不過這個版本在 mailing list 看得出來目前還很不穩定，很多人抱怨在非主流的 browser 上會有問題 (主要是 Opera 與 Safari，以及 Konqueror)，甚至有 Linux 上的使用者抱怨 Firefox 回報 SlickSpeed 測試全部都是 return error。
接下來的 1.1.4 版將會是 1.1 系列的最後一個版本，之後就是 1.2 了…
用 Google 找到的 bug 似乎是講用 Javascript 動態改變 display 時的 bug，不過我遇到的是純 CSS 的 layout 問題…
這頁 丟到 IE6/Firefox2/Opera9/Safari2/Safari3 測試，發現在 Safari 2.0.4 (Mac) 及 3.0.1 (Win) 上都會先出現 #id2 再出現 #id1，但是其他的瀏覽器都是先顯示 #id1 再顯示 #id2。
這是在我的 Windows 上顯示出來的結果，Safari 2.0.4 (Mac) 的結果跟 Safari 3.0.1 (Win) 的結果一樣，再加上我手邊沒有 Mac，就不貼了：
我的問題是，Opera 與 Safari 這兩個都通過 ACID2 的 Browser 到底哪個才是正確的？
Update：The display declaration 上早就提過這個問題了。
Note：這只是在 Javascript 裡跑 CSS Selector 的速度。
剛好看到 SlickSpeed CSS Selector TestSuite 這篇文章，在 Windows 上測了幾個瀏覽器，單位都是 ms (所以數字愈小愈好)，測試的時候都儘量保持不動電腦的情況下跑完：
| prototype 1.5.1 | jQuery 1.1.2dev | MooTools 1.2dev | ext 1.1b1 | cssQuery 2.02 | |
|---|---|---|---|---|---|
| IE 6 | 1600 | 3238 | 1302 | 839 | 6511 |
| Firefox 2.0.0.5 pre | 176 | 4289 | 144 | 965 | 5411 |
| Opera 9.20 | 68 | 1445 | 112 | 198 | 1122 |
| Safari 3 beta | 120 | 733 | 140 | 152 | 931 |
呃，Firefox 2 的速度… (想裝地雷看看有沒有進步，結果想到早上才失敗過，沒辦法測 XD)
Update：網頁上多了 Dojo 的測試項目，速度也還不錯。
兆豐商銀憑證管理工具使用手冊 的第七章對「為什麼採用電子憑證之授權交易在執行時，一直出現「安全性資訊畫面」？」的說明：
Update：第一個，畫面跳出安全性資訊是因為在 https:// 網頁上夾雜 http:// 資訊，這不是 IE 的 bug，而是兆豐金的人設計網頁時的安全漏洞。如果沒有特殊設定，那麼在 SSL 所建立的 Cookie 會因為抓取 http:// 資料而從 Non-SSL 下從網路上傳輸。
IE 會出現警告訊息是正確的作法，因為這本來就有安全問題。
第二個，SSL 連線裡面需要的不只是一種加密方式，一般比較常見的連線是 RSA 1024bits + RC4 128bits (左圖) 或是 RSA 1024bits + AES 256bits (右圖)，所以在說明書裡面故意把 “1024bits” 與 “128bits” 放在一起誤導使用者「1024 > 128」是很糟糕的事情：
第三個，兆豐金宣稱使用的 RSA 1024bits + 3DES 與現有 SSL 在使用的 RSA 1024bits + RC4 128bits 比較，會不會比較安全，我覺得… errr…