首頁 >web前端 >css教學 >CSS Parts 將你從惡夢中拯救出來

CSS Parts 將你從惡夢中拯救出來

Patricia Arquette
Patricia Arquette原創
2024-11-26 11:02:09275瀏覽

CSS Parts are saving you from a nightmare

必要的背景

最近,我在聽一個著名的播客,很棒的主持人正在談論 Web 組件,列出了各種 Web 組件規格和功能的所有好的、壞的和醜陋的部分。

向 Chris Coyier 和 Dave Rupert 致敬,感謝他們的完全公平的劇集和精彩的對話。在這裡收聽該劇集:

商店脫口秀

任何人,在那一集的深處,我驚訝地發現 CSS Parts 進入了壞人列表,儘管我可以看到人們可能認為它們不是最好的一些原因。我碰巧認為CSS 部分不僅非常好,而且實際上將我們所有使用它們的人從一個場景中拯救出來,這種場景比無法像無法完全設置Web 組件影子根中的每個元素的樣式更煩人和令人沮喪你想要的。

讓我解釋一下,但先了解更多背景!

Web 元件主要是為第三方使用而設計的

我無法明確驗證以下所有內容是否屬實,但我個人的觀點(在過去幾年的日常工作中編寫、使用和幫助規範Web 元件功能時產生的)是,現有的Web 元件規格和功能都是為了解決“第三方組件”用例而設計的。也就是說,Web 元件旨在支援非常具體的情況:元件作者創建一個工具,其他消費者可以從網路下載並在他們的應用程式中使用該工具。

我覺得,如果您透過「第三方元件」用例的角度來看待 Web 元件功能,那麼規範編寫者和瀏覽器實作者所採取的許多方法都非常有意義。以shadow dom風格封裝的嚴重性為例。如果您將一個元件從互聯網上拉到您的應用程式中,那麼不必擔心該元件的 css 會以某種方式破壞您的頁面之一,這不是很棒嗎?不必關心您沒有編寫的組件的內部結構,並將該組件視為黑盒並通過定義良好的 api 表面與其進行交互,這不是很棒嗎?

理解 Web 元件如何設計工作的大部分問題是,自從創建 Web 元件規格以來,產業已經發生了變化,如今我們在應用程式中使用的 99% 的元件都不是來自外部來源。如今,當我們想到組件時,大多數時候我們想到的是我們或我們的團隊編寫的“第一方組件”,而不是互聯網上的某個人。我們在應用程式中不會使用那麼多外部元件,因此主要針對該用例設計的 Web 元件 API 對我們來說似乎很奇怪,特別是當我們也嘗試使用 Web 元件為自己建立第一方元件時。

因此,對於我在本文中要說的所有其他內容,假設我指的是「第三方組件」情況。想像一下,我正在談論的元件是您下載的一個 npm 包,並且有一個 GitHub 自述文件和補丁說明等,但您(或您的團隊)沒有為您自己的應用程式自己編寫它。

CSS 部件對於您為自己或團隊編寫並完全控制的樣式組件來說並不是一個很好的介面。

CSS 元件是 Web 元件公共 API 的一部分

精心設計的元件有多種不同的互動方式。優秀的 Web 元件具有用於自訂 HTML 的插槽、用於自訂主題的 CSS 自訂屬性以及用於自訂樣式的 CSS 元件。 Shop Talk Show 的朋友們討論了 CSS 部件,背景是它們對於自由形式樣式來說很笨重,但我不會那樣考慮 CSS 部件。我將它們視為組件的另一個公共 API 表面,與屬性或特性非常相似。人們通常不太擔心無法為從互聯網上取得的元件建立自訂屬性或屬性。我認為CSS Parts 是同樣的想法。組件作者指定內部模板的各個部分可以按照您想要的任何方式「設定樣式」。因此,能夠為 Shadow dom Web 元件中的每個內部元素設定樣式並不一定是一種期望。

還有誰比組件作者更了解某個複雜模板的哪些部分可以套用任何樣式呢?如果您從互聯網上獲取一個組件只是為了轉身並重寫所有樣式,可能會在此過程中破壞可訪問性等,那麼您為什麼首先安裝該組件呢?我得到了許多人所提倡的「我知道我在做什麼」陰影根選擇器的吸引力,但在下一節中,我將闡明為什麼我認為有一個定義的樣式API 表面與內部DOM 結構斷開連接實際上是令人驚奇的,應該慶祝它幫助我們所有開發人員不發瘋。

提示老式電影預告片聲音

在一個存在「我知道我在做什麼」選擇器而 CSS 部件不存在的世界中

讓我們跳入一個想像的世界,其中CSS 部件不存在,並且存在一些“我知道我在做什麼”選擇器(為了懷舊,我們將其稱為/deep/),並且是存在的“方式」您應該設定某些影子根Web 元件的內部DOM 模板的樣式。

你的應用程式需要一個這樣的元件,所以你去下載一個 npm 套件

npm i some-awesome-package@1.2.3

並在您的應用程式中包含以下 HTML:

<some-awesome-component></some-awesome-component>

Some Awesome Component 元件中有一個預設為紅色的 div,並且不使用任何 CSS 自訂屬性。一開始,紅色 div 完全沒問題!

但隨後您決定需要將紅色 div 的顏色變更為 rebeccapurple。所以你寫這篇CSS:

@layer my-overides {
  some-awesome-component /deep/ div.the-red-div {
    background: rebeccapurple;
  }
}

the-red-div 對於一個類別來說是一個糟糕的名字,但是嘿,沒有人關心 Shadow dom Web 元件的內部結構,對吧?它們不能與外界發生衝突,因此元件作者可以根據需要編寫糟糕的類別名稱。

因為我們處於 /deep/ 存在的想像世界中,所以一切正常!紅色 div 現在是紫色的,一切都是 Coolio。

你忽略了我們大腦中微小的認知失調,即 .the-red-div 的顏色不是紅色。那是明天的問題。

甜甜的!

然後組件作者新增一個功能並發布補丁

CSS Parts are saving you from a nightmare

您正忙著運送,一路上,您重新安裝了一個不相關的軟體包,並拉取了一些很棒的組件的最新補丁,紅色 div 又回來了!

什麼給了?你去搜尋補丁說明,你會發現:

## 1.2.4
- [a987s83] Added cool button, fixed a11y issues

看起來不錯,為什麼 CSS 損壞了?變更日誌註釋沒有任何線索。所以你瀏覽了最新的幾篇 PR,並沒有看到任何讓你感興趣的內容。

因此,您啟動應用程式並檢查影子根,紅色 div 是一個 。現在!元件作者意識到他們的類別名稱 the-red-div 應該更通用,並將其更改為 colorful。

好的,所以你將 css 編輯為:

@layer my-overides {
  some-awesome-component /deep/ .colorful {
    background: rebeccapurple;
  }
}

一切又恢復正常了!

然後作者會在下週發布另一個補丁

跳回現實世界

直接 CSS 選擇器存取你無法控制的 DOM 是一個巨大的槍

看到模式,因此直接選擇器存取您不擁有或控制的內部範本時出現問題?

不可避免地,內部模板的變更將超出您(組件使用者)的控制。不可避免地,這些變化將以一種幾乎看不見的方式發生,而無需手動或使用不穩定的視覺回歸測試工具對正在運行的應用程式的每一部分進行目視檢查。如果您使用來自互聯網的組件,那麼就會有某種合約。元件作者擁有 Shadow dom,而您(消費者)擁有 :host 元素(您編寫的程式碼中的 HTML 標記本身)。在沒有某種契約的情況下跨越這個邊界是脆弱代碼的保證。

有趣的事實是,在 JS 中對 DOM 元素進行直接 Shadow dom querySelectors 時也會發生這種脆弱性。如果您的應用程式依賴某些元素來始終存在,那麼它就不會存在。如果您查詢不受您控制的 DOM,有一天某些元素將不存在。它要么是不同的元素,要么具有不同的類別/屬性/id。

但 CSS Parts 會為您提供支持

CSS Parts are saving you from a nightmare

因為 CSS 元件是簡單的字串,本身不是 DOM 元素,所以使用它們可以保護您的應用程式免受脆弱程式碼的影響。第三方作者永遠不會測試某個 div 永遠是 div。但是,如果他們創建 CSS 零件,他們就知道他們正在為該元件建立一個公共 API,如果不進行重大更改,就無法刪除或更改該 API。如果您使用 CSS 元件而不是直接查詢 Shadow DOM,那麼元件作者可以在 Shadow DOM 中移動該 CSS 元件,而您的應用程式程式碼不會中斷。

此外,由於 CSS Part 名稱暗示了關係、概念和功能,因此組件作者很難重構組件以使 CSS Part 實質上改變其含義。因此,除了知道使用程式碼的 CSS 部件不會因為組件作者在沒有通知您的情況下進行更改而中斷之外,您還可以合理地確定 CSS 部件與整體的關係始終是同一類事物成分。因此,即使組件隨著時間的推移而演變,您應用於該部分的樣式也將相當確定始終對該部分「有意義」。

更進一步

我看到了一些來自非常聰明且有價值的行業人士關於 CSS 部件的痛苦的評論,並且通過選擇器添加直接的 Shadow dom 訪問會更加方便。如果隨著時間的推移一切都沒有改變,我會全心全意地同意。但由於元件確實會隨著時間的推移而發生變化,我敢說直接存取影子 DOM 會比記住哪些 CSS 零件可供使用更痛苦。

每當討論如何跨越「應用程式」和元件內的 Shadow dom 之間的邊界時,我總是提倡使用一些命名的結構契約方法,例如 CSS Parts,而不是直接選擇器存取。在我看來,任何認為 CSS 部件笨重且糟糕的人都不必在整個應用程式中尋找影子根模板在他們不知情的情況下更改的所有位置:)

結論

CSS 零件很棒,當您使用它們時,即使您100% 是一位出色的開發人員並且您知道自己在做什麼,您也100% 不希望可能需要調整所有自訂CSS 帶來的痛苦每次您使用的元件出現補丁時,您都會編寫此內容。您肯定知道自己在做什麼,但我們所有人都希望防止我們的應用程式隨機損壞,而這就是直接影子 DOM 樣式所要做的。 「我知道我在做什麼」選擇器肯定會讓您的樣式正常工作,但只有在您從不更新樣式的包版本時才能保證正常工作。如果您確實更新了版本,則每次都必須留意所有這些「我知道我在做什麼」樣式。

我認為這是浪費我們寶貴的時間。只需使用 CSS 部件並鼓勵組件開發人員將它們添加到他們編寫的組件中即可。

以上是CSS Parts 將你從惡夢中拯救出來的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn