可憐天下 web developers 不知花了多少光陰在支援不同瀏覽器上。Internet Explorer 就甭提了，即使 Safari、Firefox 都支持的陰影（box-shadow）效果，偏偏都有不同寫法。結果就是同一件事情要寫好幾次，不幸要修改數值的話又要連續改數次。杯具啊……（還是都習慣了？）

原本簡單一個陰影效果往往要六行 code 才可以搞定：

.box_shadow {
     -moz-box-shadow: 1px 0px 4px #ffffff; /* FF3.5+ */
  -webkit-box-shadow: 1px 0px 4px #ffffff; /* Saf3.0+, Chrome */
          box-shadow: 1px 0px 4px #ffffff; /* Opera 10.5, IE 9.0 */
              filter: progid:DXImageTransform.Microsoft.dropshadow(OffX=1px, OffY=0px, Color='#ffffff'); /* IE6,IE7 */
          -ms-filter:"progid:DXImageTransform.Microsoft.dropshadow(OffX=1px, OffY=0px, Color='#ffffff')"; /* IE8 */
}

為了解決這個問題，我在此隆重介紹～ CSS3 Please.com－ 一個網上 跨瀏覽器 CSS3 代碼生成器。以後寫 CSS3，只需修改一處地方，網站自動幫你更新其他瀏覽器的代碼。支持的效果有圓角 border-radius、陰影 box-shadow、漸變、移動 transform等，而且還會最大限度地支援各個瀏覽器：Internet Explorer, Safari, Chrome, Firefox, Opera。比較意外的是，原來有不少效果在 Internet Explorer 下可以靠 filter (DXImageTransform) 來達成，如果要自己寫的話，大概要花不少時間查文檔吧。

Google 也要搞 SEO 嗎？當然不需要啦，一來 Google.com 的 page rank 滿分，雞犬升仙，二來大不了就花錢買廣告啊，左袋放右袋，跟本沒有成本。可是最近 Google 竟然公開了他為旗下產品作做的一份 SEO 報告：Google’s SEO Report Card。

在該份近 50 頁的報告裡，詳細列明了 Google 產品各項 SEO 環節的綜合情況，以及可改善的地方。有趣的是，絕大部份項目得分都頗差啊～

當然，報告裡所涉及的建議都很正路。而且 Google 產品的頁面大部份都一頁起兩頁止，又屬於靜態，未必能完全套用到大型網站。真實世界裡的網站的 SEO 小招數多的是呢。

無論如何，這都是一份必看的 SEO 教材，強烈推薦喔～

先來數一數白隊共互傳了多少次球？

如果有觀察過一些不熟悉電腦操作軟件／網頁的情況，大概會時常發生一些 developer 和 designer 難以理解的現像－何以這麼大的一顆按鈕、一個告示，居然會被忽略掉？

並不是因為他們有先天缺陷，「發雞盲」。如果明白到所有視覺影像都需先經大腦處理方可解讀，會發生以上情況就不是那麼難以理解了。學者稱之為「failures of visual awareness」，其成因眾說紛紜，本文無意探討（『演化心理學！』蕭生聽眾如是說 XD）。failures of visual awareness 可大概分為兩類，Change Blindness 及 Inattentional Blindness。

illinois university 對此兩者進行了一系列研究，並有大量錄像可供觀看，十分有趣： http://viscog.beckman.illinois.edu/djs_lab/demos.html

Change Blindness 是指人對事的的變化視若無睹。例如緩慢的局部漸變往往很容易地被人忽略。在「A subject in a real-world person change event」這個實驗中，被實驗者甚至無法察覺到交談對像已被換掉（前提是不能是帥哥美女、年紀相近，否則印像太深會影響結果 XD）。

Inattentional Blindness 比較為人所熟知，是指注意力集中的時候往往會無視掉畫面上的其他元素。文章開頭的那則廣告已是一例，第一次看該影片的人沒多少個能發現那隻黑猩猩。影響 Inattentional blindness 的最大因素是用戶的認知負擔。負擔越大，需要更專心，便越容易無視身邊環境。其實就該實驗而言，兩隊顏色的相比度越高（即相似性減低），受試者會更難發現大猩猩。當然大猩猩跟兩隊的相似性也會影響結果。

對 UI 設計有何啟示？老生常談：

1. 減低用戶認知負擔，一個 UI 只做一件事；
2. 利用對比突出重點。

Parallel script loading （併行載入）是加速網站頁面載入最有效的方法之一。因為古代的瀏覽器（aka IE）很多都不支援 parallel scripting loading，它們載入外部 script 時是一個完成後才開始下載另一個，而不是像圖片一樣同時下載多個文件，即出現上圖情況：所有在該 script 之後的文件下載都被擋在後面了 (blocking)。因此出現了 n 多個小技巧解決這個問題。

• Script DOM Element
• XHR Eval
• XHR Injection
• Script in frame
• Script Defer
• Document.write Script tag （IE only）

不同方法有不同特徵，如對跨域名的支援、執行順序、瀏覽器狀態等。當中 Script DOM Element 是最流行的的方法，亦都支援最多的 browsers。各種方法的優劣可參考 Loading Scripts Without Blocking 一文。當中 Script DOM Element 是最流行的做法，唯在 IE 下並不保證可按次序執行。順帶一提，jQuery 的 getScript() 貌似也是用此方法。

新推出的 browsers 已經開始支援 parallel script loading，包括 IE8, FF3.5, Safari 4, Chrome 2 等。但 parallel scripting loading 除了可以解決 blocking 問題外，應用得宜還可以有 progressive enhancement 的作用，developer 可決定各檔案下載的時機。

例如 Google docs 會在工具列未完全下載完之前，會先顯示一個 view only 的版本。直至工具列完全載入後，才轉成編輯狀態。

除工具列以外，Google docs 部份次要的 menu 的下載次序比工具列更後，例如 share button。你按下 Share button 的時候有機會看到灰色 loading 字樣的。由於時間太短無法截圖給各位看…

圖出自 Loading Scripts Without Blocking

BBC 日前在 Blog 上展示了他們正在設計中的新網站視覺系統，他們稱之為視覺語言 Visual Language，旨在統一 BBC 各個網頁的設計風格。目前 BBC 網站便用的視覺系統是兩年前設計的，該套設計標準規範可在此中尋。

新網站設計想傳遞「現代英國、時事、強勢、獨特、領先、綜合、優秀」等感覺。同時為了適應越來越流行的闊螢幕瀏覽，設計團隊還重新設計了一套新的網格系統 (grid system) 及網頁模版。

當然還少不了字款、顏色選用的規範。總體來說沒有太大改變。將在今年逐漸應用到 bbc 各個網站上。

（影片可能無法在 RSS Reader 上正常顯示）

一直認為目前市場上所謂「電子雜誌」的存在是種倒退，將影印版原原本本地轉成 PDF 格式搬到電腦上，缺乏互動，麻煩之餘比網頁更加不如。

最近 Adobe 跟 WIRED magazine 在 TED 上展示了如影片中的電子雜誌概念，利用 tablet 提供讀者全新的使用體驗：

• 基於 touch screen 的設計
• image slideshows
• 產品 360 度全觀可能
• 影音可能
• 當然跟 iPhone 一樣有垂直／水平版本

這大概是最接近我理想中的電子雜誌。而且變成現實的機會不少，因為成本上大概不會比傳統雜誌高出多少。除了那個 360 view 以外，其他素材都是可跟影印版共用。平台方面也是一次性的支出，只需開發一次，說不定 Adobe 還會提供個 framework 呢。唯一成本大概是要請幾個長駐的 developer。

此 demo 基於 Adobe AIR （Flash）建成的，不提供下載，亦大概不可能出現在 iPad 上。

// 眼見未為真
"string" instanceof String; // false. 

// 誰在說謊？
typeof null // object
null === Object // false

// 意料之內
typeof NaN // number
NaN === 'number' // true, of course.

// 邏輯謬誤
NaN === NaN // false

// 數學謬誤
0.1 + 0.2 === 0.3 // false

以上內容由 http://wtfjs.com/ 提供

Uniform 是個新的 jQuery 的表單美化插件，能夠美化 CSS 管不到的 form elements，例如 file upload、radio box、check box 。其實網上美化表單的 JavaScript 插件的多不勝數，但是這個是我見過最好的一個，為甚麼？

首先是下拉選單 (select element) 的實作方法。其他表單美化插件一般都會將整個 select element 移走，換上一個用自制的 JavaScript 下拉選單 － 而且一般做得反應遲鈍、難看。我自己很討厭這種做法。

可是 Uniform 的實作方法就好得多：圖檔一如以往地被設定成背景圖片，不同的是，Uniform 將 select element 的透明白降至 0%，使它從人們的視覺上移走 － 而不是從 DOM 中移走。所以，原來的 select element 其實依舊存在，用戶點擊的時候其實是點中了原生那個 select element。

下面是其代碼：

<div id="uniform-">
  <span>Option 3</span>
  <select style="opacity: 0;">
    <option value="option1">Option 1</option>
    <option value="option2">Option 2</option>
    <option value="option3">Option 3</option>
  </select>
</div>

同樣原理還應用到其他 form element 上。Uniform 支援 File upload input、radio、checkbox、button，但居然沒有一般的 input text box，雖然要美化一般的 text box 對大家應該沒有難度吧。

下載：http://pixelmatrixdesign.com/uniform/

Image Optim 其實是由 AdvPNG, OptiPNG, PngCrush, JpegOptim, jpegtran, Gifsicle 等多種壓縮方法結合而成的一個小工具（開源就是棒啊），支援 GIF、JPEG、PNG，該有的都有。把圖片拉到軟件上便會自動開始壓縮，就是如此簡單。

官方網站：http://imageoptim.pornel.net/

寫 CSS 最痛苦的是要搞定一堆 browser bugs ，其次就是要面對 CSS 不是 programming language 這現實，不存在其他程式語言常見的 變數、運算、繼承 等概念，使原本簡單的工作變得冗長，並且使維護工作變得麻煩。

less 的出現便是為了解決這個問題：在現有 CSS syntax 的基礎上，為 CSS 加入程式語言的特性，包括變數、scope、nested rules、運算、繼承。

看例子你便會明白：

@brand_color: #F0F;

#container {
    div {
        color: @brand_color;
        border: none; }
    p {
        color: @brand_color;
      }
}

這例子應該很容易理解吧，相等於以往的：

#container div {
    color: #F0F;
    border: none;
}
#container p {
    color: #F0F;
}

壞消息是，用 less 寫成的檔案需要在 Unix based 的電腦上編譯過後方能變成真正的 CSS；好消息是，有人寫了個小工具 less.app 可以完成這項工作，使不懂得用 terminal 的用戶也能夠使用。在 window 下貌似沒有簡單的解法…

less 官方網站：http://lesscss.org/
less.app (GUI): http://incident57.com/less/

無論你的立場如何，無論你對反高鐵或「八十後」有甚麼意見，我不奢求你明白，只想你了解，這些市民是真切地愛著香港這片土地，並用過最和平理性地的行動去為我們乞求、爭取一些原本屬於你我的東西。

大可以不認同他們的行為或政見，但請認清事實，不要亂信傳媒，抹黑他們。他們為這片土地付出太多，無論誰對誰錯，亦值得我們萬二分尊重。

希望香港不久的將來，人民可以用自己手上的一票去為自己發聲。

做 web development 的人應該都會用過 JSLint 或 JSONLint 這些線上驗證工具。日前連 jQuery Lint 也出爐了。 jQuery Lint 的目的也是提供一個工具協助 programmer 寫出更好的 jQuery code（例如 $(el).css(...).css(...).css (...) 可簡化成 $(el).css({...}) ）。

跟 JSLint 和 JSONLint 不同， jQuery Lint 是個 run time reporter，安裝後所有訊息會顯示在 FireBug 上。安裝 jQuery Lint 只需加如下一句：

<script src="jquery.lint.js"></script>

jQuery Lint 提供的訊息頗為詳盡，除了簡單錯誤報告外，還提供修改建議、問題代碼、甚至相關的 method signatures 。

下載及 API 請到 http://github.com/jamespadolsey/jQuery-Lint

高鐵常見認知謬誤

1. 『高鐵打造一小時生活圈，到廣州只須48分鐘』
   錯！所謂廣州南站的石壁其實位處番禺郊區，如果要去天河要再轉乘十八個地鐵站。
2. 『高鐵能「造大個餅」，令更多人來香港』
   錯！1月8日立會會議上，在梁家騮的逼問下，鄭汝樺親口承認政府不假設高鐵會令更多人往返中港。
3. 『過去十年跨境數字不斷上升，高鐵好有需要』
   錯！在跨境數字上升的背景下，真正蓬勃發展的是點對點的直通巴而非鐵路！
4. 『高鐵快過火箭，每小時300公里』
   錯！三百公里只係地面時速，地底會慢很多，不然會很危險。而幾乎全程高鐵香港段都是於地底。而且高鐵要用26公里才能加到最高速，而福田與西九只相差30分里。因此高鐵的平均時速只有每小時130公里。
5. 『每日會有99000人搭高鐵？』
   錯！政府每次都高估載客量。政府曾話機鐵2011年每天75000乘客，但現在只有28000人；政府話深港西部通道2011年每天有46000車次使用，但現在只有7000車次！你信唔信政府？你信唔信高鐵可取代需時接近、點對點並且平一半的直通巴？
6. 『有左高鐵就唔駛下下搭飛機去北京上海，仲要平d』
   錯！85%的高鐵客量都是以深圳及廣州為終點站。在每日只有三班高鐵、但有三十班飛機到上海的情形下，高鐵顯然不能成為飛機的 alternative。何況，以現時內地票價計，坐高鐵到北京也要千二蚊一程，與平價機票相去不遠，但慢好多。
7. 『高鐵能帶來五十年870億，或每天五百萬的經濟效益』
   錯！中大蘇偉文教授指高鐵票價每程要收1800元才能回本，而現在是只賣180元！客量更極有可能偏低！經濟效益只係吹水。何濼生教授指出政府出資六百多億元，要計利息成本，光是利息一年已蝕逾二十四億元，這筆錢還要年年蝕，永無止境。
8. 『高鐵已經經過三年多討論，不能再拖延』
   雖高鐵計劃的討論從三年前開始，但絕大部份實質數據、細節只是在近半年才公布。所以高鐵方案被真正討論的時間其實很短。

所需時間

從旺角出發到廣州

• 190蚊高鐵到廣州 = 20分鐘到西九 + 48分鐘高鐵 + 30分鐘過關 + 1 小時廣州地鐵 = 近3小時
• 110蚊東鐵轉廣深線火車到廣州 = 40分鐘東鐵 + 30分鐘過關 + 30分鐘候車 + 1小時廣深線 = 近3 小時
• 80-100蚊搭直通巴到廣州 = 連過關3小時

從旺角出發到福田

• 55蚊高鐵到福田 = 20分鐘到西九 + 12分鐘高鐵 + 30分鐘過關 = 1小時
• 45蚊東鐵轉深圳地鐵到福田 = 40分鐘到落馬洲 + 30分鐘過關 + 10分鐘深圳地鐵 = 1小時20分鐘
• 40蚊直巴轉深圳地鐵到福田 = 45分鐘到落馬洲 + 30分鐘過關 + 10分鐘深圳地鐵 = 1小時25分鐘

旺角尚且如此，新界出發呢？你會先南下西九再北上嗎？
那麼，669億公帑買了甚麼，除了炒起西九豪宅之外？

高鐵造價

• 北京至石家莊高鐵造價︰每公里1.8億
• 石家莊至武漢高鐵造價︰每公里1.6億
• 武漢至廣州高鐵造價︰每公里1.1億
• 廣州至深圳高鐵造價︰每公里1.8億
• 國際平均高鐵造價︰每公里1.6-1.9億
• 香港段高鐵造價︰每公里25億，而且必定超支

中港交通基建

• 皇崗口岸
• 文錦渡口岸
• 深圳西部通道
• 東鐵羅湖線
• 東鐵落馬州支線
• 興建中︰港珠澳大橋
• 擬興建︰蓮塘口岸、港深機場鐵路、港鐵北環線

還需要嗎？

結論︰

669億高鐵經濟效益 = 吊腳西九 + 天價公帑 + 快鐵慢檢 + 番禺郊區接駁至廣州巿區 + 毀人家園 + 噪音廢料 = 廢鐵

（本文轉自中大學生報，經本人略為修改）

每參與一個新 project，我總會第一時間問用不用支援 Internet Explorer 6，答不用支援的一般都是不憂財源的公司。所幸某公司一直沒有支援 IE6 的傳統，加上自從轉用了 Mac 以後，開 IE 變得很不方便，已經很久沒 debug IE 了。

最近看見有人寫了篇 IE6 bug 大全，整理收集了一堆 IE6 bugs。其實要找 IE CSS bugs ，我推薦一個好地方：Explorer Exposed 。這個網站收集了很多常見的 IE CSS bugs 及其解法（不限 IE6），對工作極有幫助。另外，在《Ultimate IE6 Cheatsheet》這篇帖子裡，也介紹了多種方法去補足 IE6 功能上的缺陷，例如半透明的 png、圓角等。

老實說，不提複雜一點的 floating、positioning ，Microsoft 要怎樣寫才能寫出 double margin 這些不合邏輯的 bugs 呢？與其說 bugs，倒不如說是瘟疫更為貼切。

不知道當年的 IE6 developers 敢不敢在自己的 resume 上寫自己曾經開發過 IE6 呢? XD

PS: 有人會為 IE 8 debug 嗎？還是都是強行轉成 IE7 算了？

上圖出自：IE6 denial message for Momentile.com

Web debugging proxy 可以用來記錄，甚至修改所有你電腦的 HTTPS traffic，大大方便了我這些 web developer 的 debug 工作。以前用 Window 的時候我一般會用 Fiddler 作為我的 web debugging proxy ，但自從成了 Mac 用家後，就得另尋一套新工具。

Charles 是套 java based web debugging proxy tool，可以在所有 OS 上運行（包括 Mac），支援 Internet Explorer, Chrome, Safari 及 Firefox （需安裝 Plugin），而且介面比 Fiddler 好看易用得多，是我目前最喜愛的開發工具之一。其實不止開發 web app 時會用上它，開發任何跟 HTTPS traffic 有關的應用都可以用得上，包括 Flash、Firefox plug-in，iPhone app。

當中最常用到的，是透過 Charles 的 Map local 功能，它容許我在不上傳檔案到 server 的情況下 debug css / javascript，大大增加了 debug 的效率。要知道很多 bug 只存在於 production environment，有時又不能直接把 code upload 到 staging server，有了 mac local 就省了很多麻煩事。

此外 Charles 還可以模擬慢網速的情況，都是很實用的功能。只是這套軟件並不是免費，有興趣請到 http://www.charlesproxy.com/ 。

初看到 JavaScript Closure Compiler 這個名字的時候，我很好奇，因為 compiler 這個詞一般不會跟 JavaScript 扯上關係。原來這個個由 Google 用 Java 開發的 Javascript 壓縮工具。

Google Closure Compiler 提供三種壓縮方法，分別是空格移除、簡單壓縮及進階壓縮。簡單壓縮基本上只是把 comments 和空格拿走（跟 YUI Compressor 基本一樣）；進階壓縮除以上功能外，還能夠 rename variable name、甚至重寫某些 statement！很好很強大！

Google JavaScript Closure Compiler 有單機版和線上版兩款任君選擇：

1. 按此下載 Javascript Closure Compiler
2. 網上版 Javascript Closure Compiler
   

附官方英文版簡介：

Closure Compiler is a JavaScript optimizing compiler. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what’s left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls. It is used in many of Google’s JavaScript apps, including Gmail, Google Web Search, Google Maps, and Google Docs.

相對於 programing ， design 往往是感性的，沒有標準答案。所以要設計出一個好作品必需對完美有所追求，而這往往要求 designer 有無限的耐心，更要有走彎路的決心。（當然這也同時要求公司有足夠的時間資源提供）

這個 video 展示了一款 iphone app 的 UI 設計過程，完全可以看出該 designer 花了多少時間與心血在此之上啊。

Convert Design Evolution from tap tap tap on Vimeo.

較早前讀到一篇《The Definitive Guide to GET vs POST》，簡釋了一下 GET 和 POST 的優缺。並總結了 4 條準則：

• 用 GET 來處理比較安全的動作（例如 search、view 等），因為 GET 可以被 cache 及 share 的特性；
• 用 GET 來發送 ajax request，因為 POST 要先 send header 再 send 內容，比較麻煩；
• 用 POST 來處理長的字串，因為 GET 的上限為 2048 個字符；
• 用 POST 來處理敏感資料；

該文附送一張 work flow chart 一張，亦是我會轉載至這裡的唯一原因：

－－－－－－－－

願死者安息，望生者堅強。

Front-end developer 一定對傳統的 css image replacement 很熟悉：先為文字設定一個背景圖片，再把文字用負數的 text-indent 隱去，這樣一來一往就只剩下圖片了。以前學習 css 時，都說這個方法有個優點，就是在沒有 css 的情況下（如手機、Google 的 bot），網頁依然保持可讀。只是，這方法在有 css 卻沒有圖片的情況下則表現得一團糟了：圖片沒有了，文字也沒回來。

最近有人提出一套叫 State Scopes Method 的辦法，可解決以上提到的這個問題。解決方法是這樣的：先測一下瀏覽器是否能夠正常顯示圖片，正常的話才做 image replacement 的工作。

但這個辦法的缺點也很明顯：需要用到 Javascript，寫 css 時也變得麻煩。下面是一段 css

h1 {
  width: 100px;
  height: 50px;
}
@media screen {
  .images-on h1 {
    text-indent: -10000px;
    background-image: url(image.png);
    overflow: hidden;
  }
}

其實我個人覺得舊方法已經足夠好了，實在沒必要為了那一小部份人（可能是零）花這麼多功夫去完善 css。這些知識，知道就好了。

詳情請參考：The State Scope Method of CSS Image Replacement

－－－－完－－－－

在下現在是 香港中文大學 計算機科學系 一年級生。

對一件事情很不滿，身為香港的中文大學，為甚麼要捨香港通譯「電腦」不用，反而跟隨國內譯法把 computer 譯成「計算機」呢？