剛讀到這篇 Component Directory Lockdown 新聞時,乍看標題誤以為 Firefox 3.6 中所有的 XPCOM components 都將被閹掉、無法使用了。認真讀了火狐人肉盾牌 (Human Shield) Johnathan Nightingale公告、以及 Vladimir Vukićević詳盡說明,知道關掉的是官方自動載入 Firefox 安裝目錄下的 components 目錄。

其實是為了一些惡搞軟體所下的限制,特別是在 Windows 平台上。許多 Windows 使用者都會安裝一些防毒軟體、輔助工具等等,許多 Windows 上的工具軟體常便宜行事,會偷偷在 Firefox/components 目錄下塞入自己的 XPCOM 元件,藉此置入功能到 Firefox 中。在 Firefox 的設計中,這些 XPCOM 元件都會依照其宣告被自動載入、執行。

問題在於不少軟體的作法都是射後不理,軟體公司常常依照特定版本的 Firefox 開發其 XPCOM 元件,安裝時強制安裝該元件檔案到 Firefox 的 components 目錄,然後就不管了。隨著時間演進,使用者可能會升級 Firefox,結果這些非官方的 XPCOM 元件未被升級,造成相容性問題而使整個瀏覽器當掉。

XPCOM 是設計來接取一些基本的系統資源、或與其他函式庫介接,若是 API 版本不合,不小心會造成當機、安全漏洞或系統損毀。特別是 XPCOM 不同於 Extension,在瀏覽器一執行時就會載入,也不作版本驗證。對於使用者而言,也無法像擴充套件一樣,透過設定介面關掉或移除有問題的外掛。於是使用者很容易就怪罪這個瀏覽器不穩定。

於是,在 Firefox 3.6 中,將只載入寫在 components.list 的官方元件。一般開發者若想使用 XPCOM 元件,應該使用包裝成 extension 的形式,讓系統自動安裝,詳細的技術細節請參考 Mozilla 開發網站

若想利用 HTML 5 開發一些多媒體程式的網站,你大概會需要一個本地檔案處理的 API 來儲存影片、圖檔等。同時你大概也會希望創作一種類似桌面系統的使用經驗,讓使用者可以直接從原生作業系統拖拉檔案到你的 Web Apps 中。而檔案塞進網頁程式後,又可以製作成縮圖,讓使用者透過網頁介面進行管理。

這些功能在 Google Gears 0.5.21.0 皆已經實做,包含了支援 Bolb, Blob BuilderDrag & Drop supportImage thumbnailing

除了 Google Gears 的實做以外,其實從 Gecko 1.9.2 後在 Firefox 3.6 與 Fennec 1.0 也支援了這些直接利用 Java Script 進行檔案處理的功能。於是你可以利用 Java Script 刻一個的檔案瀏覽器工具,拿 FileList 來接受使用者拖拉進瀏覽器或自選的檔案列表,用 FileReader 作一些簡單的處理,像是把圖片丟進 Canvas 讓使用者改一改後,再傳到網路上伺服器存放等。依據安全性考量,你自然不能直接拿 File Reader 來讀系統檔案,File Reader 的參數都必須是使用者自行選擇帶入的 File 型別才可以。如此便可避免拿 Java Script 作壞事的機會。

Mozilla 的 Arun Ranganathan 已提交 File API 一案至 W3C 供獨立審核。其他關於 HTML5 的 API 請見我的 blog,或參考 Mozilla 的 HTML5 support in Mozilla

關於 Web Typography。過去,你若想讓網頁上出現多樣性的字型與排版,往往得將文字作成圖片或 Flash 來顯示。如此一來常常使網頁失去文字複製、搜尋引擎最佳化 (SEO) 的功能,一個網頁製作再精美,但卻沒有人可找來閱讀的話,也是徒勞無用的。

於是你想使用瀏覽器預設的功能,但又不想屈就於有限的作業系統內建字型,這該怎麼辦?你或許會利用像是 sIFR, FLIR, Typeface.jsCufón 等替代方案。

sIFR (Scalable Inman Flash Replacement) 來講,sIFR 是利用 Java Script 與 Flash 動態的替換瀏覽器上的文字,字型則來自網頁設計者預先從系統中設定欲使用的字型於 Flash 中。

而 Cufón 概念亦差不多,不過作法是先將字型外型轉成 Java Script/JSON 格式,實際使用時再利用 HTML5 Canvas 繪出字型。Cufón 的作法所生成的 Java Script 雖比所用的 Truetype 字型小,但其實檔案大小也頗大,BCSEEATI 試驗了一分割字型方式,可有效降低傳輸量,但需把字型計算工作轉移到伺服器端。

Cufón 的一項缺點是,用了 Canvas 來繪圖,結果造成使用者無法點選文字。關於這個問題,TypeSelectTypeface.js 用 span tag 解決的選字的問題。這些作法都頗討厭,因為你要求瀏覽器為了美觀顯示,多做了圖形運算或重複塞了一圖一字就為了美觀跟可選字。

若是可以讓瀏覽器直接依字型繪字不是很好嗎?在 Firefox 3.5 (Gecko 1.9.1) 後,Firefox 開始支援了 CSS 的@font-face 語法。於是,你有機會可以用 font-family 來指定一些擺在網路上 TrueType 或 OpenType 字型,直接讓流覽器繪出美麗的文字 (中文版: 顛覆網路 35 天 (4b): 以 @font-face 使用你喜歡的字體 by BobChao)。 文泉驛的雲字體計劃便是應用 CSS 更換字型的例子之一。

但是對於字型廠商來說,並不樂見讓你隨意在網路上使用 TrueType 或 OpenType 字型。主要的原因就是版權濫用,同樣的一套字型很可能會被大量複製。另外,對於瀏覽器開發者而言,納入 DRM 控制網頁用字型顯然是與網路傳統背道而馳。對使用者而言,這兩種格式都太大,會浪費相當頻寬下載所需字型。

就頻寬的問題而言,其中一種解決方式如 Microsoft 所倡議的 Embedded OpenType (EOT),解決方案是以工具掃瞄網頁,並從字型檔中抽出網頁所需的字型。這樣的確可以降低頻寬使用,但是總覺的每次都要產生特定的字型檔實在有點太麻煩。

比較好的作法或許使利用壓縮的機制來降低傳輸量。Mozilla 的 Jonathan Kew 於是提議了一種新的規格 ZOT,基本上就是 OpenType 的壓縮,但壓縮的是 SFNT 字型檔中的獨立表格。這種格式的好處是有效壓縮字型檔大小,在 Web Open Font Format for Firefox 3.6 一文中提到,此格式可將 3.1MB 的 TTF 字型檔壓縮成 1MB 左右。另外一個好處是由於 table 獨立壓縮,因此像是記憶體容量較小的行動裝置,可以下載字型後依照 cmap 表格找到相對應的字型,依照需求再逐一解縮壓,可解省些系統支援。

另外一個需求會是版權的問題,Jonathan Kew 倡議 ZOT 時,同時有人為了字型供應商的需求做了 .webfont 格式。基本上的用意是希望能夠在字型中夾帶一些 metadata,使供應商可以追蹤網站所使用字型是否符合版權,但是不加以 DRM 保護。這個提議已經得到一些字型供應商的支持

這些規格加起來就是 WOFF File Format 在新釋出的 Firefox 3.6 中,預定支援 Web Open Font Format (WOFF) 之格式。ars technica 有一篇詳盡的報導 Web Open Font Format backed by Mozilla, type foundries,介紹了 WOFF 中的一些規格演繹與技術說明。在 after Firefox 3.6 – new font control features for designers 一文中有相當精彩的字型應用展示,如利用網頁字型重現傳統印刷字等。

目前此規格已經在 W3 的 Web Fonts Working Group Charter 中,目前只有 Firefox 支援 WOFF,接下來要便看其他的瀏覽器是否願意支持此規格了。可於 www-font 郵遞論壇追蹤最新的進展。

2009-12-02 後記: John Boardley 的 Web fonts. Where are we? 亦相當有參考價值。簡體中文翻譯請見關於 Web 字體:現狀與未來

先前裝了 HelloTxtUbiquity Script 來用,以便於可以在 Firefox 中直接用 Ubiquity 介面來更新自己的狀態到多個微網誌。不過 Hellotxt 的 script 是針對早期 Ubiquity 版本所撰寫,因此在 0.5 版釋出後,原 Script 不相容於新 Parser 2 API,因此幾個月前就無法使用了,官方也一直未修正。於是自立自強的依照 Parser 2 API Conversion Tutorial 修正一版,可於此網址安裝或下載 patch

自己已經用了 Ubiquity 一陣子,目前使用經驗良好,值得推薦給你使用。但網路上介紹已相當多,除了 Mr6 的「開啟比 Google寬一千倍的路」目光短視的膚淺廢話不要浪費時間之外,其他的使用面介紹都可參考。這裡就不多費唇舌,你想了解基本的使用方法可以參考 Ubiquity 0.1 實際操作過程的精彩影片示範一文。

若可聽讀英文或日文,可讀 mitchoTokyo 2.0 的精彩演講 Ubiquity: Command the Web with Language 言葉で操作するWeb (簡報),mitcho (Michael  Yoshitaka  Erlewine) 現在是 MIT Department of Linguistics 博士生,之前在 Mozilla Lab 擔任研究員開發 Ubiquity。

Ubiquity 的指令與功能極多,逐一介紹極耗時,請安裝後利用 list ubiquity commands 指令取得各項功能說明。

自從新版的 Ubiquity 的 Mozilla Web Search Commands 整合了 Firefox 的 Open Search 功能後,我就可以直接用 search 指令查詢自建的 Open Search Plugins。過去雖然依照自己的需求建立了十幾個不同的 open search plugin 來找不同的郵遞論壇BTS、搜尋引擎、拍賣等,但是用滑鼠切換搜尋引擎絲毫沒有可用性可言。

新版的 Ubiquity 可讓你利用鍵盤快速搜尋所選文字,而且常用的指令會排序再前頭,也可以直接選擇文字後透過滑鼠右鍵執行該指令。因此除了內建的 IMDB, Wikipedia 外,我自己最常用得就是 amazon, aNobii, FindBook, 博客來臺北市立圖書館館藏間互查書籍,一邊在 aNobii 規劃書單,一方面在不同的地方查詢藏書。

過去查詢一本書,你得「複製」、「開啟新頁」、「連上特定網站」、「貼上」、「搜尋」等幾個步驟,現在一樣是選取可以直接用右鍵選擇該服務,或者叫出 Ubiquity 的搜尋介面鍵入該服務名稱即可,也避免在複製貼上間還得找網頁的輸入欄位。剪貼行為總是很快讓我進入昏睡狀態。

另外一個值得提的指令是 Marcello Herreshoffcreate search command,之前建立自己的 Open Search plugins 程序其實有點複雜,即便利用 Ready2SearchSearch Plugins Generator 等工具也需要一些步驟。這個指令只要選定一個搜尋欄位,鍵入 create search command 名稱 就會自動產生一組 Ubiquity 專用指令,一行程式都不需要寫!非常好用。另外你也可以利用 create bookmarklet command 把你常用的 bookmarklet 轉成 Ubiquity 指令。

即便我自己最常使用的還是搜尋引擎等指令,但是我相當看好 Ubiquity 的未來發展。不少人認為 Ubiquity 僅多提供 Web 的 CLI 的介面,也有些人質疑指令列根本就是走退路,未能體會 Ubiquity 的多國自然語言介面設計理念。

事實上,對電腦下命令不難,難的是背指令後依照指定語法下命令。

CLI 介面最令人畏懼的是得背下指令名稱,還得依據其指定之語法給予參數。而多國自然語言介面的設計用意就是,讓使用者盡量用熟悉的口語方式給予指令,不讓使用者強記。替代日漸繁雜的選單與功能列,取而代之是選取文字後使用「search this with Findbook」、「到 Findbook 查這個」的這種指令方法。

在新版 Ubiquity 的 Parser 2 中,Ubiquity 帶入semantic roles 的指令設計,搭配先前設計的名詞詞性 (Nountypes),可以更精確的分析使用者欲執行的指令。再研究過眾多語言的文法架構後,在語意分析器設計上也可有彈性的適應於不同語系,現在你可以依照自己的語言特性設定 Branching、斷詞等方式,讓分析器再判斷完介係詞、分隔字後正確判斷文句意義。因此未來除了現有的英文語系之外,你也可以使用中文來下達指令,再接下來的計畫中,也會納入 Command chaining,於是或許接下來你就可以直接對電腦說「到 Findbook 查這個並寄給 Rex」這種語法。

不少人拿 Ubiquity 跟一般桌面的 Launcher applications 作比較,像是 MacOS 上的 Quicksilver 介面,或 Linux 上的 Gnome-Do 等。但是桌面系統的特性畢竟跟網頁略有不同,許多桌面工具並非文字導向,應用上並沒有像網頁間互相傳輸字串那樣自然。

我最期待的幻想其實是希望這套系統可以置入行動裝置,並結合語音辨識功能。雖說現在許多智慧型手機已內建語音辨識,但常常都還只是啟動電腦或直接撥打電話這樣程度的應用,軟體若可以知道自己接受哪些參數,或許就可以利用觸控螢幕輸入欲傳送之「物件」(object) 並用語音給予指令了。這樣的應用相對只需要聽懂指令,可以避免以語音給予「物件」數值時容易聽錯的缺點。

最近,追蹤了一些在 HTML5 draft 上的新規格,試著想跟上一些更動,一方面嘗試新 API 的用法。基於 HTML5 的強大功能,未來只用 HTML 與 Java Script 便可以實做出許多的網頁版本的應用軟體,在行動裝置如 iPhone, Palm webOS 上已經有許多軟體或小遊戲之實做。其中一項感興趣的功能是離線 Web Apps 的應用。這篇文章稍微紀錄一下相關的規格。

若想進一步瞭解 HTML5,可參考 Google 的 Brad Neuberg 的演講 Introduction to HTML 5Ian HicksonHTML 5: Features you want desperately but still can’t use 的展示。Ian Hickson 是 Web Applications 1.0/HTML 5 specification, CSS 2.1 的規格作者之一,也是 Acid2, Acid3 的維護者。

Offline resources

離線網頁的第一個問題,是必須使頁面中所使用的各項網頁、圖片先行快取於系統中。欲達到此目的,規格中定義了一個 manifest 宣告機制,你必須在此檔案中宣告所有欲快取之檔案列表。規格中亦定義了一組 Application Cache API,使你知悉目前快取狀態。

Offline resources 功能已經包含於Gecko 1.9.1/Firefox 3.5 中。

Online and offline events

若要作離線程式,第一個要判斷的可能還是網路連線狀態,雖說有時會是電腦依然接在網路上,但是卻連不上網路的狀態,但是若系統可以自行告知目前連線狀態,就可以省下不停確認連線狀態的白工。在 Debian GNU/Linux 上,若使用 NetworkManager,瀏覽器如 Iceweasel 會自動依照網路狀態切換狀態。

關於連線狀態之規格定義在 Browser state API 中,在 Firefox 3 中已可取得連線狀態改變通知

Client-side Storage

關於儲存離線使用的客戶端資料,在不同的瀏覽器中有不同的作法。像是早期 Firefox 2 (與 IE8) 的 globalStorage、Microsoft’s userData、Flash storage、Google GearsDatabase API 等等。原則上有兩種形式,一是 key-value 為主,另一種則是 SQL 語法導向,在 HTML 5  中有兩份規格,可以用來儲存離線使用的客戶端資料,一為 Web Storage、另一則為 Web Database

Web Storage 即為 key/value 形式的 API,在 Firefox 3.5 後已可使用相容於規格的 DOM Storage API. 而 Web Database 則提供給開發者利用 SQL (SQLite) 的語法直接管理資料庫,但除了特別需要搜尋功能外,我其實頗懷疑還有多少人願意用 JS 寫 SQL 語法。目前尚未見到 Firefox 實做 Web Database API,類似的 API 是 mozilla.org/storage/service,此 API 只能提供給 Firefox Extension 使用,尚無法直接應用於網頁中,網頁中必須透過 XPConnect取得權限才能使用。實際的作法可以參考 Klaus Förster 的 Offline SQLiteSVG database applications with Firefox 一文。

Other APIs

雖說目前已有較新的瀏覽器開始逐步支援 HTML 5 規格,但是基於跨平台的考量,目前最方便的 API Framework 應該暫時還是 Google Gears。這麼說得主要原因是因為其支援眾多平台,Firefox 1.5 之後、Safari 或者 IE6 以上皆可支援,甚至也支援一些 Windows Mobile 5 或 Android 平台,自然 Google 自己的 Chrome 瀏覽器也是內建支援的。跨平台支援,大約是網頁開發者最想避免的痛苦之一吧,在 HTML 5 普及前,若你願意使用 Database API 的 SQL 語法,Google Gears 可以減輕一些痛苦。另外 Google Gears 比 HTML 5 還好一點的特色是,Database API 讓開發者直接作全文搜尋,此乃利用 SQLite 的 fts2 模組。

或者,也可以利用一些 Java Script Library 來避開平台問題,讓 Library 自己選擇適當的儲存機制,像是早期的 Dojo Offline ToolkitPersistJS,或者我自己比較偏好使用的 jquery-jstore

新版的 Google Gears 0.5.21 (Released May 29, 2009),還支援 BlobCanvas。Blob 可以讓你在瀏覽器中存取一些二進位的檔案。Canvas 最大的用處大概是拿來縮圖,並另存檔案吧。0.5.21 中也增強了 Desktop API,Desktop API 除了最強大的製作捷徑 (createShortcut) 功能外,也新增了猜(圖片)檔案格式的 extractMetaData,跟可以處理檔案拖拉進瀏覽器處理的 getDragData。

目前的狀況,若想直接使用 Google Gears 同步網站資料,依然需要自己花費一些精力配合自己的伺服端 API 整合設計。一個需要考量的技術瓶頸是得避免同步抓取時,使網頁下載、解讀速度變慢,影響使用者的使用經驗。雖然這個問題可利用 WorkerPool 進行背景下載 (見 Google Gears 架構之  Background Sync),但依然必須攥構一快取與同步機制。

我更感興趣的是 Vladimir Vukićević 所提出的看法,他提議或許可用 CouchDB 來處理資料儲存的問題。而 Atul Varma 發表了他的新嘗試 BrowserCouch,用 Java Script 重作 CouchDB 的 API,目的是若上線狀態,可將資料存進「雲端」,而離線則可用本地快取。這種作法相當接近我期待中的系統架構。

話說,為了新的 HP Pavilion dv3509 裝了新版的 Firefox 後,發現在 Microsoft Vista 上瀏覽器三不五時就當機一次。Firefox 時常跳出 Microsoft Vistual C++ Runtime Library – Runtime Error, abnormal program termination.

一度還以為 Firefox 跟 Microsoft Visital Home 有相容性問題,或者新購入的筆記型電腦的記憶體出了。後來反覆查了查,發現是指紋辨識資料安全系統 Digital Persona 的問題,系統預設會安裝 DigitalPersona 擴充套件。根據網路上的反應,看來他除了跟 Firefox 3 不相好,時常當機外,他也會妨礙你下載檔案,在加上似乎還有 memory leaking 的問題,我看還是暫時關掉他吧。