TPAC 的 CSS 工作組：CSS 有什麼新變化？

上週，我參加了 W3C TPAC 以及那裡的 CSS 工作組會議。 對規范進行了各種更改，並且進行了我認為網頁設計師和開發人員感興趣的討論。 在本文中，我將稍微解釋一下 TPAC 發生的事情，並展示我們在 TPAC 特別針對 CSS 討論的內容的一些示例和演示。

什麼是 TPAC？

TPAC 是 W3C 的技術全體會議/諮詢委員會會議週。 作為 W3C 一部分的所有不同工作組有機會聚集在一個屋簷下。 該活動每年在世界不同的地方舉行，今年在法國里昂舉行。 在 TPAC，CSS 工作組等工作組有自己的會議，就像我們在一年中的其他時間一樣。 但是，因為我們都在一個大樓裡，這意味著其他群體的人可以更容易地作為觀察者來，並且可以討論跨工作組的利益。

TPAC 的與會者通常是一個或多個工作組的成員，致力於 W3C 技術。 他們要么是成員組織的代表，要么是特邀專家。 與 W3C 工作組的任何其他會議一樣，在 TPAC 舉行的所有討論的記錄都將公開提供，通常作為 IRC 在會議期間記錄的日誌。

CSS 工作組

CSS 工作組在 TPAC 和一年中至少兩次其他場合會面； 這是我們每週電話的補充。 在我們所有的會議上，對規範提出的各種問題進行了討論，並做出了決定。 由於能夠與整個團隊一起討論這些問題，或者只是能夠繞過白板或在屏幕上查看演示，因此有些問題保留為面對面討論。

在任何會議（無論是面對面會議還是電話會議）中討論某個問題時，相關的 GitHub 問題都會隨討論記錄更新。 這意味著如果您有想要跟踪的問題，您可以為它加註星標並查看它何時更新。 完整的 IRC 會議記錄也會發佈到 www 風格的郵件列表中。

以下是我們討論過的一些我認為您最感興趣的內容。

CSS 滾動條

CSS 滾動條規範旨在提供一種標準的方式來設置滾動條的大小和顏色。 如果你有 Firefox Nightly，你可以測試一下。 要查看下面的示例，請使用 Firefox Nightly 並通過訪問 Firefox Nightly 中的https://about:config啟用標誌layout.css.scrollbar-width.enabled和layout.css.scrollbar-color.enabled 。

該規範為我們提供了兩個新屬性： scrollbar-width和scrollbar-color 。 scrollbar-width屬性可以採用auto 、 thin 、 none或length值（例如1em ）。 看起來好像可以從規範中刪除length值。 可以想像，Web 開發人員可能會通過調整寬度來製作非常不可用的滾動條，因此最好讓瀏覽器確定有意義的確切寬度，而不是顯示細或粗滾動條。 Firefox 沒有實現長度選項。

如果你使用auto作為值，那麼瀏覽器將使用默認的滾動條： thin會給你一個細滾動條，而none將顯示不可見的滾動條（但元素仍然是可滾動的）。

在支持 CSS 滾動條的瀏覽器中，您可以在演示中看到這一點：

scrollbar-color屬性處理——正如你所期望的——滾動條顏色。 滾動條有兩個部分，您可能希望獨立著色：

• 拇指
  滾動時上下移動的滑塊。
• 追踪
  滾動條背景。

scrollbar-color屬性的值是auto 、 dark 、 light和<color> <color> 。

使用auto作為關鍵字值將為您提供該瀏覽器的默認滾動條顏色， dark將提供深色滾動條，無論是在該平台的暗模式還是自定義暗模式， light平台的亮模式或自定義亮模式.

要設置自己的顏色，請添加兩種顏色作為值，並用空格分隔。 第一種顏色用於拇指，第二種顏色用於軌道。 您應該注意顏色之間有足夠的對比度，否則滾動條可能對某些人來說難以使用。

在支持 CSS 滾動條的瀏覽器中，您可以在演示中看到：

請參閱 CodePen 上 Rachel Andrew (@rachelandrew) 的 Pen CSS 滾動條：滾動條顏色。

縱橫比單位

一段時間以來，我們一直在使用 CSS 中的 padding hack 來實現長寬比框，然而，隨著 Grid Layout 和更好的調整內容大小的方法的出現，在 CSS 中實現長寬比的真正方法已成為更緊迫的需求.

GitHub 上提出了兩個與此要求相關的問題：

• 需要的縱橫比單位
• 縱橫比。

現在在 CSS Sizing 的 Level 4 中有一個規範草案，會議的決定是這需要在 GitHub 上進一步討論，然後才能做出任何決定。 因此，如果您對此感興趣，或者有其他用例，CSS 工作組會對您對這些問題的評論感興趣。

:where()函數偽類

去年，CSSWG 決定添加一個偽類，其行為類似於:matches()但具有零特異性，從而使其易於覆蓋，而無需人為地誇大後續元素的特異性來覆蓋默認樣式表中的某些內容。

:matches()偽類對您來說可能是新的，因為它是一個 4 級選擇器，但是，它允許您指定一組選擇器來應用一些 CSS。 例如，您可以編寫：

 .foo a:hover, pa:hover { color: green; }

或使用:matches()

 :matches(.foo, p) a:hover { color: green; }

如果你曾經有一大堆選擇器只是為了設置相同的規則，你會看到這將是多麼有用。 以下 CodePen 使用前綴名稱webkit-any和-moz-any來演示matches()功能。 您還可以在 MDN 上閱讀有關 match() 的更多信息。

我們經常做這種選擇器的堆疊，因此:matches()最有用的地方是在某種初始的默認樣式表中。 但是，我們在覆蓋這些默認值時需要小心，任何覆蓋都是以確保它比默認值更具體的方式完成的。 正是出於這個原因，提出了零特異性版本。

會議討論的問題是關於這個偽類的命名，你可以在這裡看到最終的解決方案，如果你想知道為什麼排除了各種名稱，請查看完整的線程。 在 CSS 中命名非常困難——因為我們都將不得不永遠忍受它！ 經過大量辯論，該小組投票決定將此選擇器稱為:where() 。

自那次會議以來，在我寫這篇文章的過程中，有人提出了將matches()重命名為is()的建議。 如果您有任何強烈的感受，請查看問題並發表評論！

邊距和填充的邏輯簡寫

關於命名事物，我過去曾在 Smashing Magazine 上寫過有關邏輯屬性和值的文章，請參閱“了解邏輯屬性和值”。 這些屬性和值提供流相關映射。 這意味著，如果您使用的不是水平從上到下的書寫模式（例如英語），則邊距和填充、寬度和高度等內容將遵循文本方向，並且與物理屏幕尺寸無關。

例如，對於實物保證金，我們有：

• margin-top
• margin-right
• margin-bottom
• margin-left

這些（假設為水平-tb）的邏輯映射是：

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

我們可以有兩個值簡寫。 例如，要將margin-block-start和margin-block-end都設置為簡寫，我們可以使用margin-block: 20px 1em 。 第一個值表示塊維度中的起始邊，第二個值表示塊維度中的結束邊。

然而，當我們談到四值速記margin時，我們遇到了一個問題。 該屬性名稱用於物理邊距——我們如何表示邏輯四值版本？ 已經提出了各種建議，包括文件頂部的開關：

 @mode "logical";

或者，使用一個看起來有點像媒體查詢的塊：

 @mode (flow-mode: relative) { }

然後是關鍵字修飾符的各種建議，使用一些標點符號，或者創建一個全新的屬性名稱：

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

您可以閱讀該問題以查看正在考慮的各種事項。 討論的問題是，雖然邏輯版本很可能最終成為默認版本，但有時您會希望事情與屏幕幾何形狀相關； 我們需要能夠在一個樣式表中同時擁有這兩個選項。 在 CSS 頂部設置@mode可能會造成混淆； 如果有人要復制和粘貼一大塊樣式表，它將失敗。

我的偏好是具有某種關鍵字值。 這樣，如果您查看規則，您可以準確地看到正在使用的模式，即使它看起來有點不雅。 這是預處理器可以為您處理的事情； 如果您確實希望所有屬性和值都使用邏輯版本。

我們沒有設法解決這個問題，所以如果您確實對其中哪些可能是最好的有想法，或者可以看到我們沒有描述的問題，請在 GitHub 上評論這個問題。

網絡平台測試討論

在 CSS 工作組會議和非會議風格的技術全體會議期間，我參與了討論如何讓更多人參與編寫 CSS 規範測試。 Web 平台測試項目旨在為所有 Web 平台提供測試。 這些測試然後幫助瀏覽器供應商檢查他們的瀏覽器是否符合規範。 在 CSS 工作組中，目標是對已達到候選推薦 (CR) 狀態的規範的任何規範性更改都應伴隨測試。 這是有道理的，因為一旦規範在 CR 中，我們就會要求瀏覽器實現該規範並提供反饋。 他們需要知道規範中是否有任何更改，以便他們可以更新他們的代碼。

問題是我們編寫規範的人很少，所以規範編寫者必須編寫所有測試會減慢 CSS 的進度。 我們希望看到其他人編寫測試，因為這是為 Web 平台做出貢獻並深入了解規範如何工作的一種方式。 因此，我們開會思考如何鼓勵人們參與這項工作。 我過去曾寫過關於這個主題的文章； 如果您對為平台編寫測試的想法感興趣，請查看我關於“測試 Web 平台”的 24 種方式文章。

繼續工作！

TPAC 已大大增加了我的個人待辦事項清單。 然而，我已經能夠獲得關於規範編輯、測試寫作的技巧，並製定了一個計劃，以使多列佈局規範（我是其中的共同編輯）恢復到 CR 狀態。 作為一個不喜歡會議的人，我來看看這些面對面會議對於網絡平台的價值，讓我們這些為它做出貢獻的人有機會分享我們個人正在開發的知識。 我覺得重要的是，然後將這些知識並在團隊之外分享，以幫助更多的人參與開發和使用該平台。

如果您對 CSS 工作組的運作方式以及新的 CSS 是如何發明並最終在瀏覽器中產生興趣感興趣，請查看我在 2017 CSSConf.eu 的演示文稿“CSS 來自哪裡？” 以及來自 fantasai 在她的帖子“W3C CSS 工作組的內部視圖”中的信息。