CSS 層疊式宣告 - 讓你快速選到特定元素內的物件的選取器裡面提到了 CSS Selector 是從右到左比對的這個資訊，我印象中也是這樣沒錯，看到之後想說應該滿容易就能找到來源，就隨手 Google 一下。

Google 以後發現是來自一個 Stackoverflow 上的回答：Why do browsers match CSS selectors from right to left?，我之前也是看到那一篇。但仔細看一下之後發現事有蹊蹺，第一是這回答已經是 2011 年了，第二是當年有的參考資料，例如說 Google 官方的文件或者是 Mozilla 的文件現在都不見了（可參考：CSS combinator precedence?），於是就再去找了一下相關資料。

發現有人跟我一樣感到疑惑，所以問了這個問題：What happened to the “Use efficient CSS selectors” rule?，底下有人貼了一篇：CSS Selector Performance has changed! (For the better)，內容大意是說 webkit 對 CSS selector 做了一系列的優化，所以開發者不必擔心如何自己優化，那應該是引擎的事。也有把幾個優化給寫出來。

Mozilla 在 2017 年發表的文章 Inside a super fast CSS engine: Quantum CSS (aka Stylo) 有提到 CSS engine 的工作流程，但也沒有明確提到從右比對到左這件事，但還是滿值得一看的文章就是了。

然後今天剛好發現這篇：05. [CSS] 元素選取器是如何運作的？也在講類似的事情，而且附上的參考資料更多。

稍微總結一下，CSS selector 比對應該還是由右到左沒有錯，但原本的 selector 效能問題在八年後的今天應該不是什麼問題了，可能都被 css engine 的優化給做掉了。這個感覺有點像是：

for(let i=0; i<arr.length; i++){
}

const len = arr.length
for(let i=0; i<len; i++) {
}

第一個 for loop 每跑一圈都要存取一次 arr.length，第二個先算好之後就不用每次都跑，所以照理來說第二個會快一點。但有兩個問題，第一個是這個「快一點」可能只是 0.1ms 的差異，小到可以忽略（除非你是在真的很注重效能的環境），第二個是 compiler 很可能會把第一個優化成第二個那樣，所以最後跑起來是沒差的。

對我來說，css selector 效能的問題可能就跟這個差不多，不過實際上的性能到底為何，還是要做過測試才敢下結論。

然後今天很 lag 的發現 bottender 的開發者也參戰了：使用 Modern Web 技術來打造 Chat App

06. [JS] 請你在旁邊的白板寫個快速排序演算法。裡面給的快速排序程式碼其實滿不錯的，雖然說不是 in-place 版本，但有把快排的精髓顯現出來。

話說 CSS 規範的版本和狀態怎麼看呢？，有篇文章能教大家讀 CSS 規範真棒。如果有人需要 rfc 的，這邊也有一篇：How to Read an RFC，之前路上撿到的。

今天原本是想要出門的，但中午要先洗個衣服，洗加烘就被綁住兩小時了
既然都被綁住了，就懶得出門了，想說在家耍廢好了，順便查一下明天去德國柏林的交通
所以今天一天就是毫無進度，等著明天去機場搭飛機
繼續看 kmp 的論文好了