- From: Henri Sivonen via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 08:04:45 +0000
- To: public-css-archive@w3.org
Currently, parsing incompleteness is tracked only on a very small number of specific element types. What's proposed here would add a lot of "end tag seen" traffic from the parser to the DOM. Intuitively, that kind of added traffic has _some_ performance cost. I don't know how substantial the cost is. Intuitively, the cost is more in the Gecko architecture (off the main thread parsing) than in the WebKit or Blink architecture (on the main thread parsing). It would be good to quantify the perf cost of every element node gaining an "incomplete" bit and the parser flipping that bit for every element later on even when it's not connected to any further action (such as rematching selectors). (This isn't the first time that a feature that implies this added traffic from the parser to the DOM has been proposed. I now fail to remember what the previous proposal was, but it would be worthwhile to find it and see if anyone ended up quantifying this aspect in the context of WebKit or Blink. I'm pretty sure we didn't take the time to quantify it in the context of Gecko.) -- GitHub Notification of comment by hsivonen Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12578#issuecomment-3209456796 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 August 2025 08:04:46 UTC