Using CSS3 Today(現在使用 CSS3)

回顧 CSS 的傳奇歷史，我們看到一些重要的里程碑，它們塑造了我們作為網頁設計師的方向。這些具有里程碑意義的技術、文章和活動幫助我們創建了靈活、易於訪問的網站，無論是在視覺上還是在幕後，我們都可以為這些網站感到自豪。

你可能會說，事情在 2001 年就開始變得有趣了，當時 Jeffrey Zeldman 寫了“讓糟糕的瀏覽器見鬼去吧”(http://bkaprt.com/css3/1/)，年齡。該宣言鼓勵設計師推動 CSS¹ 標誌著 CSS 的黎明的應用，而不僅僅是鏈接顏色和字體，從而拋棄那些因 CSS1 而陷入困境的舊版、無能的瀏覽器。是的， CSS1。

在接下來的幾年裡，我們發現並分享了使用 CSS 來實現我們對客戶和老闆的期望的技術。這是一個令人興奮的時刻，以提高靈活性、改進可訪問性和減少代碼的名義進行試驗、突破界限並找出處理跨瀏覽器渲染問題的複雜方法。

大約在 2006 年左右，關於 CSS 的討論逐漸平靜。我們需要解決的大多數問題都有記錄的解決方案。常見的瀏覽器錯誤有多種解決方法。我們為因無法解釋的 Internet Explorer 錯誤而受到情感創傷的設計師創建了支持小組。

我們的頭髮開始變白。 （好吧，我在這裡代表自己說話。）但最重要的是，當代的瀏覽器相對停滯不前。這段時期的現狀讓我們有時間設計可重用的方法並建立最佳實踐，但我敢說，對於渴望更好工具的 CSS 愛好者來說，事情變得有點無聊。

值得慶幸的是事情發生了變化。瀏覽器開始更快地迭代和更新（好吧，無論如何，其中一些）。 Firefox 和 Safari 不僅開始獲得市場份額，而且還憑藉更快的開發週期蓬勃發展，增加了可靠的標準支持以及更多實驗性屬性。在許多情況下，這些具有前瞻性的瀏覽器選擇實現的技術隨後被折疊回草案規範中。換句話說，瀏覽器供應商定期推動規範的發展。

但不要閱讀規範(But don’t read the spec)

問一屋子的網頁設計師，“誰喜歡閱讀規範？”你可能會讓一個人舉手。 （如果你是那個人，我讚揚你和你顯然擁有的空閒時間）。雖然它們是重要的參考資料，但我當然不喜歡閱讀完整的規範，也不建議這樣做來整體掌握 CSS3。

好消息是 CSS3 實際上是一系列模塊，這些模塊被設計為彼此分開且獨立地實現。這是一件非常好的事情。這種分段方法使規範的某些部分能夠比其他部分更快（或更慢）地發展，並鼓勵瀏覽器供應商在整個 CSS3 被認為完成之前實現進一步發展的部分。

W3C 解釋了模塊方法(The W3C explains the module approach)：

與其嘗試將數十個更新塞入單個整體規範中，不如能夠更新規範的各個部分會更容易、更高效。模塊將使 CSS 能夠以更及時、更精確的方式進行更新，從而使整個規範能夠更靈活、更及時地發展。 2

對於我們網頁設計師來說，這樣做的好處是，除了實驗和更快的發布週期之外，還可以在等待許多 CSS3 屬性成為候選推薦（也許是幾年後）之前使用它們。

現在，無論如何，如果您喜歡閱讀規範，那就去吧！當然，其中有很多東西需要學習，但更實際的做法是關注當前已實現和可用的內容，這些都是我們將在本章其餘部分討論的內容。稍後，我們將在本書其餘部分的示例中應用這些內容。

我總是通過剖析野外例子而不是閱讀白皮書來了解更多關於網頁設計的知識，這就是我們將在接下來的幾頁中強調的內容。

CSS3 適合所有人(CSS3 is for everyone)

我從全球各地的網頁設計師那裡經常聽到這樣的話：“我迫不及待地想使用CSS3 ⋯⋯ 當它完成時。”

但事實是每個人現在就可以開始使用 CSS3。幸運的是，您不必為此進行不同的思考或對製作網站的方式做出重大改變。任何人如何在任何項目中使用 CSS3？因為我們要仔細選擇應用 CSS3 的場景，重點關注體驗層。

瞄準體驗層(Targeting the experience layer)

如果我們在過去幾年裡一直在做正確的事情，那麼我們一直在網絡標準的基礎上構建（用於佈局、類型、顏色等的語義 HTML 和 CSS），留下大部分交互效果 動畫、反饋和移動 針對 Flash 和 JavaScript等技術。隨著 CSS3 屬性在具有前瞻性的瀏覽器中緩慢而穩定地引入，我們可以開始將一些體驗層轉移到我們的樣式表中。

作為一名界面設計師，他更傾向於設計的視覺方面而不是編程方面，我越能使用 HTML 和 CSS 等已經熟悉的工具來打造引人注目的用戶體驗，我就越能跳起快樂的小舞。

CSS3 適合像你我這樣的網頁設計師，我們今天就可以開始使用它的一部分，只要我們知道何時以及如何折疊它。

何時應用CSS3(When to apply CSS3)

就網站的視覺體驗而言，我們可以將其分為兩類：關鍵和非關鍵（表 1.01）。

表 1.01：網站的視覺體驗可分為關鍵和非關鍵類別。後者是當今 CSS3 可以應用的地方。

品牌、可用性和佈局等領域對於任何網站的成功都至關重要，因此使用並非所有瀏覽器都完全支持的技術將是一項冒險的冒險。

例如，在不斷發展的 CSS3 規範中，有多個用於控制佈局的草案 這是我們迫切需要的。多年來我們一 直在改變浮動屬性來處理佈局。我們已經弄清楚如何利用我們現有的資源，但真正的佈局引擎絕對是必要的。

也就是說，三個新的 CSS3 佈局模塊中的兩個尚未被任何瀏覽器實現。它們仍在製定中，可以說仍然令人困惑，難以掌握，而且可能不是我們一直在尋找的最終解決方案。最重要的是，對於像佈局這樣重要的東西， CSS3 並不是合適的工具。然而另一方面是非關鍵事件，例如交互（懸停、焦點、表單元素、瀏覽器視口靈活性）以及這些交互（以及動畫）產生的視覺增強。對於此類事件，在瀏覽器之間匹配相同的體驗並不那麼重要，這就是為什麼現在為支持 CSS3 的瀏覽器應用 CSS3 某些部分的絕佳機會。

在這些非關鍵事件之上，我們將在整本書中應用 CSS3，為所有瀏覽器保持頁面更重要的特徵完整，無論它們當前的 CSS3 支持如何。
當我們決定專注於視覺體驗的這些非關鍵領域時，在 CSS3 上分層並豐富網站的交互就變得非常自由，而不必擔心核心消息、佈局和可訪問性會受到阻礙。

目前可用的核心 CSS3 屬性(Core CSS3 properties that are usable today)

因此，雖然我們已經將體驗層確定為今天可以安全應用 CSS3 的地方，但我們還想確定可以使用哪些 CSS3 屬性。 也就是說，規範的哪些部分已經達到了足夠的瀏覽器實現臨界點，可以立即實用和可用。
CSS3 的大部分內容尚未在任何瀏覽器中實現。 事情仍在解決中。 我們可以對那些不斷變化的塊感到好奇，但我們最好將注意力集中在真正有效的東西上，幸運的是，現在有相當多的東西是有效的。
讓我們快速瀏覽一下我們將在本書示例中使用的相對較小的核心 CSS3 屬性集（如下和表 1.02）。 我只是在這裡介紹它們，因為稍後我們將更深入地研究高級語法和實際用法。

表 1.02：CSS3 屬性和支持它們的瀏覽器。

PROPERTY(屬性)	SUPPORTED IN(支持於)
border-radius(邊界半徑)
text-shadow(文字陰影)
box-shadow(盒子陰影)
Multiple background images(多個背景圖像)
opacity(不透明度)
RGBA

邊界半徑(border-radius)
使用指定的半徑值對元素的角進行圓化。 支持 Safari 3+、Chrome3+、Firefox 1+、Opera 10.5+ 和 IE9 Beta。 例子：

1
2
3

.foo {
  border-radius: 10px;
}

文字陰影(text-shadow)
一個 CSS2 屬性（在 2.1 中被刪除，然後在 CSS3 中重新引入），用於向超文本添加陰影，並提供陰影的方向、模糊量和顏色選項。 在 Safari 1.1+、Chrome 2+、Firefox 3.1+ 和 Opera 9.5+ 中受支持。 例子：

1
2
3

p {
  text-shadow: 1px 1px 2px #999;
}

盒子陰影(box-shadow)
向元素添加陰影。 與文本陰影相同的語法。 支持 Safari 3+、Chrome 3+、Firefox 3.5+、Opera 10.5+ 和 IE9 Beta。 例子：

1
2
3

.foo {
  box-shadow: 1px 1px 2px #999;
}

多個背景圖像(Multiple background images)
CSS3 添加了在一個元素上應用多個背景圖像（用逗號分隔）的功能，而不是像 CSS2.1 中定義的那樣僅使用一個背景圖像。 支持 Safari 1.3+、Chrome 2+、Firefox 3.6+、Opera 10.5+ 和 IE9 Beta。 例子：

1
2
3
4
5

body {
  background: url(image1.png) no-repeat top left,
  url(image2.png) repeat-x bottom left,
  url(image3.png) repeat-y top right;
}

不透明度(opacity)
定義元素的不透明程度。 值為 1 表示完全不透明，值為 0 表示完全透明。 在 Safari 1.2+、Chrome 1+、Firefox 1.5+、Opera 9+ 和 IE9 Beta 中受支持。 例子：

1
2
3

.foo {
  opacity: 0.5; /* .foo will be 50% transparent */
}

RGBA
不是 CSS 屬性，而是 CSS3 中引入的新顏色模型，增加了指定不透明度級別以及 RGB 顏色值的功能。 支持 Safari 3.2+、Chrome 3+、Firefox 3+、Opera 10+ 和 IE9 Beta。 例子：

1
2
3

.foo {
  color: rgba(0, 0, 0, 0.75); /* black at 75% opacity */
}

當然，現在這個清單還遠非詳盡無遺。 CSS3 包含更多屬性和工具，其中許多仍在開發中，尚未在任何瀏覽器中實現。 但您會注意到，前面列表中的每個屬性都達到了瀏覽器支持的特定閾值：它至少適用於兩種主要瀏覽器。 在某些情況下，Internet Explorer（和 Opera）的未來版本承諾提供支持。
因此，基於 Safari、Chrome、Firefox 和 Opera 中相對不錯的支持，我們現在有了一個簡潔的屬性列表可供使用。 它們還不能全面工作，我們將在本書後面討論為什麼可以這樣做，以及如何規劃這種不統一的支持。

我們不打算介紹的內容(What we aren’t going to cover)

我列出了我們將在書中經常使用的一些 CSS3 屬性，但是其餘的呢？ 我選擇不在這裡詳盡地介紹所有內容，而是介紹目前實際可用的內容，因為它具有良好、穩定的瀏覽器支持。
CSS3 規範的其他部分現在可能可用，但超出了本書的範圍（並且可能需要完全單獨編寫一本書）：

1. 媒體查詢 (http://www.w3.org/TR/CSS3-mediaqueries/)
2. 多欄佈局（http://www.w3.org/TR/CSS3-multicol/）
3. 網頁字體 (http://www.w3.org/TR/CSS3-webfonts/)

讀完本書後，請務必查看這些其他模塊。

供應商特定的前綴(Vendor-specific prefixes)

我之前提到CSS3規範是瀏覽器供應商正在慢慢推出的一系列模塊。 在某些情況下，這種推出涉及實驗支持。 也就是說，當 W3C 正在編寫、討論和討論該規範時，瀏覽器製造商可能會選擇添加對某些屬性的支持，並在現實環境中對其進行測試。 它已經成為這個過程的一個健康的部分，實驗使用的反饋經常被用來
對規格進行調整。
或者，瀏覽器供應商可能希望引入一種實驗性屬性，該屬性不屬於任何擬議標準，但可能會在以後成為標準。
通常，這種對 CSS 屬性的實驗性支持是通過使用供應商前綴來處理的，如下所示：

1

-webkit-border-radius

這個以破折號為前綴的關鍵字附加在屬性名稱的開頭，將其標記為正在進行的工作，特定於瀏覽器的實現和對不斷發展的規範的解釋。 如果當實驗成為已完成的 CSS3 模塊的一部分時，瀏覽器應該支持未來的無前綴屬性名稱。
每個瀏覽器供應商都有自己的前綴，本質上是為其實驗屬性命名。 其他瀏覽器將忽略包含它們無法識別的前綴的規則。
表 1.03 顯示了最廣泛使用的供應商及其相關前綴，我們將使用 WebKit、Mozilla 和 Opera 前綴，因為它們與前面章節的示例中的 CSS3 相關。

表 1.03：最廣泛使用的供應商及其相關的前綴。

	WebKit	–webkit–
	Mozilla	–moz–
	Opera	–o–
	Konqueror	–khtml–
	Microsoft	–ms–
	Chrome	–chrome–

供應商前綴如何工作(How vendor prefixes work)

以下是供應商前綴 CSS 在實踐中的工作原理； 我們將使用 border-radius 屬性作為示例。 假設我們想要對半徑為 10 像素的元素進行圓角處理； 我們的做法如下：

1
2
3
4
5

.foo {
  -webkit-border-radius: 10px;
  -moz-border-radius: 10px;
  border-radius: 10px;
}

WebKit（Safari、移動 Safari 和 Chrome 背後的引擎）和 Gecko（Firefox 背後的引擎）瀏覽器均通過自己的供應商前綴版本支持 border-radius 屬性，而 Opera 支持沒有供應商前綴的屬性。 IE9 還將支持不帶供應商前綴的 border-radius。

最優排序(Optimal ordering)

使用供應商前綴時，請務必記住在聲明中列出規則的順序。 您會注意到，在上面的示例中，我們首先列出了供應商前綴的屬性，然後是無前綴的 CSS3 屬性。

為什麼把實際的 CSS3 屬性放在最後？ 因為您的樣式將來可能會在更多瀏覽器中運行，因此將逐步增強您的設計。 當瀏覽器最終實現對規範中定義的屬性的支持時，該實際屬性將勝過實驗版本，因為它排在列表的最後。 如果供應商特定版本的實現與實際財產不同，您將確保以最終標準為準
最高。

不要害怕供應商前綴(Don’t be afraid of vendor prefixes)！

你的第一反應可能是，“布萊奇，這是混亂的、專有的東西！” 但我向您保證，這不僅是一種前進的方式，而且比非 CSS3 解決方案經常出現的代碼臃腫和缺乏靈活性要簡單得多，而且也是規範發展的重要組成部分。
現在通過供應商前綴使用這些屬性，我們可以試水，甚至可以在規範最終確定之前向瀏覽器製造商提供有價值的反饋。 還要記住，前綴通常附加在提議的標准上。 這與我們定期用來解決跨瀏覽器問題的其他 hackish CSS 有很大不同。
有些人可能會將供應商前綴與我們許多人用來針對特定瀏覽器版本的語法漏洞進行比較（例如，使用 w\idth: 200px 或 _width: 200px 來針對特定版本的 IE）。 相反，供應商前綴是標準流程的重要組成部分，允許屬性在現實世界的實現中不斷發展。

正如 CSS 專家 Eric Meyer 在 A List Apart (http://bkaprt.com/css3/2/) 上的“Prefix or Posthack”中所解釋的那樣：3

前綴讓我們能夠掌控自己的黑客命運。 在過去，我們不得不發明一堆解析器漏洞，只是為了讓不一致的實現在我們發現它們不一致時表現得相同。 這是一種完全被動的方法。 前綴是一種主動的方法。

他接著建議供應商前綴不僅是積極的，而且應該成為標準流程的核心，並且會：

…迫使供應商和工作組共同努力設計確定互操作性所需的測試。 這些測試可以指導後續人員，幫助他們更快地達到可互操作狀態。 他們實際上可以在一個公共測試版中發布帶前綴的實現，並在下一個公共測試版中刪除前綴。

因此，不必擔心供應商前綴。 使用它們時要知道您是流程的一部分，可以讓您完成今天的工作，並為將來可以刪除前綴鋪平道路。

那麼所有這些重複呢(What about all that repetition)？

您可能認為必須為每個供應商重複看似相同的房產三到四次是愚蠢的，我可能會同意您的觀點。
但現實情況是，非 CSS3 解決方案可能需要不靈活且更複雜的代碼，儘管可能是非重複的。

我們不需要永遠重複自己。 目前，這是一個必要但臨時的步驟，以將瀏覽器之間潛在的不同實現與最終規範實現分開。
在我們開始使用少數可用的 CSS3 屬性及其各自的供應商前綴做一些引人注目的事情之前，讓我們對 CSS 轉換有一個基本的了解。 了解過渡及其運作方式將有助於我們將它們與其他酒店結合起來，創造美妙的體驗。

1. 長網址：http://www.alistapart.com/articles/tohell/ [↵]
2. http://www.w3.org/TR/css3-roadmap/#whymods [↵]
3. http://www.alistapart.com/articles/prefix-or-posthack/ [↵]

Jangow9JqzJiYx20230701pkagr