2024年對CSS來說是輝煌的一年：跨文檔視圖轉換、滾動驅動動畫、錨點定位、動畫高度：自動等等。雖然聽起來有點不合時宜，但我們仍然期待CSS的更多功能。許多功能！
我們集思廣益，提出了一些想法……其中包括你們的一些想法。
我認為我們現在已經擁有了大量的優秀的CSS工具。我們有很多很棒的——而且是新的！ ——功能，我仍在努力學習它們中的許多。
但是！總是有空間容納更多好東西，對吧？或者也許有空間容納四個新東西。如果我可以要求任何新的CSS功能，我會選擇這些。
它即將到來！或者如果你認為CSS工作組（CSSWG）已決定將if()條件添加到CSS值模塊第5級規範中，那麼它已經存在了。這是一個巨大的進步，即使需要一兩年（甚至更多？！）才能得到正式定義並進入瀏覽器。
我對if()的理解是，它是實現容器樣式查詢的關鍵組成部分，這也是我最終想要的。能夠根據另一個元素的樣式有條件地應用樣式可以說是CSS的聖杯。我們已經可以根據其他元素的樣式來設置元素的樣式：has()，所以這將擴展這種魔法，也包括條件樣式。
這更像是一個“錦上添花”的功能，因為我覺得它完全屬於CSS預處理器領域，並且相信擁有用於輕量級抽象的工具是很好的，例如在CSS中編寫函數或mixin。但是，如果有人向我提供mixin，我當然不會說不。這可能是壓垮CSS預處理器的最後一根稻草，並允許我100%的時間編寫純CSS，因為現在當我需要mixin或函數時，我傾向於使用Sass。
我寫了一堆關於mixin提案及其規範初始草案的筆記，讓您了解我為什麼想要這個功能。
是的，請！這是一個次要的開發者便利性，它使CSS與其他語言中的註釋編寫相媲美。我很確定在我的CSS中編寫JavaScript註釋應該在我的最愚蠢的CSS錯誤列表中（即使我沒有把它放在那裡）。
我就是討厭算術，好嗎？ ！有時我只是想要一個大小適合其所在容器的單詞或簡短標題。我們可以使用clamp()之類的工具進行流體排版，但是，這仍然是我不想費心的數學運算。你可能會認為使用容器查詢和容器查詢單位進行字體大小設置可能是一種解決方案，但這並不比視口單位更好。
我只是一個簡單的、小鎮上的CSS開發者，我對過去幾年瀏覽器中出現的所有新功能都非常滿意，我還能要求什麼呢？
我不需要更多關於CSS錨點定位的說服，我已經相信了！在11月份的大部分時間裡學習了它的工作原理之後，我知道在12月份我不會很快就能使用它。
在2024年結束時，只有基於Chromium的瀏覽器支持它，不幸的是，回退和漸進增強並不容易。但是，有一個可用的polyfill（這很棒），但這意味著要添加另一塊JavaScript代碼，這與錨點定位解決的問題形成對比。
不過我很耐心，我等了很長時間才讓：has進入瀏覽器，現在它已經“新可用”在Baseline一年了（你能相信嗎？）。
我喜歡錨點定位，我喜歡彈出窗口，它們非常搭配！
彈出窗口的巧妙之處在於它們出現在#top-layer中，因此您可以避免與z-index相關的堆疊問題。這可能是大多數人需要的全部，但是擁有其他方法將元素移動到那裡將會很有趣。此外，現在我知道#top-layer存在，我想用它做更多的事情——我想知道那裡有什麼。 到底發生了什麼？
好吧，我可能應該從規範開始。事實證明，CSS位置佈局模塊第4級草案討論了#top-layer，它的用途以及處理其中包含的元素樣式的方法。有趣的是，#top-layer由用戶代理控制，似乎是全屏API的副產品。
對話框和彈出窗口是目前可行的方法，但樂觀地說，這些功能的存在可能意味著將來可以通過其他方式將元素提升到#top-layer。這很可能是一個郊狼/路跑者類型的情況，因為我不太確定一旦我得到它，我會用它做什麼。
就我個人而言，級聯層改變了我編寫CSS的方式。我認為如果我們可以在標籤上包含一個layer屬性，那將會很棒。想像一下，能夠在你的項目中包含一個CSS重置，例如：
<code><link href="https://cdn.com/some/reset.css" layer="reset" rel="stylesheet"></code>
或者，根據訪問的頁面，動態添加CSS部分，融入你的級聯層：
<code> <link href="/styles/main.css" rel="stylesheet"> <link href="/components/card.css" layer="components" rel="stylesheet"></code>
這個功能在CSSWG的repo上被提出，就像生活中的大多數事情一樣：這很複雜。
瀏覽器對它們不認識的屬性特別挑剔，加上對處理回退的明確擔憂。該主題也被提交給W3C技術架構組（TAG）討論，所以仍然有希望！
我必須承認這一點，在網絡狂野且人們有點擊計數器的時候，我並不在。事實上，我認為與你們平均的網絡鑑賞家相比，我相當年輕。雖然我知道如何使用float製作佈局（我選擇的第一個網絡課程非常過時），但在使用Flexbox或CSS Grid之前，我不必忍受很長時間，並且從未對IE和瀏覽器支持咬牙切齒。
因此，與過去網絡真正需要的功能——甚至現在的一些功能相比，以下願望可能看起來像是微不足道的請求。無論如何，以下是我希望在2025年看到的三個微不足道的請求：
這是那些你發誓它應該已經可以通過CSS實現的事情之一。情況如下：我發現自己想要知道元素在其同級元素中的索引或子元素的總數。我不能使用counter()函數，因為有時我需要整數而不是字符串。當前的方法是在HTML中硬編碼索引：
<code><link href="https://cdn.com/some/reset.css" layer="reset" rel="stylesheet"></code>
或者，在CSS中編寫每個索引：
<code> <link href="/styles/main.css" rel="stylesheet"> <link href="/components/card.css" layer="components" rel="stylesheet"></code>
無論哪種方式，我都總是留下這樣的感覺：引用這個數字應該更容易；瀏覽器已經有了這些信息，這只是將其公開給作者的問題。它將使交錯動畫的代碼更漂亮、更簡潔，或者只是根據總數更改樣式。
幸運的是，已經有一個關於sibling-count()和sibling-index()函數的工作草案提案。雖然語法可能會改變，但我確實希望在2025年聽到更多關於它們的信息。
<code></code>
我從Adam Argyle那裡偷來了這個，但我確實希望有一種更好的方法來平衡flex-wrap佈局。當元素隨著容器縮小而一個接一個地換行時，它們要么被單獨留下空隙（我不討厭），要么增長以填充它（這讓我很痛苦）：
我希望有一種更原生方法來平衡換行元素：
這絕對很煩人。
我非常喜歡CSSWG及其所做的一切，所以我花了很多時間閱讀他們的工作草案、GitHub問題或關於他們會議的筆記。但是，儘管我喜歡在他們的GitHub中從一個鏈接跳到另一個鏈接，但很難找到與特定討論相關的所有問題。
我認為這提高了表達你對某些主題意見的入門門檻。如果你想參與一個問題，你應該了解所有討論的大局（說了什麼，為什麼有些事情不起作用，需要考慮的其他事情等等），但它通常分散在幾個問題或會議中。雖然問題可能很冗長，但這並不是問題（我喜歡閱讀它們），而是根本不知道討論的一部分存在於某個地方。
因此，雖然它不是直接的CSS願望，但我希望有一種更容易的方法來了解討論的全貌，然後再參與其中。
我們問了！你們回答了！以下是從人群中選擇的幾個選擇：
CSS-Tricks的軌跡在過去幾年裡並不總是那麼順利，所以我們對2025年的最大願望是繼續撰寫和激發關於網絡的討論。 2025年快樂！
以上是2025年的CSS願望清單的詳細內容。更多資訊請關注PHP中文網其他相關文章！
