從火星看地球

這標題，起得有點唬人哇。原先打算自成一篇的，但是，大概想了一下，CSS的瀏覽器兼容問題，應該也可以算是前端通用設計中的一部分吧。當然，這個問題的歸屬，當然是見仁見智了。

CSS的兼容問題，一定讓不少人很頭疼吧，特別是初識html、css的小盆友，即使是進階中的中盆友大概也是會很鬱悶的吧。網路上很多關於CSS兼容的篇章，幾乎都是以說教的口吻在說的，權衡了一下，我沒說教的資本，只能是分享一下自己的經驗啦，既然是經驗之談，難免會有錯誤和不被認可的言論，如果你覺得我是在胡扯，那你也可以移步他處了，不是說不歡迎你，而是你沒必要在這裡浪費時間。另外，這裡不會說什麼技巧之類的東西。

另外，我寫東西很拖沓，常常胡言亂語不著重點，所以寫到這裡，依然還沒進入主題，不耐煩的盆友，你們可以移步他處了。嗯，要怎麼進入主題呢，先說一個不相關的問題吧。

遇到瀏覽器兼容問題的盆友，在想怎麼做兼容之前，不妨想想為什麼要做兼容。幹這一行，有一個最基本的知識是必需要知道的，由於歷史原因，在瀏覽器大戰後，逐漸趨於緩和的瀏覽器市場，一直都是暗流涌動。各家瀏覽器廠商除了當時各自加入的新特性外，也不斷的為了使自家的產品符合W3C的標準，而不斷的在向W3C靠攏。由於W3C對標準的描述并非非常的到位，導致各廠商的文字工作者在理解W3C標準時，產生的或多或少的偏差，這就是CSS Hack出現的基本原因——各瀏覽器對W3C標準的理解偏差，導致瀏覽器在渲染同一個模型時，出現不同的渲染方式。

我在之前任職的公司，前端頁面的瀏覽器兼容是有要求的，要最大限度的充分考慮IE6用戶的感受，某些特殊頁面，還需要考慮正在使用IE5.5的老伯伯的問題。因為公司營維部門有統計數字給我們做支撐，所以我們非常容易知道需要照顧哪一些用戶。總的來說，使用IE6的用戶，佔了80%左右，IE7/IE8在12%左右，使用IE5.5的老伯伯，仍然有2%的份額，其他瀏覽器用戶，相對來說，灰常少。但是有個特點，就是opera和firefox的用戶，在我們的年度統計中，是一直處于增長狀態的，也就是說，在未來的2-3年間，他們也許會成長為我們的主要用戶，所以我們要特別關照他們，給他們一些甜頭（所謂的甜頭，其實就是按W3C的標準來寫我們的頁面）。

看了上面兩段，對於為什麼要做CSS兼容，你大概已經心中有數了吧？在現今最常被人使用的瀏覽器中，對W3C標準實現得最好的有opera、firefox、webkit核心瀏覽器（包括google和apple）、IE8也算吧，雖然在渲染的時候常有怪異表現，不過比起IE7，那可是非常好用的。如前所言，CSS兼容的要點，無非就是，讓標準瀏覽器達到你最想要的效果，然後再去考慮非標準瀏覽器。

CSS瀏覽器兼容的難點，其實應該是對IE的兼容（IE8對標準的支持已經比它的前輩強多了，即將發布的IE9，據說會完美實現W3C標準）。之所以這麼說，是因為，只要你有良好的代碼編寫習慣、正確的標籤嵌套、正確的理解盒子模型，那，對標準瀏覽器，幾乎是不存在不兼容的問題的。

貌似網路上的文章，一說到CSS的瀏覽器兼容，都是逮著盒子模型一往死裡說，既然這樣，我也跟風一把好了。因為我懶得貼圖，所以只好用一個加法式子來表述，這個式子是這樣的：margin+border+padding+width(content width)+padding+border+margin。這個式子，我自認為應該可以很好的表述盒子模型了，雖然還差了上、下兩邊的描述。從這個式子裡，你應該可以看出margin、border、padding、width之間的層次，確切的說，應該是包圍層次（和z-index不是同一個概念，只是x和y軸上的方向）。對於這個式子中的content width我需要做一下解釋。在IE6時代，IE6的盒子的width，就是以上面這個式子來計算的，你在CSS中寫明的容器的width:220px，實際上是content的width；而用於佈局的整個容器的width實際上就是這個式子計算出來的總和。但是非IE系的瀏覽器不會這麼計算，它們會把border看成是width的一部分，而不是另外計算。（有人告訴我，其實它們和IE是同一個計算方法）但是，因為我很懶，所以對IE和非IE系的瀏覽器，都是用的這個式子來解決width問題，所以比較討巧的規避了一些因為width引起的亂七八糟的問題，比如，在FF下能一行顯示完的三個DIV為什麼在IE下要用兩行來顯示。

有些盆友，遇到的CSS不兼容問題，常常是因為不正確的標籤嵌套引起的。舉例來說，就是用inline元素嵌套block元素。這種標籤的嵌套方式，其實是不被允許的，但是，因為瀏覽器的大度，它不會否認這種嵌套層次，而是嘗試去渲染，這樣子，問題就出來了。我們先來理解一下，什麼是inline元素，什麼是block元素。簡單的說，inline元素不會自動填充瀏覽器的可視區域寬度，它的寬度是隨著自身包含的文本長度來確定的，inline元素不能嵌套自身和block元素；block元素會自動100%填充瀏覽器的可視區域寬度，它的寬度不會因為自身包含的文本長度而改變，block元素可以嵌套任何inline元素，以及自身或者其他block元素。inline元素還有一個特性，兩個相鄰的inline元素，第二個會跟著第一個的結尾顯示；block元素則是換行顯示第二個block元素，即使這兩個元素的寬度之和不足以填滿瀏覽器的可視區域。

現在，你應該對inline和block元素有個大概的了解了吧。我猜，你一定會問，如果我要block元素也能像inline元素一樣，能夠頭尾相接的顯示；或者，inline元素也能像block元素一樣，寬度不受包含的文本內容的影響，應該怎麼做呢？其實，有一個叫做display:inline-block的屬性值對，不應該被你忽略。但是，目前能完美實現的，只有standard模式下的IE8和非IE系的瀏覽器，話雖如此，IE6想要實現，其實也比較容易：display:inline;zoom:1;同時使用這兩個，也可得到和inline-block相似的效果。合理的利用這個屬性，可以減少一些不必要的css hack。

順便提一點，有些盆友，喜歡在做超文本鏈接時，使用text-indent:-9999em;這個方法，但是IE6有時根本不買賬。如果你使用這個屬性的是一個inline元素，它會把你的整個標籤都-9999em了，即使你把inline元素聲明為block元素也不會有好轉。使用inline-block，改變你的顯示模式，再配合line-height，就可以比較完美的隱藏文字，同時還可以規避一些莫名的問題。

網路上有些文章，喜歡推薦別人使用CSS Reset，我的經驗是，如果你不了解這是什麼東西，裡面寫的定義都有什麼用，那你還是乖乖的用body,ul,ol,img{margin:0;padding:0;border:0 none}這種方式來重置一些你知道的標籤樣式。

關於float所能引起的問題，在IE6下已經不是什麼新鮮事了，網路上有很多相關的介紹，想知道的，自己搜一下吧。總之有一條，用完後記得clear，保你省心又省事。

最後，再說一點題外話，如果你想跟風，判IE6死刑，那你最好想清楚了再做。最好的辦法不是讓用戶根本無法訪問你的站點而去下載你那個框框裡推薦的什麼狗P瀏覽器，而是讓IE6用戶能從一個樸實的界面裡看到他來你的站點想看到的東西，順便在某個稍微醒目又不會打擾到看文章的用戶的地方，放上一句提醒：如果您願意在更華麗麗的界面中暢享閱讀的樂趣，建議更換支持華麗麗界面的瀏覽器，比如：xxx。一直在叫囂用戶體驗的你，如果連這點都做不到，就不要談什麼用戶體驗了。

寫到這裡，你一定看得很失望，這是一篇什麼狗P東西，完全沒有告訴我我想要的東西嘛！如果你有這種感覺的話，那我只好說抱歉，我一向不喜歡直接把答案說出來；如果你在看這篇狗P東西之前，有瀏覽過網路上其他相關的內容，你會明白，我想說的，其實只是我的一些工作習慣而已。

本來想這樣就結束算了，想想還是寫一下結語吧。現在做前端的盆友，都比較急燥，老覺得IE系的瀏覽器（特別是IE6）和他過不去，覺得如果IE系的瀏覽器統統死掉，那頁面寫起來會爽很多。瀏覽器廠商商業運作上的事情，我們不討論，給IE系瀏覽器做兼容，其實不是一件很難的事情，對於做前端的人來說，可以算是舉手之勞。瀏覽器的兼容問題，其實很簡單，我再重複一下：只要你有良好的代碼編寫習慣、正確的標籤嵌套、正確的理解盒子模型、對標籤\css屬性能夠理解得透。這四點，如果都具備了，你要做的CSS兼容工作，就可以大大減少。

標題寫成這樣，其實和“性”沒半點關係，只是看到S&S在摳摳空間寫了篇關於前端通用按鈕的日誌，我給他回了個“寫得這麼不專業…”，嗯，現在我要來看看我有多少本事，比他寫得更專業。

前端中的通用設計，到底是幹嘛的？其中，至重要的一點，就是設計師為了偷懶，其次，才是堂而皇之為了項目。那麼，既然是為了偷懶，那就來看看怎麼樣才能高效率的偷懶吧。

原理當然是要明白的，一個正常的按鈕，從點擊之前到點擊之前，這一過程從視覺上，至少會給人三個比較明顯的變化：什麼變化都沒有—>按鈕上的顏色變了（有可能形狀也會變，反正變色和變形都是變，咋就不管這麼多了）—->形狀變得和最初的形態不一樣了。<—這是完成一個點擊的過程，同時也是一個按鈕從視覺上產生變化的過程，還是先直接看圖吧。

點擊按鈕的視覺變化過程

好吧，這只是按鈕點擊時的視覺變化上的原理，和我要說的偷懶的事情，貌似沒啥關係。不管有沒有關係，我只是想先引出這張圖。

現在仔細看看這張圖裡的三個按鈕有什麼特點吧。嗯，看完後覺得，這三個按鈕的最大特點就是，沒什麼特點…囧rz。撇去那些亂七八糟的不說，這三個按鈕，都是定寬（如果按鈕上的字超級多怎麼辦？）、定高、有邊框、背景都可以做x軸平鋪，其中，能被我們利用來偷懶的兩個要素就是定高和背景可以做X軸平鋪。但是，我在這裡要說明一個問題，往往一個項目中，並不是一套按鈕用到老的，一般情況下，是在一個流程中的按鈕，才會具有高度的通用性和重用性，當然，設計師在設計的時候，如果有充分考慮過策劃檔上的說明，應該也可以做到整 個項目，至少80%（我隨口說的，非確定的數值）的按鈕可以重用。

基於上面重要的兩點，定高和背景可以做X軸平鋪，以及“按鈕上字超級多怎麼辦”這個問題，切圖的時候，應該心中有底，知道怎麼切才能更好的偷懶了吧？定高的通用按鈕，要解決的問題就是字很多的時候，寬度不夠用怎麼辦。前面提到了一點，按鈕的背景可以做X軸平鋪，這可是很關鍵的一點呢，沒有它就沒法實現字超級多寬度也要超級寬的需求了。先來看看，最常規的切法是怎麼切的吧。

切出來的button

這圖上，我是把邊框也一塊切了，這樣子，可以少寫幾行CSS，但是圖片也多了點，變成3*3個了；不帶邊切的話，只需要上圖中中間的那部分，圖片也就是1*3，但是你需要在CSS裡為按鈕的邊框做定義，最後應該怎麼實現，還是得看你自己了。

到這裡，圖片加工就告一段落。現在需要做的事情，就是在CSS裡整理出一個可以往死裡重用的class，關於這個，不需要我多說了吧？

看到這裡，各位看官可明白為啥要做通用按鈕了麼？不明白？真的不明白？好吧，那我把秘密告訴你噢，其實，我只是要把寫各種不同按鈕的時間省出來，然後就可以幹愛幹的事了—_.—

最後做一下總結，通用性的物件，往往都會比一次性的物件實現起來要麻煩得多，因為要考慮的問題不是針對一個問題，而是一類問題，這樣子你就要考慮到物件會在什麼狀況什麼情境下使用；另外，在實現通用物件的時候，盡量使用簡單的html結構，這至少會給你帶來兩個明顯的好處：你只需要維護少量的CSS和html，程式員知道物件應該怎麼用，而不會頻繁的找你問題。

偷懶已經成了習慣，我連代碼都不貼了，哈哈…故事至此結束，晚安，各位

貌似是昨天，群里某S&S问了我个IE6多猪问题（IE6文字溢出），结果，我居然不太记得怎么解决了，看来真的是业精于勤，荒于嬉啊！
不过还好，最后还是记起来了，看了S&S的页面，貌似是注释引起的，遂，帮之
code：
原来注释的写法是这样的

<--我是注释-->

现在，把注释改成这样来写

<!--[if !IE]>我是注释<![endif]-->

使用IE的注释hack来解决，看懂了吧？

ps.这两天貌似更新的频率有点高~哈