Big5 與 WHATWG Encoding Standard

到了 2017 年還是要講 Big5 編碼……這篇算是 But 的 Big5-UAO 從頭說起的續篇。

WHATWG Encoding Standard 是一個用 WHATWG 名義發表,試圖最後一次解決規範瀏覽器對 Web 的不同編碼的行為的規格書,還有提供標準的 DOM API。大約幾年前開始,規格書的編輯就和 MozTW 社群這邊討論,想要知道要如何產生一個統一的 Web 使用的 Big5 字碼表。

XKCD: 標準規範

討論滿攏長的,總之最後的結論是因為在 Web 上沒有看到顯著的使用 Big5-UAO 編碼的網站,所以 Web 應該使用基於 Big5-HKSCS 的字碼表。那個字碼表後來也就和 Encoding Standard 一起被發表出來且實作在 Firefox 43 中。

當初其實和 but 一樣有點錯愕(或是哀傷)的,不過想想台灣(或是台灣的原 Big5-UAO 使用者)比起香港能夠先拋棄 Big5,到一種 Web 上量不到有使用狀況的情況,其實是一種成就啊。Big5-UAO 在 PTT 等環境的使用對使用者來說也是近乎透明的(由 BBS Client 直接支援),也算對這個字碼表的地位的重要承認。

會突然想起這事,後來也發現是因為跟 HKSCS 有關:#whatwg 上面在問 Encoding Standard 表的重複對應問題,研究之後發現是因為 Big5-HKSCS 沒有處理,把變成重複編碼只對應到單一的 Unicode 字碼導致的。原本 Big5 的重複文字有兩個,會對應到 CJK Compatibility Ideographs 去。

我昨天也就順手更新了 MozTW 網站上那份 Mozilla 系列與 Big5 中文字碼文件(不知為何後來就變成我維護了)。希望這次是最後一次更新了。相關的討論都有在那份文件上連結,可供參考。

Emoji for all Firefox users!

Back in June I worked on a desktop Firefox feature that would bundle the Emoji One font on Linux and Windows Firefox installs. By bundling the font (which converted to the right format for Gecko), Firefox users on Windows XP/7/8 and Linux can see color Emoji instead of blank tofu or black-and-white system default glyphs.

Today, this feature reaches release, on Firefox 50.

Wikipedia on Emoji, Firefox 49 on Windows 7

Before: Wikipedia on Emoji, Firefox 49 on Windows 7

Wikipedia on Emoji, Firefox 50 on Windows 7

After: Wikipedia on Emoji, Firefox 50 on Windows 7

Special thanks to Jonathan Kew on helping me address the issues found in the Gecko graphics code and font format conversion. Enjoy and try it on your browser 😁😁😁!

前端開發領域的終結(與重生)

數年前 awoo 給了一篇重要的演講,試圖定義網路前端開發這個領域的獨立的職能,還有其作為基石,不可或缺的角色。從那邊出發,想要寫一下這幾年的觀察與心得。

先大膽的下標:網路前端開發(Web front-end development)即將終結。

就如當年的演講所定義的一樣,網路前端開發一都是跨領域的拉扯與協調。專業的能力必須同時展現在使用者體驗(UX)、專案管理(Project Management)、產品管理(Product Management),以及為了產品選擇最適合的技術的軟體工程(Software Engineering)能力,還有為了產品開發特殊技術的電腦科學(Computer Science)能力。有些團隊的前端開發還會兼視覺設計(Visual Design)。講到這裡,大家有沒有發現其實這邊已經把一個 client application 團隊的所有職能列完了(笑)?前端最大的危機,或是最大的潛能,就是可以成為以下所列的任一職務之一,或是被這些職能吸收:

  • 視覺設計師(Visual Designer)
  • 使用者體驗設計師(User Experience Designer)
  • 產品經理(Product Manager)
  • 專案經理(Project Manager)
  • 軟體工程師(Software Engineer)
  • 電腦科學家(Computer Scientist)

為何要說網路前端開發即將終結呢?首先的問題是專案的大型化與專業化;大部分的網站已經不是單純的資訊載體了,而是堅實的線上服務。一個優秀的線上服務需要專業的分工去設計與實作最好的呈現以及產品規劃,一人或許能兼任多個職能,但是必須要在這多個職能上都足夠優秀。另外一個觀察是市場現實:Web 或是 Mobile Web 還是很重要,但是它一個產品/服務中只會是其中一種呈現,而不會是唯一的呈現。這樣的產品會仰賴堅實的軟體工程規劃去細緻的拆分前後端的功能與實作,而瀏覽器所顯示的「網頁」會越來越像另一個跟 iOS/Android app 並立的 client-side software。這就呼應到最後一點了:在 Web is the Platform 的遠景之下,瀏覽器再也不只是呈現你最獨特又漂亮的版面的佈局引擎,而是和 Windows/OS X/iOS/Android 一樣的應用程式平台與虛擬機。瀏覽器的廠商們也在朝向這個未來努力,累積這個平台提供給應用程式的功能。

我預期前端開發在工程面向的職能會越來越像一般應用程式開發的軟體工程,只是用不同的技術組合,例如寫 iOS 要懂 Swift 跟 AutoLayout,但寫 Web 要知道 JavaScript 跟 CSS。像是這樣的對應會越來越明顯,對軟體工程專業的要求也會越來越高。Web 作為一個獨特的平台,並不代表他的技術組合必須永遠是獨特的。即便是不同的語言(JavaScript),軟體工程模式還是可以交換且通用的經驗。重新發明其他平台累積過的輪子,或是一年換一個 ecosystem 最熱門的工具,並不是真正的經驗累積。更何況技術組合也確實在聚合中:WebAssembly 會開始讓 Web 成為支援多個語言的開發平台,也會有更多的技術被移植到 Web 上,藉由 <canvas> 繞過 DOM,而且實用化(還記得 Flipboard 怎麼在 Web 實作 60fps 效能的版面嗎?)。

我希望這樣的終結是這個領域的轉機。「前端開發(Web front-end development)」的工程面專業化成為「軟體工程(Software Engineering)」的過程是漸進的,只要有正確的心態,一定能和整個領域一起轉換。若有足夠的基礎知識,還可以進一步精進電腦科學的技術。即便不把自己的角色定位為軟體工程師,若有正確的機會,前述的其他職能也不會難以觸及。這是一個在職涯過程中一定會面對的選擇。

畢竟如果不羽化的話,就無法飛行了。


註:之前 UX Mag 也有文章立論「網頁設計(Web Design)」即將終結,而他們的職能會被視覺設計以及使用者體驗設計給吸收。這個狀況對前端開發來說也是相似的。