Use Firefox OS "lightsaber" on Flame

EN: I'll make a note as a "lightsaber quick install guide" here.

Firefox OS 新的 Add-on 等功能都在 lightsaber 上，要安裝稍微得費點勁，這邊分享一下最速達陣手法：

「不必」自己 build Gecko

EN: You don't have to build the whole gecko from mozilla-central, just use the nightly and it works. Check Updating your Flame and choose the https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/ builds.

lightsaber 上面叫你自己從 mozilla-central 重新自建 Gecko，但其實光是要嘗試新東西的話無此必要，只要更新 Flame 到 mozilla-central 的 nightly-build 就好：

https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-kk/

如果不知道怎麼升級，請見 Updating your Flame

拿把光劍

EN: then, follow the quick setup section in the README.md of lightsaber, but be sure to remove the "GAIA_DEV_PIXELS_PER_PX=2.25" part.

接著就要把光劍裝上去，其 Readme 裡有最速捷徑：

sudo npm install -g bower && sudo npm install -g gulp && sudo npm install -g apm && sudo npm install -g grunt-cli && sudo npm install -g browserify
git clone https://github.com/fxos/lightsaber
cd lightsaber
make install
make sync

我這邊故意少複製了一行，原因有三：

1. 我在 make sync 時有跳錯誤，如果發生錯誤無論如何就上網查一下，通常都是什麼東西沒裝好。
2. 這邊有可能會問你要裝哪種 gaia-icon，我反正是挑最新的
3. 這份 Readme 主要寫給 Z3C 用，如果你好傻好天真地照辦那在 Flame 上就有問題了。

最後一行是真的要把 Gaia 裝上去，作為日用機，我常用的參數是這樣：

• 要掛 Mozilla 的品牌: MOZILLA_OFFICIAL=1
• 日用，跳過測試用 App: PRODUCTION=1
• 跳過啟用導覽與設定: NOFTU=1
• 開啟 adb 連線除錯: DEVICE_DEBUG=1
• 開英文跟注音鍵盤: GAIA_KEYBOARD_LAYOUTS=en,zh-Hant-Zhuyin

如果你也要裝中文語系和設定上去，參考小帥提提供的古早資料，將語系抓下來，再以 language.json 指定一下啟用的語系即可。你的最後一行指令可能長得像這樣：

DEVICE_DEBUG=1 PRODUCTION=1 MOZILLA_OFFICIAL=1 GAIA_KEYBOARD_LAYOUTS=en,zh-Hant-Zhuyin LOCALE_BASEDIR=locales/ LOCALES_FILE=locales/l.json make reset-gaia

最後

沒有下一步了，就是這樣喵。雖然手上有 Flame 又不屬於 MoCo 的華人不多，但還是分享一下順便當自己的筆記 -- 我近兩年前寫的 build Firefox OS 筆記，現在還是很好用 :P

Firefox 附加元件：用 Markdown Here 在 Blogger 上發文

因為公司的系統常用 markdown，在這幾個月裡我也開始慢慢熟悉語法，就想找些方法以後用 markdown 寫 Blog。我之前大多使用 HTML 編寫，大致的缺點就是比較慢… 改用 markdown 應該會快很多，至少有點 tag 潔癖的情況下，用 markdown 似乎可以確保出來的語法整潔？
不過由於自己的 blog 在 Blogger，多少也有改點佈景，實在有點懶得搬家到別的地方，於是開始找「能在 Blogger 上寫 markdown」的方法。目前大部份的教學文件都要你轉個方向走，例如：

• 先用 markdown 編輯器寫、轉成 HTML、再把 HTML 貼上來：想也知道我不可能選這個啊…
• 利用其他有整合好的編輯器，把「轉成 HTML 在貼」的工作盡可能自動化：缺點是 Blogger 上的一些文章設定沒那麼方便，變成寫好要再回來調整，且不一定有辦法上傳圖片…

後 來找到這個 Firefox 附加元件 — Markdown Here，似乎還 不錯，他其實只是把 Rich Text Editor 裡的 markdown 純文字轉換為 HTML 內容，但這樣便讓相容性提高了許多 — 理論上可以相容任何 Rich Text Editor 網站。
目前試用有些缺點：

1. 為了在 HTML 跟 Markdown 之間互轉，它在產出的 HTML 碼裡會塞一些有點醜的原始碼編碼… 外觀看不到，但看 Code 很醜，且重點是大幅增加了頁面所需的 data
2. 另外它預設會添加很多 style… 這個要去設定裡把它的 Style 全部清掉。其實這個設定原意也是讓頁面更漂亮，但遇到你自己本來就會加 CSS 的 Blog 時，還是全拿掉吧…

或許用一用會決定要來自己改他的 code，但無論如何有興趣的朋友可以試試看 :)

下載 Markdown Here

Now you see me, now you don't

UX Build 開始調整關閉鈕的空間，目前的設計是分頁超過一定數量後會隱藏關閉鈕... 還可以，視覺上是簡潔了點，但沒有非常喜歡就是（個人比較偏好要固定出現關閉鈕，畢竟 Firefox 的分頁有最小寬度、不必像 Chrome 一樣為了避免誤按而藏起來）。

Firefox 的新界面 Australis，分頁部分

已經開始有些媒體針對這個新的界面撰寫報導，事實上現在你也可以透過 UX Build 玩玩看。大家一眼就會看見的是分頁，我想順道就針對分頁的更動列出幾個自己覺得重要的事情：

弧線

Australis 的線條大概是目前瀏覽器裡最「弧」的一個（剛巧 Firefox 也是最「狐」的瀏覽器 -- 冷！）

上：Australis (in UX Build)   下：Google Chrome

 以我所知，有幾項設計理由：

• Firefox 在各版本間開始追求的、一致的設計語言：柔軟、友善，很多稜稜角角的東西都改成圓弧狀了。這樣的風格早已在 Firefox for Android 上呈現，現在桌機版只是（終於要）跟上而已。
• 速度感：不要問我這是硬扯的還是真的，反正有張投影片是在描述，這樣的弧線有跑車似的流線型感覺... 好啦是有流線啦，有沒有反映到感覺上，我就不知道了。

好看嗎？難看嗎？我覺得看久倒是意外的順眼，當初 Thunderbird 剛換上這個主題時個人讚譽有加，Firefox 換上多少有點不習慣（TB 跟 Fx 開的分頁數目有巨大差異），但使用 UX build 一陣子之後，我是還蠻喜歡的。

強調當前分頁

目前的設計加強「目前分頁」的存在感。一方面拜弧線所賜，相較於舊的設計確實更有「從網址工具列長出來、是一體的」的感覺；二方面，此設計削弱了背景分頁的存在感，除去框線使其融入標題列中。

有人覺得這會造成背景分頁較難辨識與瞄準，我是還好；但無論如何，帶來的好處倒是顯而易見，整個瀏覽器的分頁列確實變得更乾淨、更不打擾 -- 不打擾是 UI 設計上大家都想追求的東西，很高興 Firefox UX Team 不僅僅用砍掉元素的方式來整理標題列，在色彩、線條的設計上也投下心力。（例如，除了背景分頁框線不見之外，你有注意到兩個相鄰背景分頁之間變成直線嗎？）

其他

一定爆炸多人覺得這根本抄 Chrome，且不論每個瀏覽器都有上一頁下一頁、每個電話都有掛斷的鍵，我就舉幾個在分頁列部分跟 Chrome 一樣或不一樣的地方：

• 標題列不見了，有人討厭有人喜歡，我是喜歡的那一派（我之前一直比較喜歡 Chrome 在這部分的設計，精簡）
• 每個分頁的關閉鈕還在：雖然實際上用到的機會不大，相較於 Chrome 的背景分頁沒有關閉鈕，我比較喜歡讓它一直存在。
• Chrome 分頁太多時基本悲劇，還好 Australis 仍然保留這部分的堅持:

又，PTT 上莫名其妙有很多人覺得這樣的設計會浪費空間 -- 怎麼會？東西都要搭配各種環境一起看的，且讓這些截圖告訴你：

 

其實 Australis 的一大要點是凸顯「自訂」這件事情，此處的體現大抵藏在那個真的從 Chrome 來的 Menu 選單中。之後有機會再分享我的看法。

如果你有興趣要瞭解 Australis，可以參考 Wiki 上的設計文件及當時用來展示的草稿圖。

聲明

大概有人會覺得上面這些偏好單純因為我很少用 Chrome，事實上我不但每種瀏覽器都用（是啊，我想多瞭解），在過去半年也都用 Chrome 當主力瀏覽器。青菜蘿蔔各有所好，如果我剛巧就是喜歡某個多些，別覺得我太偏袒哪 :)

HTTPS 的 referrer 狀況筆記

很快筆記一下，周三去聽喬后演講時，她講了個我從前不知道的事：HTTPS 的網站連向 HTTP 網站時，瀏覽器不會送 referrer。以目前大部份網站都沒用 SSL 的情況來說，這會讓分析時高估直接流量（自以為有很多人加入書籤？XD）、且可能低估某些來源的威力。剛巧又有人貼了 Search Engine Land 的文章，說 iOS 6 因為預設搜尋引擎與 Firefox 相同，都轉往 SSL Search，所以就不送 referrer 了。如此推算，被低估的部份就變成自然搜尋，但這是網站健康程度的指標之一，雖然重要性就看個人，但若有需求該怎麼解決？

那就測試一下吧！Dropbox 的空間可以用 SSL 存取，所以我做了個簡單的網頁來顯示 referrer，想等 Google 去索引此網頁後再來測試搜尋。但，後來想到更快的方法：Facebook 也是 HTTPS 吧？那就從 Facebook 去連這個檔案就好。

• 原始網址 https://dl.dropbox.com/u/3280872/referrer.htm
• Facebook proxy link (from HTTPS) https://www.facebook.com/l.php?u=https%3A%2F%2Fdl.dropbox.com%2Fu%2F3280872%2Freferrer.htm&h=YAQH98kqz

好，所以事實證明，若 HTTPS 網站轉進另一個 HTTPS 網站時，還是會送 referrer。所以，如果想避開這種狀況帶來的影響，讓自己的網站也採用 HTTPS 就好了。花錢能解決的事情都是簡單，接下來的問題只在值不值得花。

不過現在大部份網站並不採用 HTTPS，那按理說會造成一部份的自然搜尋來源蒸發現象。但以我可以看到分析資料的網站而言，在 Firefox 預設改用 SSL Search 後，這種事情卻沒有發生，難道這代表 Firefox 的使用量已經低到無法撼動任何東西了嗎？ XD

這倒也不是。其實 Facebook 等網站或許因為廣告等需求，就算你用 HTTPS 連，他的 proxy link 仍採用 HTTP 未加密連線。也就是說

1. 你使用 HTTPS 來連 Facebook，並點擊一個看到的對外連結
2. 這個對外連結會先跳到 HTTP 連線的 proxy link：以我的測試網站來說，就是 http://www.facebook.com/l.php?u=https%3A%2F%2Fdl.dropbox.com%2Fu%2F3280872%2Freferrer.htm&h=YAQH98kqz
3. 這樣正式連過去另一個站的時候，對方無論是否採 HTTPS 連線，仍可收到來自 facebook.com 的 referrer

實際上 Google 也是如此，即使你採用 SSL Search，按照 Search Engine Land 的方法到 whatismyreferer 測試，對方也能正確顯示你從 Google 來。因為 Google 也用 proxy link 當跳板，然後這張跳板也刻意僅用 HTTP 連線。這是 Firefox 採用 SSL Search後，在數據上沒有造成任何影響的原因。

最後一個問題 - 那為什麼 iOS6 採用 SSL Search 後，搜尋上會造成這種影響？從剛剛的各種線索推算，答案就簡單了：因為 Google 行動版的行為不同。Google 行動版雖然也用 proxy link 來計算點擊數，但這個 proxy link 卻採用 HTTPS 連線，所以瀏覽器發現連線對象是 HTTP 網站時，也就很快樂地把  referrer 擋下來了。你可以用 Firefox for Android 搜尋 whatismyreferer 後，長按搜尋結果連結來證實此點。

喔，這樣才是置入性行銷啊 :)

Firebug 頁籤文字太小的繞路解法

只有在 Windows XP 加上新細明體會出事，整個頁籤文字會小到難以辨識，差不多像這樣：（圖片來自 issue 4489 comment 38)

翻了一下 Firebug 的 issue list，似乎目前卡在 issue 4696；Dark 也寫了篇筆記教人怎麼改 Firebug 的安裝檔以便暫時繞過這個問題。不過改安裝檔雖然能解，每次 Firebug 升級時又要再修一次也是麻煩。這邊提供一個 userChrome.css，下載後放進個人設定檔資料夾裡的「chrome」中就可以了。雖然治標不治本，聊勝於無。詳細步驟如下：

1. 下載 userChrome.css 備用
   
2. 打開 Firefox 你所使用中的個人設定檔資料夾。不知道在哪裡的話，請從選單的「說明 > 疑難排解資訊」頁面裡按下「開啟所在資料夾」鈕。
   
3. 開啟個人設定檔資料夾後，進入其中的 chrome 資料夾。如果這個資料夾不存在，就自己建立一個。
   
4. 將剛剛下載的 userChrome.css 丟進去 chrome 資料夾裡。如果資料夾裡已經有同名的檔案，則開啟原先存在的 userChrome.css，把這行 CSS 碼貼在最後面以後存檔：

   .innerToolbar, .panelTab-text {font-size-adjust: 0 !important;}




5. 重新啟動 Firefox
   

因為治標不治本，所以不能視為已經解決了這個問題，只是至少升級時也不必再修改了就是。待以後 Firebug 有所更動，或許可以把這個檔（或你剛剛自己加上去的 CSS 碼）砍掉。至於這個 userChrome.css 是幹嘛的？可以看一下 Mozilla 的舊版自訂文章，這可是從 Mozilla Suite 時代就存留下來的自訂法。

A fox in your pocket - 測試 Firefox 行動版瀏覽器

你的電腦裡安裝了 Firefox Beta、Aurora 或甚至 Nightly 版嗎？或許你也會想幫忙測試 Firefox 行動版。如果你的手機符合系統需求，就可以從 Android Market 上下載 Firefox Beta 來用，提前體驗新版 Firefox 的行動魅力。

Aurora 與 Nightly

有行動版的 Beta，那有沒有 Aurora 與 Nightly？這位客官您問得好，當然有！要安裝也並不是件難事。首先，別忘記在「設定 > 應用程式」下勾選「未知的來源」，以便安裝來自 Market 以以外的程式。

接著，你想測試 Aurora（可以視為 alpha 版）還是 Nightly（每天都會更新，反映最新的程式修改）？

• 想測試 Aurora 曙光版，可以到 http://www.mozilla.org/en-US/firefox/channel/，或直接掃描這個 QRCode 下載 apk 檔：
  
• 想測試 Nightly 天天想你逐日版，可以到 http://nightly.mozilla.org/mobile.html，或直接掃描這個 QRCode 下載 apk 檔：
  

下載完安裝好就可以用了，同一台手機上可以 四個版本（正式、測試、曙光、逐日）全部都裝也沒問題，設定上都會分開。

如果你完全不知道怎麼安裝... 建議你不要裝，因為這兩個版本主要還是給人測試用的，三不五時還是會有地雷出現 -- 還記得以前的 Nightly 叫做 Minefield 嗎？ :P

秉持著 Mozilla 的優秀傳統「Nightly 太好、Beta 不夠好 (c) 彼得大光」， 我現在就是用 Nightly 當預設的手機瀏覽器，其實除了天天都會更新要花時間下載安裝、以及套件的版本相容外，沒什麼大問題。同時，即時完全不想寫程式，你還是可 以藉由使用測試版來幫助 Mozilla 蒐集效能資料，打造更好的 Firefox 行動版，何樂而不為呢？

中文在哪？

但是這下又有一個問題：現在桌面版的 Nightly 都有中文了，那行動版為什麼四個版本都還是沒有中文可以用？其實當然是有的！不過預設情形下，你確實打破砂鍋也找不到。目前的火狐中文老師陳大光表示，把行動版的 4x 國語言都包進去同一個安裝程式會很可怕，所以 Mozilla 目前只先挑了幾個放，中文很不幸市場太小沒入圍。預定從 Firefox 7 起的新版會在第一啟動時讓使用者下載適用的語系檔，到時就有中文啦！

等等，那不就是後天嗎？ XD 後天 Firefox 7 就要上場了，請大家多指教啊！

不過為了確保中文環境使用上沒有問題，我們仍然需要大家從現在起就協助測試，那麼就自力救濟吧！其實開放如 Mozilla，FTP 上早就都把語言包傳便便了，只要用行動版 Firefox 開啟如下網址，把 xpi 點下去就可以裝語言套件囉！

正式版正體中文套件由此去：http://bit.ly/fxmobilezhtw

測試版正體中文套件放在這：http://bit.ly/fxmobilezhtwbeta

Aurora 曙光版正體中文套件抵嘉：http://bit.ly/fxmobilezhtwaurora

Nightly 逐日版正體中文套件看過來：http://bit.ly/fxmobilezhtwnightly 是說這個版本每天更新、語言套件也要每天重裝有點麻煩就是了 orz

有圖有真相，由於這個語言包是從測試版抓來裝的，所以瀏覽器名稱會叫做 Fennec，大家別棄嫌啊：

回饋

歡迎一起來幫忙測試給意見，也歡迎各位勇敢踩雷、追求以後靈魂可以過彩虹橋的勇士到討論區與大家分享想法，或者加一下 MozTW 的 Facebook 粉絲團～

Firefox 4 的 HTML5 表單

（廣義的）HTML5 除了絢麗的各種 CSS3 及新 JavaScript API 組合技之外，還有一個十分實用、卻比較容易忽略的 HTML5 Forms。Firefox 4 實作了其中不少東西，這篇文章將大致介紹一下這玩意。

本文編譯自 Mozilla Hacks 的文章：Firefox 4: HTML5 Forms。原文亦採 CC:BY-SA 3.0 釋出。要實際試用文中的表單效果，你需要以支援 HTML5 表單的瀏覽器觀看此頁。關於各瀏覽器的支援程度，文末將略提一下目前的概況，可逕自參考。

---

輸入欄位新型態

HTML5 中新增了不少 INPUT 元素 的 type 屬性值，可以表達我們希望使用者輸入哪一類的資料，從而在語意甚至互動呈現方式上獲得更好的結果。

舉例而言，手機上虛擬鍵盤的輸入一向受限於顯示區域、經常得在各種模式（中文、英文、數字）間切換。假若一開始就擺明了要輸入電話號碼、那麼瀏覽器就可以自動呼叫數字鍵盤出來，節省時間也增進體驗；又或者，如果這個欄位就是要輸入 URL，那麼或許也可以跟瀏覽器的瀏覽紀錄互相結合以節省使用者記憶的功夫。

Firefox 4 Beta 7 裡新增了以下幾種 type：

<input type="search">
<input type="tel">
<input type="url">
<input type="email">

其中 url 與 email 會自動驗證使用者是否確實輸入了網址或電子郵件地址格式的資料，等下會再提一下這個部份。

輸「出」欄位

還有一個新的 OUTPUT 元素，用來表達某個區域的內容是因應表單的輸入而改變的。例如，你填了出生年月日後，就在此顯示你幾歲那類的。寫法如下：

<output for="i1 i2">

for 屬性中是以空白字元分隔的、「構成這個輸出結果」的表單元素 ID 清單。使用這個元素主要是可以讓補助工具（如螢幕閱讀軟體）了解該區域的語意並提供對應服務，但 OUTPUT 裡的內容並不會「自動」計算出來，你還是得用 JavaScript 算好後填進去。畢竟，瀏覽器怎麼知道你想如何計算呢？

輸入欄位的備選清單

長久以來，網頁世界裡一直缺乏「ComboBox」這樣的元件：一方面能接受使用者自由輸入、二方面也能提供預選的清單，讓使用者更方便。過去我們可以利用 JavaScript 「做」出類似的效果，而以後則可以使用 DATALIST這個新元素來處理。在DATALIST 中所有的 OPTION元素，都會被視為是這份清單裡的備選答案。在清單定義完畢之後，則可在 INPUT 裡加上 list 來使用。範例如下：

輸入所在城市：

<label>輸入所在城市：<input list="cities"></label>
<datalist id="cities">
  或
  <label>從清單中挑選
    <select>
      <option value="Taipei">台北</option>
      <option value="Tainan">台南</option>
      <option value="Taichung">台中</option>
      <option value="Taidong">台東</option>
      <option value="Taihsi">台西</option>
    </select>
  </label>
</datalist>

以這個方式書寫的話，如果訪客的瀏覽器不支援這個功能，也會直接略過 DATALIST 而將當中的 SELECT 選單顯示出來，所以不必擔心使用者就因此無法使用。你可以另外拿一個不支援這個標籤的瀏覽器來看本頁試試。

輸入元素新屬性

autofocus

不必再仰賴 JavaScript 將輸入焦點移到使用者第一個要輸入的表單欄位了！只要在要搶輸入焦點的 INPUT 元素上加入 autofocus 屬性即可：

<input autofocus>

placeholder

在使用者未輸入文字前，要在欄位裡顯示的東西。可以用來提示使用者該輸入些什麼，例如：

電話：

意見：

<label>電話：<input placeholder="02-22223333#311"></label>
<label>意見：<textarea placeholder="請輸入您對本產品的意見。"></textarea>

解構式表單

現在表單元素的書寫方式將有更多靈活的變化。

form 屬性

INPUT 不再需要放在 FORM 元素中了，現在放在任何地方都行，只要加上 form 屬性指明要歸屬的 FORM id，此部份的資料就會隨該表單一併送出。

舉個實用的例子：你想在網頁頁首放一個簡單的搜尋欄位，又想在頁尾另外提供更進階的搜尋功能選項。那麼，頁首可以這麼寫：

<input type="search" name="search_field" form="search_form">

而頁尾可以這麼寫：

<form id="search_form" action="search.php" method="post">
  <fieldset>
    <legend>進階選項</legend>
    <input type="checkbox">也搜尋私人內容
    <!-- 其他內容 -->
  </fieldset>
</form>

這麼一來，兩個部份就屬於同一個表單，而你可以更自由地隨意擺放。

欄位中的各種表單選項

在 FORM 元素中定義的屬性，都可以視情況、由表單欄位中的設定來推翻。目前表單的送出按鈕（包括 BUTTON 跟 type="submit" 的 FORM）支援的相關屬性有：formenctype、formaction、formmethod 及 formtarget。

有個可能的使用情境是，若表單尾附上「預覽」及「送出」兩個按鈕，則按下去後的表單行為不見得要都相同：

<form action="new_post.php" method="post">
<label>標題：<input type="text"></label>
<label>內文：<textarea></textarea></label>
<input type="submit" formaction="preview.php" formmethod="get" value="預覽">
<input type="submit" value="送出">
</form>

若使用者按下「預覽」鈕，則表單送出的方式會從 POST 改為 GET，且傳送目標也從 new_post.php 改為 preview.php。

表單驗證

我們經常需要驗證表單中的資料，確定使用者輸入了正確資訊。我們可以在表單送出前用 JavaScript 驗證資料，也可以在表單送出後以 PHP 等後端語言驗證。一般來說我們都希望使用者盡早知道自己輸入錯誤的地方，所以前端的 JavaScript 多少是會做的，那麼如果瀏覽器就可以處理這塊，不是很好？

必填資訊 required

在表單元素中加上 required 屬性，就代表要求使用者一定要填寫這個欄位。以 Checkbox （多選方塊）來說就代表這個格子一定要勾，而 Radio button （單選鈕）的情況則代表這群按鈕中要選一個。

直接試試以下範例吧！

<input type="text" required>

<input type="checkbox" required>

<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>

網址 url

自動驗證是否為 URL。

<input type="url" value="mozilla">
<input type="url" value="http://mozilla.org">

電子郵件地址 email

自動驗證是否為電子郵件地址。如果再加上 multiple 屬性的話，就可以驗證以逗號分隔的多個郵件地址。（multiple 屬性也適用於 type="file" 的欄位。）

<input type="email" value="foo">
<input type="email" value="foo@bar.org">

<input type="email" multiple value="foo@bar.org, spongebob">
<input type="email" multiple value="foo@bar.org, spongebob@squarepants.org">

這種驗證方式並不會排除有「+」號的 email 地址，所以 Gmail 那類可以在帳號上另外指定標籤（如 bobchao+spam@gmail.com）的方式也適用。

進階驗證 API

如果你想進一步控制驗證方式，可以使用 setCustomValidity 方法撰寫 JavaScript 來驗證表單。傳入字串就代表未通過驗證的錯誤訊息，以 tooltip 方式顯現（且，該表單元素會被標為未通過驗證）；傳入空字串則表示驗證通過。

請輸入密碼：

請再輸入一次密碼：

<label>請輸入密碼：<input type="password" id="password1" oninput="checkPasswords()"></label>
<label>請再輸入一次密碼：<input type="password" id="password2" oninput="checkPasswords()"></label>
<script>
function checkPasswords() {
  var password1 = document.getElementById('password1');
  var password2 = document.getElementById('password2');
  if (password1.value != password2.value) {
    password2.setCustomValidity('您這兩次輸入的密碼不同，請再次確認！');
  } else {
    password2.setCustomValidity('');
  }
}
</script>

若表單中有任何元素被標為未通過驗證，則送出表單前就會被擋下來、將輸入焦點自動移至第一個未通過驗證的表單元素、顯示錯誤訊息。若你想自訂這樣的行為，可以在 FORM 元素上設定 novalidate 屬性，或於送出表單的按鈕加上 formnovalidate 屬性。

關於驗證表單這點，Mounir 寫了另一篇文章，可參考。我（柏強）可能也會翻譯那篇，資訊很豐富。

新的 CSS 選取符

因應這些新增的表單功能，CSS 部份也有些新的選取符。

:required、:optional

預設情形下，所有的元素都屬於 :optional 的影響範圍。如果你為某元素加上 required 屬性中是以空白字元分隔的，則該元素會改套用 :required 的樣式。以下是自訂樣式的必填資訊輸入欄位：

:-moz-placeholder

這個擬似類別可以調整 placeholder 的樣式。這種設定方法還沒進入 CSS 標準，這麼寫就只有 Gecko 相關瀏覽器看得到了。WebKit 瀏覽器也有一個一樣的東西，以下為兩類瀏覽器都能看到效果的範例：

<style>
#selectors2 :-moz-placeholder {
  font-style: italic;
}
#selectors2 ::-webkit-placeholder {
  font-style: italic;
}
</style>
<form id="selectors2">
  <input placeholder="Style me">
</form>

瀏覽器相容性與標準制定

HTML5 Forms 還算比較新的功能，各瀏覽器的支援程度也大不相同。Opera 在 HTML5 Forms 還叫做 Webforms 2 時就實做了部份規格草案內容，所以雖然支援情形良好，但有些行為反而與後來的規格修訂結果有些出入；WebKit 的瀏覽器也已經支援了部份規格，所以也可以實際試試看。

Firefox 4 已經不會再加上更多表單相關功能，而要完整支援 HTML5 Forms 則還有一段路要走：還有些新的欄位型態（數字、色彩、日期）、屬性（數字變動間距、最大值、最小值）、事件（onforminput、onformchange）等等，尚未實做。在未來的版本中，我們會一步步加上去。

這篇文章只是表單功能的概括介紹。Mozilla Developer Network 上還有更詳細的資訊，歡迎參考。

Breaking: Download Firefox nightly and try WebM!

如果你是個關心網路影音發展的開發者，那麼快去下載今天的 Firefox nightly 吧。

方才在 Google I/O 上，Google 終於確實做了大家期待他做的事情：開放 OGG Theora 的同門師弟「VP8」的編碼專利，成立 WebM 專案。目前有包括 Mozilla、Opera 以及想當然爾會相挺 Google 的一些軟硬體廠商為這項計畫站台，這很可能一舉終結目前 HTML 5 中 VIDEO 標籤的編碼大戰。

YouTube 已經開始提供 WebM 的 HTML5 版，首先以支援 WebM 的瀏覽器（例如剛剛請你快點去下載的 Firefox nightly trunk）開啟 www.youtube.com/html5 點選「Join HTML5 Beta」，搜尋影片的時候在網址後加上「&webm=1」即可。目前我還沒辦法測出來，但相信很快就可以玩玩。接下來等 WebM 的硬解晶片上場，我想這場小戰役就可以宣告終結了。財大氣粗有財大氣粗的玩法，看過富豪刑事的人一定很了解啊！

source: http://genta63034.exblog.jp/2922270/

不過還是真的要說句感謝咕狗大神，總算我們可以確保網路持續開放。

近期投影片

最近走闖江湖的次數不少，投影片也依慣例會丟出來。由於簡報室的網址相對長、難記，所以我通常會說「找我的網誌，我會貼上」，但常忘 orz 今天索性一起來吧！標題是連到簡報室，如果只是要看投影片的話不需要連過去。

雜談著作權、公眾授權

在台北市大的演講，兩小時。基本上延伸「著作權在你身邊」的內容，但加上「實際體驗 CC 創作」的部份。這是易原的建議，其實效果不錯耶，以後可以再試著用不同方式表達看看，大家實際動手會更有感覺。

Sampling and Copyright Issues

Copyright Criminals 的引言，還算 ok。

COSCUP 議程組廣告

既然要徵求 UX in OSS 的講題，那麼就來衝個 UIGathering 吧 :) 其實我這幾次都有參加啦，但倒是真沒想過能有機會拿到這個場子的麥克風。感謝阿修、XXC、David 及 UIGathering 全體成員的協助。

我這週三還要在 HappyPlanner 打一次廣告 XD 內容會有一點點不一樣啦，因為會去的人好像有可能重疊到。不過說實在，如果不會重疊、我就不需要去了。

投影片製作趨勢

又，我發現近期自己製作投影片有三個趨勢：

動畫大量減少

我習慣搭配動畫來表達抽象的東西（相信我，我用得還不錯，不會像這樣。）不過，因為之前升級 OpenOffice 之後動畫好像都會「破碎」地出現，圖片有時也缺角，乾脆順便配合 Slideshare 不支援動畫這件事、就少用了。現在用投影片的切換來處理過去想用動畫展示的東西，例子可以看這次「雜談著作權」的簡報，我把過去討論「衍生著作的授權方式」問答題都改成用切換的就能看了，所以以往用 Slideshare 看不懂那幾張要表達啥的，可以再看一次 :P

這件事間接造成下個現象：

張數爆炸多

我仍愛用 takahashi.xul，不過因為圖片的長寬比設定相對麻煩，而且我又很偏好用圖片建立聽眾的視覺感，所以有時間的話還是會用 Impress 刻投影片。結合高橋流的想法發展自己習慣的演說方式，感覺最近節奏抓得都不錯，已經比較不會發生那種明明給我半小時但只講了十分鐘的事情 (不堪回首的黑歷史，還是有忠實放在簡報室)，所以看到兩百頁請不要太驚訝，真的講得完。

PDF Ready

剛也說了最近升級 OO.o 發生了些麻煩，可能是顯示卡驅動程式的問題吧，懶得處理（反正半年就隨 Ubuntu 升級重灌一次，該灌 10.04 了…）。有鑑於此，為了避免發生投影片無法顯示的慘案，我終於也養成了輸出 PDF 的習慣，現在每場簡報的投影片都是 PDF Ready 了！同時，也是因為單純餵 ODP 給 Slideshare 所出來的字型很醜，所以也改成 Slideshare 一律放 PDF、而原始檔 ODP 就放簡報室。顯示效果確實是好多了。

---

人會影響工具的形成、工具也會影響人的習慣啊。

Why so serious?

有兩件跟 Firefox 相關的事情，我的意見可能跟你相左，所以我描述一下自己的看法：

Firefox 佔有率上不去是退步的象徵？

Firefox 的全球市占率在 25%-30% 之間停了一陣子，有些人覺得這是個問題，表示 Firefox 進步緩慢、將被後起之秀追趕過去。

我曾說過的話：

• 如果拿到 10% 成為關鍵少數，也就算達成任務了。
• 如果是 Firefox 佔有率過半，我覺得反而才是要擔心的。

以現況來說，IE9 是肯定會有非常不錯的進展，但吃掉的可能是 IE6-8 的市場；同樣，Google Chrome、Opera 等市占率提昇，吃的也是 IE6-7 的市場 ── Firefox 只是之前狂咬了好幾口、現在吃的速度減緩而已，他自己的市占率沒差些什麼。

因此，多方共享的天下、是可以預期的。或許 Opera 終將拿到 10%、或許 Google Chrome 哪天也奪得 30% 與 Firefox 平起平坐，但多方共享是必然結果。只有下面兩件事情，才會讓我擔心：

• Mozilla 不再進步了：若然，我八成會比只看佔有率就講話的人先知道，而且自由軟體社群是支持好的軟體、他不行了我們就分支出去，不會有人跟他客氣的。
• 雖然其他瀏覽器佔有率上升，但吃的都是 Firefox 的市場、而非 IE6-8：那表示 Webkit 及 Opera 陣營推廣的策略完全與「維護網路標準」無關了。

因此，佔有率重不重要？其實破一定水準之後，就不太重要了，只有要拿去唬一下的時候才會看。

瀏覽器的速度十分重要？

瀏覽器的速度本身當然重要。因應網路未來發展，瀏覽器繪製頁面、執行程式的速度是越快越好。

但是做為我的角色而言，比較誰快誰慢，根本不重要：所有瀏覽器將越來越快、直至不分軒輊而人類感覺不到差異，到那時你比較兩個瀏覽器間的毫秒差距，是否有用呢？我懷疑。

又，速度是影響使用者選擇軟體的一環，卻一直不是全部。使用者關心的是足夠、而不是最好，要不然 IE6 早就退出市場了。

「好不好用」除了速度之外，還有很多因素啊！

Mozilla 2010 年第一季網路現況統計

昨天（或說不久前）Mozilla 發布了 2010 年第一季的網路現況統計報告，當然內容大部分與 Firefox 有關、即便無關也是以 Firefox 蒐集的，必然有所限制、但仍可參考。內容要點，茲列如下：

佔有率

• 經由很多網站來的綜合評比，Firefox 今年首季的全球瀏覽器市場佔有率約為 30%
• 亞洲區約為 26.6%，而歐洲區毫無意外以 39.2% 拿下第一名 -- 扣掉南極洲（80%）的話 :P
• Fx 佔有率最大幅成長的地區為義大利
• 關於佔有率，我隨後將另寫一篇來說明一下自己的看法

使用人數

• 最多的還是美國
• 俄羅斯過去一季的使用者人數成長了 20%，嘖嘖。「巧合」的是，Mozilla 基金會的主席 Mitchell Backer 訪問俄羅斯時，Firefox 下載量一時大增。

以美國人來說，哪裡的人們最早起工作？

用瀏覽器開啟時間來算，夏威夷人最早起（或者最宅、宅到早上起來第一件事情是開瀏覽器上網），最晚的是紐約。但我個人覺得這個統計方法還蠻有爭議的 :P

哪裡人最愛妝點、自訂自己的瀏覽器？

• 要妝點，最輕鬆愉快的方法是 Firefox 3.6 內建的 Personas。單以此來看，南美洲的人最愛妝點（超過 20% 的 Firefox 3.6 使用者用了 Personas）、非洲（低於 15%）最不愛。
• 又或者用使用 1 個以上的套件來算，這時亞洲人反而是套件的高度使用族群，有接近 2% 的 Firefox 3.6 使用者使用套件，成為第一名 -- 還是一樣，扣掉南極洲（超過 4%）的話 XD
• 超過 4% 是什麼意思？南極上面只有大概 1000 個人，而一月起的套件下載量為 538 次。

使用者通常都開幾個分頁？

• TestPilot 日前對上萬名志願參與者做的調查結果顯示，大致上一次約開啟 2 到 3 個分頁左右。
• 這個調查中的最高紀錄是平均 675.6 個！
• BlueT 應該沒有來得及參加這次的調查，有興趣參加日後調查、不花腦筋就可協助 Mozilla 改善易用性的各位，別忘了去下載 TestPilot！

詳情

這份報告的簡報以及圖表可以在 Mozilla Metrics 下載。

關於電子書，需要整理的雜感

真的只是雜感而已，有鑑於現在的時間詭異，我想我不要花太多時間整理比較好，但需要把想法早點丟出來免得後來太懶。

關於電子書標準進度報告

• 對於最後選擇 ePUB 的決策我都表支持，其實目前的狀況、這也夠了。畢竟，我們什麼也沒有、同樣也沒有必要在這個時間點奢求一個解決各式需求的規格，那麼選一個開放、已被證明堪用的規格即可。
• 規格的中文說明很感心，好感度++
• 中文的簡繁互轉一直都不是「對應表」就可以解決的事情，這有點麻煩。尷尬的是，我想我們很快就會熟悉各種簡體字（實際上很多人，包括我，已經是了），那麼或許簡繁互轉屆時不過是為了參考、以及看起來爽，就不會要求正確的字義對應。這是悲觀了點，要是真有好方法、能處理「我下面給你吃」這句的狀況，也是樁美事啦。
• 「中文字型支援種類不足」，沒有脈絡、不太確定自己對這句的了解是否正確，姑且視為「轉檔時的軟體無法支援足夠多的中文字型」。這其實問題不大吧？不知道發問者使用哪套軟體，但既然 ePUB 骨子裡橫豎是 XHTML、那「字型支援」就會是顯示媒介的事情、而非轉檔或規格的問題。倘若真是轉檔軟體沒有「用 CSS 設定中文字型」的能力，就花錢改善它吧。
• 「免費就能用的」字型選擇一直都不多，花錢買就有，硬體製作商或可考慮把這當成賣點。如果可以有股勢力強烈支持下列兩點任一，都是朋友：


• 要求政府相關的雜七雜八單位一致同意用 Public License 釋出全字庫。SLAT 其實去拜會過兩個相關單位了，相信還有很多單位一定也都試過。 我不會說政府沒誠意啥的（他們應該也沒有抱著不放的意思），但我們需要些力量讓這些相關單位「一起」同意這件事，避免責任歸屬不清導致的皮球亂飛。
• 請需要用的組織起頭、花錢製作一些公用字型，然後用 Public License 釋出。文鼎（似乎也是會員）早先曾釋出部份字體，若有興趣、有些已經不那麼賣的字體或許也可考慮釋出，造福人群。
• 文字是否以直書顯示，會不會是一個應該要留給讀者決定的問題？若是，那麼只要硬體商支援 CSS3 writing-mode 即可，我們可以用標準順利解決規格問題，那麼使用者便更可擁有切換的能力、而無須另行定義「直書」標籤。又，這應該是顯示媒介要考慮的問題，可以當成賣點做，Lovely Reader 好像就是這樣。在我的想法裡這也是「顯示」的問題，應盡可能與內容（在此例是 ePUB 規格）本身拆開，才能彈性利用。
• 電子書號標準，若真有必要獨立成為一個標準，猜想國外應該至少有草案了。畢竟如果目前的規格真不夠用、那麼全球都不夠用，可聯合他國一起立一個、盡量避免規格只在自家玩的情形比較好。
• 註記是否應該跟著 ePUB 一起走？好問題，我沒想過，但有的話真不錯。
• 至於註記的顯示方式，留給顯示媒介吧，除非現在我們就能窮舉各種顯示設備與介面的可能、不然怎麼訂都是給以後的自己找麻煩。將內容與顯示方式拆開討論，還是比較好的方法。
• 我的 ePUB Readers 都不能看有 DRM 的東西 orz
• 「版權保護標準」如果不是 DRM 標準，那想像不到具體是什麼。DRM 是否要有標準？沒想法，但共通標準的話、更容易被集中火力破解就是真的。個人偏頗的意見：DRM 終將要被證明是勞民傷財又吃力不討好的事情，想想怎麼從「限制著作流通來贏取利益」轉往「促使著作流通來贏取利益」不知道會不會比較快，可惜除了廣告之外我也想不到。
• 「電子書傳輸協定」，想像不到具體是什麼。
• 「兩岸電子書互通標準」，除了 ePUB 規格本身就處理完的事情之外，想像不到具體是什麼。


• 格式固定有必要，我愛 ePUB。
• 詮釋資料的定義部份有必要，雖然這好像不只跟電子書有關。
• 簡繁互轉個人覺得爆炸難，要到「術語比對」就代表其實還是各走各的，才要比對吧 XD
• 硬體規格沒想法，不確定讓大家自由發展會不會更好

閱讀體驗

為了進一步了解現況，我其實好像還不錯努力啦。除了真的拿個專用閱讀器來看之外，我試過用下列各種方式盡可能閱讀完一本（夠厚的）電子書，茲列如下：

• 用電腦液晶螢幕看 PDF 文件：這很多人都有過。心得包括眼睛很酸不舒服、希望有翻頁的動作（不是愚蠢的動畫，只是要可以翻頁而不是連續捲軸）但又要遷就螢幕與字體大小的問題、長文真的看不太下去。
• 用電腦螢幕看 TXT 文件：也很多人都有，我是看小說。心得包括眼睛很酸不舒服、用螢幕看長文還是黑底白字較舒適、很容易忘記上次看到哪裡、章節分野不明確。
• 用電腦螢幕、以好讀閱讀軟體看「好讀」文件：大概是最好的體驗。Linux 可以跑真是太棒了、直書可以接受、翻頁方式可以接受、字體大小可以調整真是太棒了。
• 用電腦螢幕、以 Firefox「ePub Reader」看 ePUB 文件：就跟看網頁一樣，體驗也一樣。我想要可以「翻頁」的閱讀工具（再次強調不是動畫效果）。
• 用手機、以好讀閱讀軟體、看好讀文件：手指頭常常會擋到字，既然是手持裝置應該還是有點 margin 比較好，其餘同電腦螢幕。我用手機看完三本小說，總閱讀時間大概是時個多小時，這個方式我算看得下去、也不太遇到眼睛疲倦的問題，推測是因為分段閱讀。
• 用手機瀏覽器看 HTML 長文：捲動而非翻頁、很容易忘記上次看到哪裡。
• 用 OLPC XO 看 PDF（彩色螢幕模式）：看不太下去，程式太慢、反光問題。
• 用 OLPC XO 看 PDF（黑白螢幕模式）：除了沒有光線就看不到外，還蠻好的，不過對比比較低有點吃力。

ePUB 的授權資訊

我 Twitter 上有寫過一些：

• 已知是 ePub 裡有授權的「描述性欄位」，至少在這個部份我們最少可以把描述資料，例如「本書除另有說明外，採用 CC:BY-SA 3.0 TW 授權 (加上網址)」，插入這個欄位中 -- 這當然不是我們最想要的，我們希望的是把機器可讀的後設資料放進去。
• ePub dc:rights 的範例，請見 content.opf 部份 http://ping.fm/Maw4R
• 我最直接的想法是，直接把 ccREL 的 RDF 放進 ePub 裡的 metadata 裡。(這個部份我還沒有研究，但我想八成在別的地方已經有類似的範例了，只是不是 ePub 格式而已)

想了那麼久我承認自己還沒實作，ePUB 書都看好幾本了。

台北市教師研習：Firefox

「Firefox 也有辦法講到六個小時？」還真的可以，而且我講了兩次。

去年也在台北市教師研習中心講一樣的題目：Firefox 更方便的資料蒐集、整理、分享工具。對我來說 Firefox 最無可匹敵的其實還是在這方面，對 Mozilla 的努力也頗具信心。我狂愛像智慧位址列這類細小、但舉足輕重能改變整個瀏覽習慣的變化，也很喜歡各種加強搜尋能力的小技巧。講義與投影片都請到柏強簡報室去看。

這次最神經病的就是把之前用 OpenOffice 做的講義全部 Google 文件化，其實比想像中麻煩，因為要顧列印版面。網頁仍然無法用傳統列印的思維去想事情，它仍是個「流動」的文件，這或許是我不喜歡用 PDF 思維去想電子書這件事情的原因之一，都從傳統的工作流程去想、就容易卡在很多地方，有的組織應該有能力從「砍掉重練」去想事情。

講課過程中，我說了很多次「這個功能現在大部分瀏覽器都有，大家不習慣 Firefox 的話還是可以試試看。」改良使用體驗的東西互抄是大歡迎，這也是「提供選擇」的精神意涵之一；如果大家都能意識「我們該有更好的網路體驗」，那麼所有瀏覽器就會不斷進步，我想那 Mozilla 就達到它作為非營利組織的目的了。

可惜我整個時間還是沒控得很好，內容塞太滿，最後的「協助翻譯」及「Test Pilot」就沒提到了。下次要改進。

Firefox for Maemo, RC2

Mozilla just released Firefox for Maemo 1.0 RC2, and I post this message with that on whiteg's Nokia N800! It works just fine, except not speedy, and you can install extensions on it!

If you got an Nokia N900, don't forget to try it out. Just go to http://firefox.com/m with your N900 and download the lastest build. Be sure to get the localized version, which include the best search plug-ins set for your region.

Porting JetQRCode from Jetpack to Google Chrome

(將 Jetpack 套件移植到 Google Chrome — JetQRCode 篇, 點我直接看中文版)

As you may know, Google Chrome browser announced their extension gallery a few days ago. The Google Technology User Group in Taipei hosted a Chrome Hackathon today, I was there and did something insteresting: porting extension between Google Chrome and Jetpack. MozTW is all for "open" (standards, source…) and not for a single product, at least that's the way I doing things.

So here it is, JetQRCode for Google Chrome 0.4, a demo about porting Mozilla Labs Jetpack scripts to Google Chrome.

I've learned a few about the difference between the two:

1. You have to break everything in Jetpack script, which is in a single file, to several parts, like manifest.json, content_script.js / background.html, options.html, to make things work in Google Chrome.
2. Jetpack is highly related to jQuery. To make life easier, you may want to insert jQuery as content script.
3. HttpRequest to different domain is not allowed in content script, do it in background html, and pass the result to content if needed.
4. You have to create a HTML page for user to set preferences, and storage the values in LocalStorage. (But you can't get the setting values in content script, pass them from background html if needed.) Also, there's only one data type in LocalStorage: string. Be careful if you're trying to use boolean or integer in it.
5. There's no APIs for context menu in Google Chrome yet, you might need to do the same behaviors in different way.

IMO, since Jetpack is still in early stage, extension APIs in Google Chrome is more complete (though more complex) in many way than Jetpack. Porting things between the two framework is not as easy as I thought before, and need creativity to conquer the difference.

If you are a not-so-good web developer like me, I think Jetpack is easiar to create extensions to solve problems in daily life. But anyway, creating an extension in either Google Chrome or Jetpack is much simpler then in Firefox (without Jetpack), which results more productivity.

(To correct my poor English, drop me a line with patches, thank you. :)

---

因為我懶得把一樣的話重寫一次了，所以這篇的中英文版大概只有重點一樣、內文會差很多 XD

我原先以為讓 Jetpack 與 Google Chrome 互通套件不算很難，但今天參加 Taipei GTUG 的 Google Chrome Hackathon 時實作一下稍稍有點改觀 —— 的確不難，但是有些東西是比想像中麻煩些。所幸最後仍有斬獲，所以各位親愛的 Google Chrome 使用者、這裡是 JetQRCode for Google Chrome！

拜雙方都遵循網頁標準所賜，其實原理跟很大一部份的程式碼依然相同 (是說我大多都用 jQuery 就是了… 懶惰鬼！)。有些經驗我想還是蠻值得跟大家分享一下，但中文版我想首先講結論：結論是…

1. Jetpack 真的比較好寫 (XD)，對於像我這種沒有很精的人來說可以輕鬆愉快地達到效果，相對來說 Google Chrome extension 就要考慮比較多架構上的問題 —— 或許是因為得拆成數個檔案吧？有些事情要在哪裡做，得先就權限等問題考量一下。
2. 無論你喜歡哪個，兩個都比原來 Firefox 的套件實作方式輕鬆許多，當然也大勝 Internet Explorer。 (Opera 跟 Safari 沒研究)

好，那麼柏強在這次的遊戲中學到什麼呢？

1. Google Chrome 的套件，要完成一件事情就算程式碼再簡單也會需要兩個以上的檔案，例如 manifest.json、content_script.js / background.html、options.html 啥的，所以單一檔案的 Jetpack 要移植過去就要好好想一下該怎麼拆程式。
2. Jetpack 內建 jQuery，很多事情也跟 jQuery 息息相關，所以移植到 Chrome 時、方便起見先把 jQuery 塞進 content script 比較好。
3. 在 Google Chrome 的 content script 裡不能做跨網域 HttpRequest，不過background html 沒問題，所以如果需要的話就在背景做、然後把資訊傳到內容去。
4. 兩者設計哲學中大不同的地方之一是偏好設定，在 Google Chrome 裡你必須自己寫整個 Option 頁面，也要自己把設定值存進 LocalStorage —— 相對自由當然也相對麻煩 (而且從 content page 裡目前還沒辦法直接拿設定值喔！記得從 background html 裡傳。) 這邊我撞到的其中一堵牆是對 LocalStorage 不熟，不知道它什麼都是用字串存，如果要用布林值還是數字的麻煩注意一下。
5. 目前 Google Chrome 裡還沒有調整快捷選單的 API，所以有些效果可能要重新想想使用者可以運用的方法。

以上心得供大家參考，也希望網頁設計師們都可以來玩玩看這兩種比較簡單的套件寫作方式，發揮創意製作出一些好玩的套件。日後有機會再來試試把 Google Chrome 的套件移植回 Jetpack…

JetQRCode: create QRCode with content on web page

Another Jetpack extension :)

JetQRCode is a Jetpack extension which can generate QRCode. With JetQRCode, you can easily get QRCode of…

• (shortened) URL of current tab
• selected text

And you can choose…

• the output encoding of the QRCode
• the image size, from 150px to 500px

Install JetQRCode from Jetpack Gallery. If you don't have Jetpack in your Firefox, Jetpack Gallery will install it first.

For more information on JetQRCode, please check the project page on http://www.bobchao.net/jetqrcode

---

又見 Jetpack 套件… 我真的愛上它了！JetQRCode 是可以拿來製作 QRCode 的 Jetpack 套件… 不知道 QRCode 是啥？蘋果動新聞全靠它啦！有了 JetQRCode，你可以：

• 製作目前網頁網址的 QRCode
• 製作選取文字的 QRCode

接著拿出支援 QRCode 解碼的手機一掃，資訊就跑到手機上囉~

你可以到 Jetpack Gallery 安裝 JetQRCode，關於這個套件的使用方法、未來規劃等等的事項則請參閱 http://www.bobchao.net/jetqrcode。

明年 Jetpack API 完整一點再來辦開發熱鬥會 :) 現在如果你有興趣討論的話，可以參加每週一晚間在生態綠咖啡的 MozTW Lab 台北場，我、小 B、Bryan 都有玩 Jetpack。

MozCC 在 Jetpack 裡重生：JetCC

在弄 ccZotero 時，網頁裡後設資料皆經由 ccMetaView (MozCC 的一部份) 擷取而來。ccMetaView 的目標是要能夠抓到各式相關的後設資料格式 (而不論是否與 CC 相關)，這是好事，不過如果就真的只想抓 CC 的後設資料、是否有跟 MozCC 1.0 一樣的簡單套件呢？又，Firefox 的 API 隨著版本演進而變，而就 CC 總部投注在 MozCC 上的資源，顯然不足以隨著版本變動而更新，是否有更能快速修改的東西呢？

之前提過，我最近花比較多時間玩 Jetpack，所以在想到這些後，就把腦筋動到 Jetpack 上。這種單純的架構果然是實作簡單套件的最佳方式，只花了一點點時間、就把這個 Jetpack feature: JetCC 做出來了。

安裝 JetCC 之後，在狀態列上會顯示目前網頁的授權方式，點選之後則會帶你前往授權條款的說明頁面。其實一切就與 MozCC 1.0 差不多，這也是我覺得比較「輕量」的方式。

拜 HTML 5 Selector API 所賜 (在此以 jQuery 處理)，要找到網頁中有沒有「授權條款」相關資訊，只需要簡單一行：

$(doc).find("a[rel~='license']");

接著再取得該元素中的 href 屬性 (也就是授權條款網址)，即可得知該文件採用什麼授權條款，然後顯示相應圖片即可、輕鬆愉快。

在這個小套件裡有幾件事情值得與大家分享：

1. CC Metadata 格式

從古到今，就我所知有三種在網頁裡嵌入 CC 授權資訊的方法，分別是放在註解裡的 RDF、microformat、以及目前的 ccREL 規格。後兩者都可以用剛剛那樣擷取 rel="license" 的方法來察知，不過對 JavaScript 來說、放在註解裡的東西還真是苦手。實作上還是可以分析網頁後自己寫簡要 RDF parser、不過我懶了…

除了註解中的 RDF 之外，XML 中的 RDF 也是個問題。按理說我不需要管到 XML 的部份、但因為 Firefox 的構成介面：XUL 也是種 XML，所以利用 XUL 做的「網頁」 (例如高橋流 XUL) 也可以由 Firefox 開啟，這麼一來支援一下就是理所當然的事情了。不過同上，目前懶得做，願意幫忙的大德快來吧 XD

2. 產生 referer

點選狀態列的 CC 圖示會帶你到該授權條款的說明網頁。其實 CC 的授權條款說明頁面會自動偵測來源網頁是否有其他 ccREL 的資訊 (例如 morePermission、姓名標示資訊等)，並且顯示出來。因此，如果在這邊單純用 jetpack.tabs.open() 來開啟授權條款說明頁的話，在 HTTP request 內並不會送出 referer，那說明網頁也就無法找到來源網頁上的其他資訊。

只要能送出 referer 就能解決此問題，不過 Jetpack 的 API 目前還沒有提供修改 HTTP Request 內容的方法，所以只能靠其他旁門左道來處理了。在你點選狀態列的 JetCC 圖示時，我們偷偷在目前頁面上插入一個按鈕，設定按下後前往授權條款網頁，再用程式模擬按下動作。這樣就暫時繞過了 referer 的問題。

嚴格說來，這個套件的作用相當有限，但有鑑於 Jetpack 這種方式是未來瀏覽器擴充套件架構必走的道路，當成試作品亦有他的價值。程式碼本身相當簡單，我直接宣告進入 Public Domain 了，歡迎大家隨意使用，如果有興趣改成 Google Chrome 可以安裝的擴充套件也不錯 (應該也相當簡單)。

JetWave 0.2 with waves list in your sidebar.

I just add a feature to JetWave which can show your inbox in Jetpack sidebar. Check the screenshot below:

Also, you can install JetWave from the new Jetpack Gallery, which is still in the alpha stage but usable. Remember to check the "Let me install this unreviewed Jetpack" near the install button.

---

我為 JetWave 新增了在側邊欄內讀取 Wave 清單的功能 (見上圖)，另外也把 JetWave 丟到 Mozilla 實驗中的 Jetpack Gallery 裡了。如果您要從那邊安裝的話，記得先勾選「Install Jetpack」上方的「Let me install this unreviewed Jetpack」。

JetWave, JetPack feature for Google Wave

JetWave is a JetPack "feature" for Firefox. Just like Gmail-notifier extensions, JetWave can help you to check your inbox in Google Wave.

For install and usage information, please check the JetWave page.

我最近花蠻多時間玩 JetPack 的。雖然上官覺得 JavaScript 其實不簡單，不過我自己來講、「簡單」代表的是肉腳如我也可以隨便寫出點東西來，我們這種人是不會要求自己太多、或者要把什麼東西寫得太好太複雜的 ;) JetPack (及 Google Chrome 的擴充套件架構) 就蠻適合我們這些平常只碰網頁設計、會點 JavaScript 的人。

JetWave 是簡單的 Google Wave 檢查套件，安裝後會在狀態列上顯示收件匣內的新訊息數目，點擊後則可前往 Google Wave 查看新訊息。除此之外，我也蠻建議會點 JavaScript 的人看一下程式碼 —— 我並不專精於程式設計，但相信看了後可以大概了解用 JetPack 快速寫個符合需求套件 (或說「feature」) 的方法。

安裝或其他資訊，請往此處去。

我接下來想做中職戰況快速檢視的東西，不過今天晚上我要去ㄆㄘㄉ了 :P 所以就跟預定的 JetCPBL 套件說聲明年三月見囉~