爲什麼不使用Compass/Blueprint Grid的語義類名稱？

Question

我最近開始了一個大型的多年客戶項目，前端開發的第一個階段是創建一個模式庫來在整個項目中使用。我爲我的網格使用了Compass和Blueprint。 Mixin的這個項目看起來非常完美：它會自動生成語義類名稱（即.span5），其他小組可以在所有頁面上重用。

然而，Compass documentation states：

最佳實踐反對使用這種混入，但它提供了支持舊版網站和測試針對藍圖的示例頁面的薩斯端口。

這是爲什麼？爲何在現代網格系統中推動使用非語義類？爲各種頁面元素創建一個新的CSS類，它們都會共享相同的網格寬度，這看起來不那麼幹。例如：

.dashboard__chart { 
    @include column(6); 
} 

.dashboard__news { 
    @include column(6); 
} 

的時候我可以簡單地只是有一個.span6類在我的標記申請。

這可能是情境性的：如果整個項目在整個項目中都有類似的佈局（例如新聞網站或博客），則非語義類是有意義的。但是，這個儀表板/報表工具項目在每個頁面中都有不同的佈局。

回到最初的問題：爲什麼最好不要使用語義類，以及避免它們的最佳方法是什麼？

Answer 1

它會自動生成語義類名（即.span5）

我不認爲「span5」是的，因爲它並沒有描述語義的名稱所有內容，但以相當具體的方式描述了佈局。

_{當然，術語「語義」是圍繞着很多，但從最純粹的意義上講，它應該與表示很少或根本沒有關係。}

理由不使用它描述呈現名稱：

1. 如果佈局的變化，名稱錯誤
2. 佈局可以適用於不同設備爲它是錯誤的和/或毫無意義。
3. 標記對閱讀任何人（即你的團隊）的意義不大
4. 佈局會變得脆弱;改變在許多不同地方使用並具有許多不同含義的課程可能會在某些地方使用。

類似「span6」的泛型類最大的缺點是它們被濫用（我已經看到Bootstrap中有類似的網格類定義）。 「我需要這個元素來跨越兩列...太好了！我只需要拍一個'span2'類就可以完成了！「

這並不意味着您不應該尋找重用;但是重用可以來自與內容相關的類名稱（當然，這可能需要一些努力）並且通過使用mixins。

我最近開始在一個大的多年客戶項目，前端開發的 第一階段是創建一個模式庫在整個項目 使用。

大多數項目結束爲了實用性而採取例外/妥協，但你有有機會以最佳實踐方法開始。