angular-easyfb v1.3.1 released!

June 13, 2015

https://goo.gl/jKvPnc

為了 adaptive width 的 plugin (目前只有 fb-page)，調整 directive parsing 的流程
支援 Embedded Video Player

想不到才隔一天馬上又 release 一個小版… 我也是千百個不願意！

話說昨天那位印度人很快的發現了新支援的 Page plugin 有 bug

我也馬上著手修正，想不到這一下去就是 5 小時…

Read on

angular-easyfb v1.3.0 released!

June 11, 2015

https://goo.gl/ky60u0

把預設的 ezfb.init() 中的 version 拉到 v2.0
新增 Page plugin 支援

~~要說今晚為什麼一事無成都是因為在忙這個~~

原本只是想說把人家發的 PR 處理一下，畢竟那個 PR 延宕已久，之前寫 comment 給發來的人請他改一下他遲遲沒有回應，我只好親自下海修正再 merge 了。

想不到就在 merge 的前後冒出了一個神秘印度人表示他疑似試了並不 work，render 出來的 plugin 寬度不太正常。我試了一下還真如他所說，還好我還沒 push tag 上去。

趕緊查了 Facebook 官方的 Page plugin 頁面，發現這個 plugin 搭配了一個玄妙、不同於以往的莫名奇妙功能叫作 Adaptive Width : https://developers.facebook.com/docs/plugins/page-plugin#adaptive-width

The plugin will automatically adapt to the width of its parent element on page load (min. 180px / max. 500px)

這敘述聽起來是滿美好的… 讓我們繼續看下去

The Page plugin works with responsive, fluid and static layouts. You can use media queries or other methods to set the width of the parent element, yet:

Yet 來了…

The plugin will determine its width on page load

It will not react changes to the box model after page load

總而言之就是基本上它 adaptive width 的決定性 render 就只有一次，之後還是要靠自己… 然後它就造成我 angular-easyfb 的 directive rendering 發生了神秘的錯誤 Orz

總之由於實作 Angular directive -> Facebook plugin 的對應上我是使用 FB.XFBML.parse ，而它只針對參數的 child element 做 parse，為了不影響到其它的 element，在 parse 前我原本是會先用一個看不到的 <span> 把 plugin 的元素整個包起來。

這個 adaptive width 破壞了這項平衡… 總之現在碰到 adaptive width 的 plugin 我就一律改用 <div> 來包，也索性不加太多隱藏用的 style，畢竟這個 adaptive width 大概是需要去抓 parent element 的寬度的。

好了，總之經過一番千辛萬苦總算修正完成，連 test 部分也一併改好，終於 release 了！

剛剛上面提到恰好出現的神秘印度人一整個就因為剛好碰到我在解這個 issue，他就在線等 XD

Awesome!!! Its working perfectly.. Really thanks a lot for the quick fix..

真的是超級 quick fix wwwww

angular-highlightjs v0.3.2 released!

November 02, 2014

https://github.com/pc035860/angular-highlightjs/releases/tag/v0.3.2

在純粹使用 hljs 來套色的時候，可以透過新的屬性 escape="{expresson}" 或 no-escape 來取消原本預設的自動 HTML entity escape

這個 repo 擺了這麼久，終於要突破 100 星大關了(放鞭炮)！！！

週末長知識: Facebook's "theater" View

October 18, 2014

Facebook 長久以來有個顯示 post 的模式(多用在照片/FB影片)，稱為 theater。

Theater 說穿了其實就是平常蠻常見到的所謂 modal 的效果，搜尋 “jquery modal” 之類的關鍵字可以找到一大堆，那這樣這篇文章是想要說些什麼呢？

雖然 modal 們乍看都是一樣，互動上還是會因為實作方式的不同而產生不一樣的結果。

基本上可以分成三種。

絕對定位型

依據產生當下的網頁畫面位置做定位
可以捲動主網頁
捲動時，modal 不會跟著瀏覽器可視範圍

Facebook JS SDK 呼叫 FB.ui() 產生出來 iframe 式的 dialog 就是屬於這種。

有捲軸可捲浮動型

永遠保持在畫面內
可以捲動主網頁(捲軸、滾輪)
看得到捲軸

大部分的 modal 是屬於這種，因為它不需要在一些多餘的地方動手腳(誤)。

無捲軸可捲浮動型

永遠保持在畫面內
可以捲動主網頁(滾輪)
看不到捲軸

為了達到不捲動主網頁的效果，通常會對 <html> 或 <body> 元素的 CSS overflow 動手腳；若不另外費工寫 JavaScript 處理捲軸寬度問題，會造成開啟 modal 瞬間的視覺體驗不佳。

Bootstrap 的 modal就是屬於這種，並且它有處理捲軸寬度，在打開 modal 的同時給予 <body> 一個 padding-right 來補上捲軸的寬度，便不會有視覺的落差出現。

Bootstrap 提供的 modal 在本身內容超過畫面高度的時候，會產生自己的 scrollHeight 並顯示屬於 modal 的捲軸，此時是無法對主網頁進行捲動的。

不可捲浮動型

永遠保持在畫面內
不可以捲動主網頁

理論上用普通方法難以實現的類型，僅管可以透過 overflow: hidden 讓捲軸消失，瀏覽器還是會聰明的讓滑鼠滾輪可以作用。

參考 http://stackoverflow.com/a/11336442/2378741 ，大概可以瞭解，完全阻止捲動的方法只有讓它其實不用捲；然而其中提到的將 <body> 的 height 限制住的方法有一個致命的缺點 - 無法保留主網頁的捲動位置。造成的視覺落差甚至超過上面提到的「使用 overflow: hidden 卻不處理捲軸寬度」的 case，也因此實際上並沒有看到什麼網頁使用此類的 modal。