FCKEditor 算是我從開始接觸所見即所得（WYSIWYG）編輯器，一直用到現在的一個。雖然其中我有嘗試去用別的編輯器，像是 TinyMCE 就是其一。不過，最後用來用去還是回到了 FCKEditor 來，倒不是因為他特別好用，只是習慣問題而已。
這裡有一份線上編輯器的比較表，有興趣可以去看看：
http://www.geniisoft.com/showcase.nsf/WebEditors
FCKEditor 也不是沒缺點（請看我 上一篇），雖然同樣是採用 IFRAME 做轉換，但是結構上來說並沒有 TinyMCE 來得靈活，所以，在某些 scripts 呼叫上會出點問題。但是，因為曾經把 FCK 的整個 dialog 項目給 hack 掉，換成自己要用的東西（這應該不難），所以對於整個 FCK 的使用比 MCE 要來得熟手，所以到頭來，還是用 FCK 比較習慣（比較容易 hack？）。
經過 上次的那件事情 之後，我真的覺得除了那該死的 IE 之外，框架真的是 DOM 裡面的一個致命傷。FCK 就是因為這樣導致 API 要去控制編輯器內容的時候過於綁手綁腳，畢竟，在那該死的 IE 的加持下，Window 與 Document 這兩項 DOM 對於子節點的呼叫硬是跟別人不太一樣，或者該說，在那該死的 IE 盛行的這個世界上，所有 IE 不能跑的都是有問題（客戶如是說），所以只好硬著頭皮把 DOM 給 hack 掉，好讓程序可以正常運作。
其實這樣有點扭曲了 FCK API 的原意，畢竟 API 是一種溝通的管道與媒介，用 API 來對 API 本身提供的 prototype 來動手腳，好像有點奇怪（不只有點吧！），所以，如果有那種需要高度客製化的部分，老實說，我覺得 MCE 操作起來應該會比 FCK 要方便一點。畢竟，MCE 在這方面所 提供的文件，要比 FCK 要來得多（肯定的）。而且對於某些 DOM 的操作，MCE 確實比 FCK 要方便一些，只是，對於原始碼（HTML/XHTML）的處理上，我個人還是偏愛 FCK 的方式就是（不要問為什麼）。
最近 MCE 推出了 3.x 版本，FCK 好像也在加緊趕工中。其實我個別都有再去嘗試一下新的版本，當然，那個 FCK 新版本的致命 bug（就是我 上一篇 提到的），目前也還沒有解決辦法（除了 hack DOM 之外），而 MCE 目前倒是沒有這方面的困擾，當然，這要看看 FCK 3.x 的造化了，要是這些 bug 還沒辦法去改善的話，那也很有可能棄 FCK 就 MCE 也說不定。
反正說穿了，不就是一大堆 Javascript prototype 在作怪嘛，只要有 source code 要把 DOM 給 hack 出來用也不是難事（吧）。不過，能不做這種事情就盡量不要做比較好，畢竟，這樣只會增加自己的工作量，把原本簡單的工作給複雜化罷了。倒是有一點，真希望 FCK 能多充實一點 wiki 的東西啊，給那幾樣 sample 實在有點太 simple 了啊（死）。
PHP 的創造者說，Simple is Hard，但，看到那種很 simple 的 documents 的時候，你只會想說，Simple is FUCK！
