宣告:你可以不同意我在本文所寫的一些觀點,沒有問題,我不是要代表你、代表你的公司或意識,因此請不要感到不安。繼續保持你的看法即可。向那些理解演講方法和辯證法的、絕大多數人致歉,因為本宣告不適用於他們。
多檔案
很多 web 開發貌似都和將任務分割為可管理的塊或「元件」相關。對於每一個分離的 JavaScript 功能塊、或 HTML 區域性,我可以做一個專門檔案,並把相關檔案組織到資料夾裡,以 javascript、html 或 controller、templates 命名。你怎麼做都行。這樣,你就能輕鬆檢視檔案系統,只關注包含有你當時想要編輯的程式碼檔案即可。
這種方式不適用於 CSS。JavaScript 函式可以放在它們被呼叫位置的前後,HTML 模組可以在任何地方插入,只要你覺得它們適合當前文件流。另一方面,CSS 是按照時間順序發生的。它和你宣告樣式的順序,有著很大關係。由於該語言的繼承和 specificity注1,你應該從一般樣式(比如對 body 設定 font-family)開始,並過度到更多具體的定義。
CSS 是一個有序的、以例外為基礎的語言,沒有簡單的方法來連貫地表示一個檔案列表(通常按照字母順序組織)。它給了你一個印象,每個 CSS 檔案都是自治的,事實上卻不是。
1 2 |
- buttons.css - reset.css |
因此你有兩種選擇:當你試圖把一個方釘子打入圓孔時,你可以對「specificity 不應該成為 CSS 的一部分」持拒絕、抱怨的態度,或者,你用一個有著良好註釋的檔案,它明確地表示了繼承過來層疊的弧度。specificity 不應該成為一個問題,因為大多數特定的選擇器應該是你最後才編寫的。
總結:你不應該把 CSS 檔案分割為獨立檔案,就像不應該把一塊玻璃丟在水泥地板上一樣。
巢狀(藉助 Sass)
我對 Sass 感到比較糾結。它的一些思想真的讓我激動,比如使用迴圈和條件語句提高編寫效率的能力。而另外一些特性就不那麼好了,比如無限巢狀的宣告。
我認為,很多人選擇 Sass,幫助他們管理和維護 CSS,更方便閱讀和編寫。Sass 做為一個依賴和抽象層所帶來的負面影響,就是讓事情更加系統化地複雜,據說還有一些 Sass 提供的介面,比如帶引數的混入(mixin)。將其用在專案中,程式碼的可閱讀性和簡短程度,就成了一種福音。
巢狀嗎?那隻會讓問題更糟。想象一下組織最糟糕的 CSS 檔案。雖然混亂,但至少是一個維度的混亂:如果你願意,那麼只有一個檔案混亂。讓編寫蹩腳 CSS 的人(可以是任何人,很多時候也包含我)使用巢狀,相當於授權他們擴大到第二維度的混亂。太棒了!現在,混亂徹底蔓延開來。
鑑於在其它語言裡,儘可能地避免巢狀結構是一種職業榮譽感的體現,那麼,將這種能力用在不需要巢狀的語言裡,貌似有些可笑。Hugo Giraudel 就 Sass 寫了數百篇指導文章。下面是他就巢狀不得不說的話:
Fucking. Stop. Nesting.
總結:你要追尋的 Sass 特性不應該是巢狀。
畫素單位
回溯到 IE6 的時代,我們被告誡用 em 單位設定字型大小。較新的瀏覽器帶有縮放功能,可以更容易地按比例增加頁面尺寸,但是在 IE6,你只能增加字型大小。由於用畫素設定的文字拒絕被放大,我們會排斥很多低版本使用者。
IE6 不再是一個問題了,但是大多數作業系統和瀏覽器的使用者仍然設定獨立於縮放功能的字型大小。這應該是他們的喜好,我們應該包容。
說歸說,我甚至沒有打算實現這一目的。我只想向你自私的一面發出懇求:在響應式設計裡使用畫素來管理大小,絕對是愚蠢至極的行為。分開元素之間的尺寸,其相對性的缺乏意味著你要不得不為每個獨立的斷點,單獨考慮每種設定。事實上,使用畫素時,你甚至不得不管理字型大小和單獨的、隔開元素的 margin。你本不想這樣做的。
舉個例子:
1 2 3 4 5 6 |
@media (min-width: 400px) { h1 { font-size: 22px; margin-top: 33px; } } |
如果使用相對單位,我該怎麼做呢?我不願意的。事實上,我無需在我的媒體查詢裡針對任何單獨元素設定字型大小和 margin。我只想讓瀏覽器或使用者根據根元素()來決定字型大小,並用 em 或 rem 來設定我的所有其它規格。
1 2 3 4 |
h1, h2 { margin-top: 1.5rem; } h1 { font-size: 2.5em; } h2 { font-size: 2em; } /* all your other element styles */ |
然後,當我想在 min-width 斷點下放大比例時,我只需要根據其它元素的比例,調整根的字型大小。我使用百分比,因為這涉及到使用者喜好,如果設定為:
1 2 3 4 5 |
@media (min-width: 400px) { html { font-size: 120%; } } |
你的響應式設計的 90% 策略都在這裡了。而且,你還能在所有同級的流元素之間設定通用的 margin,比如使用 Lobotomized Owls注2 的選擇器:
1 2 3 |
body * + * { margin-top: 1.5rem; } |
總之:擁抱相對性,收穫成果。
裝置斷點
幾個月前,也就是在被爆出蘋果公司在中國血汗工廠不久,我看到一名評論員發的 tweet。他們的 tweet 包含了一種風格:「對於響應式 web 設計,所有的視口在 iOS9 上都是可用的」。
什麼?什麼?
然後我想起和 Sara Soueidan 的一次談話,她把內容斷點描述成了響應式設計的「驚天祕密」。我突然想到:有很多人盯著被選定的專門裝置,把它們特定的螢幕尺寸做為「響應式 web 設計」的目標——每當一家技術公司釋出一款內建瀏覽器的裝置時,都要「改變這個規劃」,那麼,成千上萬的 web 設計師可能要罵「oh fuck me」了。想象一下!
“OHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKME”
我沒有假定你是在此誤解下工作的,但適用於一種情況,你有一個朋友,他需要了解真相:適應於具體裝置的具體尺寸的斷點,不屬於響應式設計。這種行為是站不住腳的,它行不通。如果你沒有針對某種裝置做過調整的設計,具有完整的呈現,那一定是好運氣在作怪。這真不算是一個策略。
你應該確保設計是流動的,僅僅在內容遭遇呈現問題的地方插入斷點(或「tweak point」)。在這些點之間,設計應該無縫地展開或摺疊,滿足任何出現在這些範圍內的裝置尺寸的要求。
我對評論員和意見領袖說,我認為他們要說的話和真正的響應式設計沒有關係。他答道,「理論上我是認可的,但是移動體驗成功的關鍵在於理解現實世界」。也就是說——沒有說明白!我很想知道真正的現實世界是什麼樣子……有一天我必須參觀一下。
總結:蘋果不是唯一一家制作帶有內建瀏覽器裝置的廠商。真的不是。
Fuck CSS,大家開幹吧
感謝你們容忍我對 CSS 作者的看法。如果你是 web 可訪問性和音樂(誰不是呢)的粉絲,你可能樂於支援一些優秀的組織,請檢視 A11Y ROCKS。
註釋
- CSS 的 specificity 特性或稱非凡性,它是衡量一個衡量CSS值優先順序的一個標準,既然作為標準,就具有一套相關的判定規定及計算方式,specificity用一個四位的數字串(CSS2是三位)來表示,更像四個級別,值從左到右,左面的最大,一級大於一級,數位之間沒有進位制,級別之間不可超越。http://www.cnblogs.com/yizuierguo/archive/2009/03/16/1413721.html
- 可參考 https://css-tricks.com/lobotomized-owls/