Firefox 附加元件:JS 注音輸入法

這兩個星期的下班時間,除了玩星海爭霸以外,另外的娛樂就是把之前獨立成 library 的 JS 注音包成 Firefox 附加元件。

Firefox 使用者:安裝 JS 注音輸入法

安裝之後啟動的快速鍵是 Ctrl+Alt+1(Mac 為 Command+Option+1),想要幫忙開發的話原始碼在 Github。很久沒有碰 Firefox add-on 才發現現在的 tool 好進步呀,Add-on SDK(原本叫 Jetpack)把常用的都包成可以任意取用的 CommonJS module,再也不用什麼東西都跑去 XPCOM/XUL 裡面挖。

不過也是因為 SDK 的版本在 Firefox 附加元件網站上架有點問題,這之後再解決。另外就是因為要對輸入框發出 keyboard event,我還是寫了需要 chrome 權限的 module。這部份抄了一些同事在 Virtual Keyboard API 的 code。也發現了一些自己在 JS 注音設計的 IME Engine API 不合理之處,「有空」的話要一併檢討,回去改善 Gaia 的 Keyboard App。

另外可以開發的是可用在 Chrome 的輸入法:Chrome 早就有為了套件設計的 chrome.input.ime API 了。希望在我「有空」之前這個就被別人做完。That’s the power of open source。

(用自己寫的輸入法打字感覺滿奇怪的 ^^:)

 

Opera 改用 WebKit 與 Chromium

如題,本日最大消息,Twitter 與 Blogsphere(如果你還覺得這個「地方」存在的話,笑)都爆炸了,如同當年 Google 宣布 Chrome 時的反應一樣。Twitter 可以看搜尋以及 Mozilla CTO Brendan Eich 的訊息。

在 Mozilla 工作,看到的反應比較多是負面的,像是在擔心 monoculture/diversity,尤其是 Mobile Web 的部份。例如,Mozilla 的 layout 魔術師 roc 在「And Then There Were Three」就說(節譯):

Opera 對 Web 標準的影響會大幅的降低,尤其是當他們和 Apple 與 Google 有不同想法的時候。佈局引擎的多元性又更加降低,尤其是 Mobile Web 的部份 … Mozilla 會更難推廣網路標準,相較於「coding for Webkit」… 網路標準會失去他的重要性,標準制定的過程會被 WebKit 這個開源專案的內部決定與政治取代。WebKit 的程式錯誤會反過來變成標準 … 無法分辨佈局引擎的行為是程式錯誤還是設計。

最近一年倒是多少有跟別人聊到類似的假設:「假如 WebKit 變成 de-facto web standard 會怎樣」這樣的問題,尤其是之前跟 Kenny 大大MozTW Labs 的路口討論。不管是好是壞,我們離那個假設又更近一步了。

台北當然是春節休假。Mountain View 剛開始上班,不知道公司會不會發什麼聲明出來。

CSS Classes State Machine Puzzle

It is quite nature to code CSS classes as “states” in a web applications. Say if you have three <div class="view">s within the <body> tag, you can easily toggle the class of the body to show/hide the views, with one-off CSS animations as view-to-view transitions, right? Wrong.

It turns out, it works with two states even with transition/animation, but not so much if there are three states. For two states like A & B, there is only one possible route to get into each state, A→B for B, and B→A for A. However, if there are three states, A would have routes B→A and C→A, and so on. It’s basically n*(n-1) for n states.

How do you specify two different CSS animations for the two routes? This doesn’t sounds like a common question, but I have personally encountered twice in different projects, and I bet sooner or later this would happen to everyone as we moved from DOM animation to CSS and rely more and more on browser to run the animation smoothly.

One way to look at it would be that this is a design flaw of the CSS language. There should be some pseudo-class like :was() to specify what exact route to match against. However, inventing a pseudo-class just for the animation property doesn’t sound like a great idea.

The other way, and a more practical approach is to look for solution with what we have right now. Inevitably, to distinguish route B→A and route C→A, one should introduce immediate states, making the routes B→A’→A and C→A”→A. Yet, this further complicate things if one would like the scripting part stay as a clean finite-state machine: First, the transition of A’→A will depend on animationend event, which couples the CSS code with Javascript code. Second, and the bummer that makes the solution incomplete, is that the animationend event will never fire if the state changes again during the A’ or A” state, which make it necessary to handling the changing in Javascript code again ourselves. Good luck on codify all the A’→B, A”→C, A’→C, … transitions.

Now you know how hard it is to write a mobile OS window manager with Javascript + CSS. There might be some obvious answers I overlooked, if you would like to give your solutions, feel free to comment here or post it on your own blog.