FeoLab

今天登到後台發現…以前PO的一篇CMD命令集有被引用，但是網站並沒有延續之前的資料XD
所以我就花了一些時間把命令表整理一下，有一些功能在WinXP被移除掉，有一些則是舊到查不到。還請各會看官多多包含:P

Read the rest of this entry »

設計一個很棒的表單不容易，我們必須設想很多可能發生的情況，還有使用者在使用上的便利性。
最近網路上出現許多在表單上添加樣式設計的程式，使用他們你可以縮短你的開發時程。

Read the rest of this entry »

現在炒的正熱的火狐3.1測試版，號稱使用了一個叫做 TraceMonkey 的技術，可以在執行網頁上 JavaScript 的效能增加三倍，並且在速度上可以大幅超越 Google 的 Chrome。但是，該測試版的 TraceMonkey 在預設上是不啟動的，如果你是個勇於嘗試的冒險者，可以按照以下步驟作設定，享受神速快感。

1. 開啟 Firefox.
2. 在網址列輸入 about:config.
3. 確認警告選項.
4. 位於 javascript.options.jit.chrome 的選項，連按兩下滑鼠左鍵將值換為 true.
5. 位於 javascript.options.jit.content 的選項，連按兩下滑鼠左鍵將值換為 true.

enjoy!

我發現 jQuery 之中有許多的捲動外掛都是以 scrollTo 這個外掛的程式碼為主來做其他的滑動特效。
這個外掛加強了原本 Javascript 中的 scrollTo 特效，在針對觸發事件後畫面上的移動看起來更順暢！

原本JS的程式：

<script>
function go250(){window.scrollTo(250,250);}
function go500(){window.scroll(500,500);}
</script>
<input type="button" value="Scroll to (200,200)" onClick="go250();">
<nput type="button" value="Scroll(400,400)" onClick="go500();">
<div style="background:#555;height:2000;width:2000;">

scrollTo 外掛：

$('div.pane').scrollTo(...);//在 class 叫 pane 的 div 物件中移動
If you need to scroll the window (screen), then use:
$.scrollTo( '#options-examples', 800, {easing:'elasout'} );//針對當前這頁畫面上的移動


來看看官方的範例會比較清楚= =

官方Demo：http://demos.flesler.com/jquery/scrollTo/

今天在寫程式的時候發現 CloneNode 與本尊的 ID 會衝突到，於是想把本尊給砍了…沒想到 DOM 裡面沒有移除所有子節點的語法，只有 remove, removeAttribute, removeAttributeNode, removeBehavior, removeChild, removeExpression, removeNode, removeRule …這幾種，並沒有 removeAllChild 這種的，後來看了一下，其他人似乎也是以迴圈方式做處理，感覺滿沒效率的。寫法大致上如下：

var KillMyChild= document.getElementById("KillMyChild");


if ( KillMyChild.hasChildNodes() ){
    while ( KillMyChild.childNodes.length >0 ){
        cell.removeChild( KillMyChild.firstChild );
    }
}


KillMyChild.removeNode(true); //如果是在IE環境下執行，又想殺掉根節點時就用這行


在這個時候用 jQuery 會比較快，有空再來做介紹XD

剛剛閒逛時找到一個 jQuery 的 PHP 化的函式庫，也就是JSON啦~有了他，在 PHP 端寫 jQuery 就方便許多，希望這函式庫不會胎死腹中，開發者加油！

簡介：
jQuery-PHP is a PHP library that allows to tie jQerry with PHP most natural way. You don’t need to think in terms of transmission, parsing and other boring staff. Now you have a bridge that brings DOM right onto your server and you can ealisy manipulate it in jQuerry-style way.

官方：http://jquery.hohli.com

今天我突然突發奇想想把標籤上的事件像 C# 那樣集中到後台 .cs 檔，稍微查了一下寫法…

原始寫法：
<element onclick="Javascript: here;">
<element onclick="blah: blah;">

可以改寫成以下這樣(放在 window.onload 內)：
obj.onclick = myFunc;
obj.onclick = function() { myFunc(Vars); }
obj.onclick = function() { this.is= 'blah'; }


可以大幅減少前台頁面的複雜度^_^

1337 is the language of hackers and newbies across the internet. Also, the words in 1337 are usually short(ie 『are』 becomes 『r』) and intentionally spelt wrong(ie 『the』 becomes 『teh』, this is most common with e switching places and o’s becoming p’s)
Read the rest of this entry »

上帝把兩群羊放在草原上，一群在南，一群在北。
上帝還給羊群找了兩種天敵，一種是獅子，一種是狼。

上帝對羊群說：「如果你們要狼，就給一隻，任它隨意咬你們。如果你們要獅子，就給兩頭，你們可以在兩頭獅子中任選一頭，還可以隨時更換。」

這道題的問題就是：如果你也在羊群中，你是選狼還是選獅子？

很容易做出選擇吧？
好吧，記住你的選擇，接著往下看。

南邊那群羊想，獅子比狼兇猛得多，還是要狼吧。於是，它們就要了一隻狼。
北邊那群羊想，獅子雖然比狼兇猛得多，但我們有選擇權，還是要獅子吧。於是，它們就要了兩頭獅子。

那隻狼進了南邊的羊群後，就開始吃羊。

狼身體小，食量也小，一隻羊夠它吃幾天了。

這樣羊群幾天才被追殺一次。

北邊那群羊挑選了一頭獅子，另一頭則留在上帝那裡。

這頭獅子進入羊群後，也開始吃羊。獅子不但比狼兇猛，而且食量驚人，每天都要吃一隻羊。
這樣羊群就天天都要被追殺，驚恐萬狀。

羊群趕緊請上帝換一頭獅子。不料，上帝保管的那頭獅子一直沒有吃東西，正飢餓難耐，它撲進羊群，比前面那頭獅子咬得更瘋狂。
羊群一天到晚只是逃命，連草都快吃不成了。

南邊的羊群慶幸自己選對了天敵，又嘲笑北邊的羊群沒有眼光。

北邊的羊群非常後悔，向上帝大倒苦水，要求更換天敵，改要一隻狼。

上帝說：「天敵一旦確定，就不能更改，必須世代相隨，你們唯一的權利是在兩頭獅子中選擇。」

北邊的羊群只好把兩頭獅子不斷更換。
可兩頭獅子同樣凶殘，換哪一頭都比南邊的羊群悲慘得多，它們索性不換了，讓一頭獅子吃得膘肥體壯，另一頭獅子則餓得精瘦。
眼看那頭瘦獅子快要餓死了，羊群才請上帝換一頭。

這頭瘦獅子經過長時間的飢餓後，慢慢悟出了一個道理：

自己雖然兇猛異常，一百隻羊都不是對手，可是自己的命運是操縱在羊群手裡的。
羊群隨時可以把自己送回上帝那裡，讓自己飽受飢餓的煎熬，甚至有可能餓死。
想通這個道理後，瘦獅子就對羊群特別客氣，只吃死羊和病羊，凡是健康的羊它都不吃了。羊群喜出望外，有幾隻小羊提議乾脆固定要瘦獅子，不要那頭肥獅子了。

一隻老公羊提醒說：「瘦獅子是怕我們送它回上帝那裡挨餓，才對我們這麼好。
萬一肥獅子餓死了，我們沒有了選擇的餘地，瘦獅子很快就會恢復凶殘的本性。」
羊群覺得老羊說得有理，為了不讓另一頭獅子餓死，它們趕緊把它換回來。

原先膘肥體壯的那頭獅子，已經餓得只剩下皮包骨頭了，並且也懂得了自己的命運是操縱在羊群手裡的道理。
為了能在草原上待久一點，它竟百般討好起羊群來。而那頭被送交給上帝的獅子，則難過得流下了眼淚。
北邊的羊群在經歷了重重磨難後，終於過上了自由自在的生活。

南邊的那群羊的處境卻越來越悲慘了，那隻狼因為沒有競爭對手，羊群又無法更換它，它就胡作非為，每天都要咬死幾十隻羊，這隻狼早已不吃羊肉了，它只喝羊心裡的血。
它還不准羊叫，哪只叫就立刻咬死哪只。

南邊的羊群只能在心中哀歎：「早知道這樣，還不如要兩頭獅子。」

這是一道非常簡單的選擇題，據我多次親自嘗試的經驗，如果拿來問歐美的朋友，大多數人都會選獅子，但是如果拿來問我們自己中國人，大多數人都會選狼。

還好我選了獅子，想說有兩頭有競爭，可能可以有些變化XD

CSS 當中有許多東西不按照某規律來寫的話，會使你很頭痛，雖然你可以通過很多 hack，很多 !important 來控制它，但是你會發現長此以往你會很不甘心，看看許多優秀的網站，他們的CSS讓IE6, IE7, Firefox, 甚至 Chrome, Opera 執行起來完美無缺是不是很羨慕？而他們看似複雜的範本下面使用的 Hack 少得可憐。其實你要知道 IE 和 Firefox 並不不是那麼的不和諧，我們找到一定的方法，是完全可以讓他們和諧共處的。不要你認為發現了 hack 的辦法，你就掌握了一切，我們並不是 hack 的奴隸。

1. div, ul, li 的嵌套順序

   今天只講一個規則。就是的三角關係。我的經驗就是在最外面，裡面是，然後再是，當然裡面又可以嵌套什麼的，但是並不建議你嵌套很多東西。當你符合這樣的規則的時候，那些倒霉的，不聽話的間隙就不會在裡面出現了，當你僅僅是裡面放，而不用的時候，你會發現你的間隙十分難控制，一般情況下，IE6, IE7 會憑空多一些間距。但很多情況你來到下一行，間隙就沒了，但是前面的內容又空了很大一塊，出現這種情況雖然你可以改變IE的Margin，然後調整 Firefox 下面的 Padding ，以便使得兩者顯示起來得效果很相似，但是你得 CSS 將變得臭長無比，你不得不多考慮更多可能出現這種問題補救措施，雖然你知道千篇一律來 hack 它們，但是你會煩得要命。

2. 具體嵌套寫法

   遵循上面得嵌套方式， 然後在 CSS 裡面告訴 ul {Margin:0Px;Padding:0Px;List-Style:None;}，其中List-Style:None是不讓標記的最前方顯示圓點或者數字等目錄類型的標記，因為IE和Firefox顯示出來預設效果有些不一樣。因此這樣不需要做任何手腳，你的IE6、和IE7、Firefox顯示出來的東西(外距，間距，高度，寬度)就幾乎沒什麼區別了，也許細心的你會在某一個時刻發現一、兩個象素的差別，但那已經很完美了，不需要你通過調整大片的CSS來控制它們的顯示了，你願意，你可以僅僅hack一兩個地方，而且通常這種hack可以適應各種地方，不需要你重複在不同的地方調試不同的Hack方式–減輕你的煩惱。你可以 ul.class1, ul.class2, ul.class3 {xxx:xxxx} 的方式方便的整理出你要 hack 的地方，而統一 hack。嘗試一下吧，再也不要亂嵌套了，雖然在 Div+CSS 的方式下你幾乎可以想怎麼嵌套就怎麼嵌套，但是按照上面的規律你將輕鬆很多，從而事半功倍！

Hack 和過濾器其實是一種迫不得已的辦法，不要稍微掌握了幾招然後就開始炫耀，到處亂寫，雖然能夠達到你的最初目的。不要到了完工的時候看一看你的 CSS 文件似乎到處是 hack，到處都是 Patch，似乎已經為每個瀏覽器都量身定做了一遍CSS。在使用hack和過濾器的時候其實更應該多理解 CSS 的標準規範，實際上要用到hack的情況是很少的。Hack本身一詞也是不包含正面意義的，而是講這是一種迫不得已的行為，是利用了不正確的瀏覽器行為。

作為一般規則，使用以來與不支持的CSS的過濾器，而不是依賴於某種瀏覽器bug的過濾器，這可能比較安全。

對比相對高級的瀏覽器應用規則和生命，同時可以確定老式的瀏覽器會平穩的退化。當瀏覽器新版本發佈時候，如果它現在支援你作為過濾器使用的 CSS，那麼它應該會如預期那樣工作。因為瀏覽器會越來越符合標準，如果使用比較高級的 CSS 克服老式瀏覽器中的問題，這個問題很有希望在新的版本中得到解決。因此，使用不支持的 CSS 作為過濾機制是一種相對安全的方法。之所以說「相對」是因為瀏覽器有可能支持新的 CSS ，但是仍然表現出你試圖修復的 bug。

因為使用依賴於解析bug的過濾器是一種有點冒險的方法。這是因為依賴於 bug 而不是特性。與前面的方法相似，如果解析 bug 被修復了，而你試圖修復的bug還沒有得到解決，那麼可能會遇到問題。但是，更嚴重的是，解析bug在瀏覽器的新版本中可能有新的表現形式。例如，假設 Firefox 的一個新版本有某個解析 bug。如果使用這個 bug 作為過濾器向IE提供不同的寬度值，從而解決專用框模型的問題，那麼Firefox有可能突然繼承這個寬度，這可能會破壞許多網站的設計。

在 CSS 中，有許多方法可以實現同樣的效果，所以如果某些東西造成了問題，那麼可以嘗試另一種方法。許多 CSS 錯誤是由過分複雜的程式碼和標記造成的。如果使程式碼保持簡單了，那麼可以避免使用大多數招數 hack。

那麼應該使用怎樣的策略保證一個網站的 CSS 簡單明瞭，而且又能適應眾多瀏覽器呢？如果經過充分的思考，認識到只能應用某種Hack或過濾器，那麼需要以明智且受控制的方式應用它。如果CSS短小而且簡單，並且只需要應用很少幾個 hack，那麼將這些 hack 放在主 CSS 文件中可能是安全的。但是，Hack往往相當複雜，使程式碼更加難懂。如果 CSS 文件很長，或者需要使用的招數比較多，那麼最好將它們放在它們自己的樣式表中。這不但使程式碼容易閱讀，而且如果Hack在新的瀏覽器中造成了什麼問題，那麼可以準確的知道它的位置。與此相似，如果決定取消對某種瀏覽器的支持，那麼只需要刪除適當的 CSS 文件，就可以刪除相關聯的Hack。或者用程式判斷瀏覽器資訊，然後連結相應的 CSS 文件。或者可以用條件註解(見下一篇)。

為了幫助你正確的選擇過濾器或者 hack，推薦這個網站（http://centricle.com/ref/css/filters/ ）。這個網站提供了表格來描述那些過濾器在那些瀏覽器中是有效的，非常詳盡。