“重構”的東風吹遍大江南北，互聯網臨時間土崩瓦解，“div+CSS”儼然已成為一種“時尚”，難以盡數的網站都不謀而合地開始了本身的“重構”。然而打開這形形色色網站的源代碼，卻時常令人啞然發笑——

　　我們看到有嵌套6、7層的div布局，有不消table的表格，有純div+a構成的頁面，有成百上千的體現層class……如今關于尺度的冊本越來越多，除了少數幾本標榜“高級本領”的冊本以外，很少有人不會在本身著作的前幾章夸大如許一句話——“布局與體現分散”。然而這些冊本的讀者們，又有幾多人認認真真地讀過前幾章呢？照舊更多地直接跳過那些乏味的布局解說，一頭扎到貌似高妙的布局本領與Hack中去？

　　實在div+CSS這個說法從一開始就誤導了太多的人，急功近利的心態則更是造成這種征象的罪魁罪魁。一個風俗了table布局的網頁制作打仗尺度的第一步，不該該是去盲目尋求實現種種布局的CSS本領，而是高興轉變本身的頭腦方法。

　　下面將聯合我的親身領談判一談適應尺度的頭腦方法，此中有不少是我曾經走過的彎路，盼望對方才打仗尺度的XDJM們有些資助：

　　1、“節流代碼”是營銷本領，不是宗旨

　　“利用div布局可以比table布局節流更多的代碼”，我在很多冊本和網站上見到過這句話。這句話本身是沒錯的，可以“節流代碼”簡直是網頁尺度化所帶來的利益之一。然而牢記，它只是“利益之一”，而不是“唯一利益”，更不是宗旨。“節流代碼”更多的時間是我們用來說服那些至死不悟的老板的營銷本領。網頁尺度化的唯一宗旨是“布局與體現分散”，而絕不是為了節流代碼而節流代碼。我曾經過于網站邊欄乃至主體內容的體現情勢雷同而接納了同一的class （至今另有一些書是如許教的），如許簡直比分別定名id更節流代碼，然而如許做的價錢是代碼失去了精良的布局。失去精良布局的結果是：一、源代碼沒有了可讀性；二、網站增加了未知的維護本錢。試想，當某一塊內容由于必要而作出體現情勢的變更，比方鏈接的顏色等等，我們就不得不去修改頁面源文件，增加分外的class，事情量比起只必要調解id分組就大了很多。并且長此以往，布局將會越來越差，形成難以逆轉的惡性循環。

　　另有一種環境，出如今id的定名方面，也是本人曾經犯過的錯誤。當時為了“節流代碼”，而把主菜單定名為“mm”，二級菜單定名為“m2”，三級菜單為“m3”，結果嚴峻低落了網頁的可讀性，使其他同事很難接辦，圖省事卻累了本身。同理，文件及文件夾定名方面也不宜過簡，象《網站重構》里發起把圖片都用“i”目次存放，小我私家以為并不行取，除非你能為這種高度縮寫的目次布局撰寫細致闡明并包管每個相干職員包羅其他制作職員、開辟、乃至懂行的老板……都能明白和實行，不然只會給你本身增加不必要的貧苦。

　　2、ID是偷襲槍，class是雙刃劍

　　想要做好網頁布局，id與class都是必須純熟掌握的，所謂“兩手抓，兩手都要硬”。ID就象偷襲槍一樣，可以資助我們精準地定位要想要加載樣式的元素；而class則是俠客的佩劍，信手拈來越發輕巧靈巧，兩者的聯合可以大概實現布局精良且體現富厚的頁面。然而如今有一種錯誤的看法，便是id完全可以用class來代替，究竟上很多網頁源代碼也簡直云云，打開來通篇class，找不到一個id。造成這種征象的來由有很多種，然而自table期間傳下來的根深蒂固的“class=CSS”的看法才是本因。簡直，class比id用途更廣更機動，但也必須意識到，class對付構建精良的網頁布局遠不如id有用。id的逼迫唯一性使得我們可以很容易通過id檢索到我們必要的恣意模塊，而class則沒有這個上風。固然我們可以為模塊界說唯一的class名，但條件是——只有制作者本人可以動網頁樣式。不然換一個輕微懶一些店員，看到樣式雷同便直接把前面的class拿來套用，其結果便是我們發明網頁里有十幾個模塊都叫做“gonggao”大概“xinwen”，以至于為了區分還不得不加上大量的html解釋，如許的結果顯然并不是我們想要的。再者便是前面提到的，通過通用class所節流下來的代碼，又不得不在每個單獨界說的class中浪費失。

　　ID是偷襲槍，class是雙刃劍，合則兩利，分則兩敗。

　　3、并不是全部的內容都必要div做“容器”

　　主菜單究竟是用<div id="mainnav"><ul>照舊<ul id="mainnav">？這是一個博弈的題目。至今這個題目也沒有人可以大概給出明白的答案，就連我也是云云。誠然，<div id="mainnav">在只包羅了一個<ul>元素的時間，這個div就顯得有些冗余，但偶然間為了共同美工壯麗的計劃，多一層標簽就意味著多一層變革（有些人在a標簽里套span也是云云）。而div不帶任何原始屬性的天賦上風也是別的標簽所無法相比的。這個命題我只是想闡明一件事，便是我們應該意識到，<div id="mainnav"><ul>之外，另有<ul id="mainnav">這種寫法，同樣具有精良的布局和語義，并且省去了一層嵌套。在我們不必要為富麗的美工勞心費神的時間，是不是也可以讓布局越發簡約呢？

這個命題實在還可以引申為——“并不是全部內容都必要塊元素做容器”、“并不是全部鏈接都必要別的元素做容器”，比方很多頁面都有的“更多”。有些人寫做“<div class="more"><a>”，也有人寫做<p><a>大概<strong><a>。在這些“容器”只包羅了一個<a>標簽的時間，它們是否另有存在的必要？直接寫成<a class="more">會粉碎布局嗎？會缺乏語義嗎？會影響布局嗎？換一種思緒，你大概就會有紛歧樣的勞績。

4、事情上也做到“布局與體現分散”

　　關于這一點，網絡上很多妙手都是如許發起的，也便是先打開編輯器，把布局完備地寫出來，再去CSS里寫體現，而只管即便不去動已經寫好的布局。

然而以看書為重要學習方法的人卻很難領會，由于關于尺度的冊本多數是手把手來教的，也便是一定是布局體現聯合，循規蹈矩。固然有些冊本有這方面的發起，但短短的幾句話遠不如念書歷程中的潛移默化。在制作職員可以大概對布局精良掌握的時間，同時寫布局與體現也不會對結果有太大的影響。但以我的履歷，布局體現分散的事情方法，要比同時寫布局與體現服從高很多，同時也不容易遺漏頁面上的元素。

　　固然，所謂的“布局與體現分散”并不是完全不思量體現，想要分身到體現，就要包管——在不粉碎布局的條件下，CSS選擇器可以大概選擇到只管即便多的內容。在哪些地方加class，大概用哪些標簽來區分，是一個見仁見智的地方，信賴每小我私家都有本身的領會。而聯合差別的計劃稿，偶然間也必要做出相應的變革，然而這些變革都應該有一個同樣的條件——不粉碎代碼的布局和可讀性。

　　再便是，肯定要意識到，任何可視化的東西都是妖怪。它們可視化界面下所出現的結果，每每與真實欣賞器相差千里，而我們真正要兼容的是欣賞器，不是編輯器的可視化界面。

5、CSS不是全能的，沒有CSS也不是千萬不克不及的

　　相比于CSS1.0期間，本日CSS可以完成更多的事變，然而需求永久是領先于技能的，CSS無法完成網頁全部的體現層事情，偶然間我們必須聯合JS大概其他語言來實現一些結果。而另一些時間，用JS的方法比只靠CSS簡樸得多，并且代碼布局越發精良——最典范的例子便是下拉菜單。這些時間，我們要說服本身，大概說服老板與客戶，去接納更簡樸更公道的方法。由于DOM同樣是網頁尺度的重要構成，并不是利用了JS我們的網頁就低落了服從或是不再尺度，恰好相反，這是對JS最大的誤解。說到這里不得不提一點，便是本日的期間，比以往更要求每個職業相識更多的相干知識，做計劃的人要懂一點交互和制作，做制作的也必須相識計劃和步伐，尤其是JS如許的前端技能，只有如許，你和同事才可以大概更好地互助，小我私家的生久遠景也會越發灼爍。

　　沒有CSS，指的是當我們的網站由于種種未知的緣故原由導致CSS文件載入失敗，不要因此而忙亂，這是磨練我們代碼質量的最佳機遇。在沒有CSS的時間，要是網頁仍舊連結精良的可讀性，這結果要遠比通過W3C驗證更值得我們自大。