作為乙個身處 2008 年末的 web 設計師，你是否好意思承認自己的**中使用了 table，如果是，你是乙個有勇氣的人，web 設計是個奇怪的行業，你可以將自己的**設計得像晚報的分類廣告，或者樓道裡的開鎖廣告，但千萬別讓人知道你使用了 table，在你的源**中發現 table 就像乙個銷售被人掀起褲腳發現穿了白襪子一樣。
table 是如此醜陋，臃腫，哪怕只顯示一段簡單的內容，你也需要 這三個基本的標籤，每個標籤裡面還要加上一堆亂七八糟的屬性，不像，既簡單，又整潔，又時尚，它和 css 珠聯璧合，琴瑟和諧，它們構成最完美的 box 模型，他們象現實中的箱子，你把東西放進去，然後，很自由地對他們進行排列，厭煩了一種布局，沒關係，簡單地改動一下 css 定義，一種全新的布局便誕生了；不象 table，table 像食堂裡的餐具櫃，一排排，一列列，土裡土氣，油膩膩的，象我們的父輩，邋遢，什麼都往家裡拿，胡亂堆在角落裡，如果 div 是小資，table 就是老三屆，他們不屬於這個時代。
div 成為幸運者一方面因為它天生就是 box 的最佳原型，在語義上，div 代表頁面的乙個區域，在外形上，它四四方方，更重要的是，它不像 或 那樣事先已經被賦予特殊的語義（雖然它們也能用於 box 模型）；另一方面，則出於人們對 table 統治乙個臃腫時代的憎惡，乙個時代的結束，繼任者都會努力抹去舊時代的痕跡，那些舊時代的象徵或代表的命運多半如此，人們並不是簡單地忘卻它們，而是斷然劃清界限。
table 的一切不公平待遇就此開始。為什麼說不公平，w3c 不建議 table 布局的時候，只說應使用 css 代替，這是什麼意思，table 不支援 css 嗎？當然支援，而且，由於 table 作為老牌的 html 物件，它的地位曾如此重要，任何瀏覽器都對 table 提供了最完美的支援，包括 css 支援。當人們擁抱 div 的時候，似乎忘記了 table 也是 box，而且是乙個擁有多個內格的 box，table 作為乙個整體，和 div 在 box 模型方面沒有任何區別，而它的內格，除了 margin 之外，仍然是乙個 box，內格不含 margin 概念這是應該理解的。div 很優秀這不必說，然而當人們說 div + css 的時候，似乎暗示著 table 無法 css，這是天大的誤會。
div 支援的所有 css 屬性，table 全部支援，事實上，在 div 大紅大紫之前，那些 div 的早期採用者曾信心不足地表示，table 能做到，div 都能，而他們也為自己的話付出了代價，企圖在 div 中實現垂直居中的人明白我的意思，企圖在 ie6 中不經 css hack 而實現 100% div 布局的人更明白我的意思。100% height 問題，幾個 div 之間的寬度自適應問題，相信任何從事 div + css 設計的人會遇到。table 在這方面的優勢並不是因為它本身多麼優秀，而是因為它老牌，沒有瀏覽器敢忽視，也因為它的特性原本如此，人們發明**，是因為希望資料顯示得整齊，就這麼簡單。然而，為什麼 table 後來背上那麼多的惡名？div 擁護者對 table 的責難不外乎以下幾條。
**臃腫：你至少需要寫下 這三個標籤之後，才能開始真正的內容，另外，table 的各種標籤中還包含了複雜的屬性定義，而 div 只需 乙個標籤。
頁面渲染效能問題：瀏覽器需要將整個**完全讀完後才會開始渲染。
不利於搜尋引擎優化：搜尋引擎喜歡內容與修飾分開。
可訪問性差：螢幕朗讀軟體和盲文瀏覽器無法很好地理解 table 中的內容。
不夠語義（semantic）：我們需要語義的 web。
第1條：**臃腫
首先，table 裡面唯一無法用 css 定義的屬性只有 cellspacing, cellpadding 幾個，其它屬性都可以並且應當使用 css，這樣，剩下的，就是 和 的對決，我相信乙個動輒幾十k大小的網頁，即使使用了幾十個 table，因此多出來的**也可以忽略不計，那些埋怨 table **臃腫的人其實該檢查自己的編碼習慣，能將 table 寫得十分臃腫的人，寫 div 相比也未必會簡潔到**。
第2條：頁面渲染效能問題
我使用一台2023年的膝上型電腦，1.6g 的 cpu 與 1g 記憶體，這種配置下，看不出 table 布局和 div 布局在頁面渲染上有任何速度差別，其實這點差別即使有，相對網路本身的延遲也可以忽略。
第3條：不利於搜尋引擎優化
如果你盡可能使用 css 而不是 table 的屬性，前面說了，產生的**和 div 的差別也不會很大，搜尋引擎會歧視 標籤嗎，這種說法的依據我至今並沒有找到。
第4條：可訪問性差
這是 table 固有的缺陷，不過多數 div + css 的擁躉似乎並不是基於這個原因才排斥 table。
第5條：不夠語義
語義 web 的含義要深遠得多，並不是僅僅在 table 和 div 上糾纏，即使 w3c，也並沒有規定 table 只能用來顯示**資料，很多在 table 的語義上進行糾纏的人，其實不妨再等等 html 5，那才是真正的語義。
本文的目的不是讓你丟棄 div 投身 table，相反，如果 div 能滿足你的設計需要，div 仍是首選，但沒必要避諱 table，否則會走入另外乙個極端。很多使用 div 無法簡單實現的設計，仍可以使用 table，當然，不管使用什麼，都應該用 css 將內容與修飾分離。div + css 和 table + css 都是合法的設計，誰更簡單就用誰。根據我的經驗，當你能預見你的內容的格式，對你即將加入的內容有能力完全控制其顯示格式時，應當使用 div + css；當你即將加入的內容是不固定的，你無法預見其格式，如果不想讓頁面坍塌，使用 table + css 是一種保險的做法。
DIV CSS與Table優劣的淺見
div與table本身並不存在什麼優缺點，所謂web標準只是推薦的是正確的使用標籤，好比說 div用於布局，而table則本來就是轉二維資料的。讓table做該做的事，並不是說頁面裡不出現table就是多麼多麼牛。用div進行排版的優勢就是我不說，大家應該都比較清楚。div是標準，是大勢所趨，但並不...
辯證的看DIV CSS與TABLE
1 內容和形式分離，網頁前台只需要顯示內容就行，形式上的美工交給css來處理。生成的html檔案 精簡，更小開啟更快。2 改版 更簡單容易了，不用重新設計排版網頁，甚至於不用動原 的任何html和程式頁面，只需要改動css檔案就完成了所有改版。對於門戶 來說改版就像換件衣服一樣簡單容易。3 搜尋引擎...
Fragment與Activity的優缺點比較
專案中對activity和fragment使用都很多，它們都能用來寫頁面，那麼什麼時候用activity，什麼時候用fragment？關於 android，用多個 activity，還是單 activity 配合 fragment？中提到 單activity多fragment實現，已知的坑有，act...