- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Aug 2022 14:24:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Batching and flushing of style/layout info`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Batching and flushing of style/layout info<br> <fantasai> s/statuses/ready-to-ship list/<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/5115<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/5115<br> <TabAtkins> Rossen_: this was brought up as part of a longstanding TAG review of the html event loop<br> <TabAtkins> Rossen_: as we looked at last week's TAG f2f, Tess and I were looking over all the issues, what was discussed between whatwg and tag and here<br> <TabAtkins> Rossen_: This was the most relevant issue, defining when styles are batched and flushed<br> <TabAtkins> Rossen_: wanted to bring it up to the WG to review<br> <TabAtkins> Rossen_: For us to encourage and define how batching/flushing takes place<br> <Rossen_> q?<br> <TabAtkins> Rossen_: I was hoping to hear from tab or dbaron or emilio on this topi<br> <fantasai> TabAtkins: My conclusion is, as I commented in the thread, knowing exactly how and where styles et batched and flushed is something that I do not know very well<br> <fantasai> TabAtkins: and I don't anticipate other authors knowing either<br> <fantasai> TabAtkins: So we should make this implicit, with as minimal manual effort as possible<br> <fantasai> TabAtkins: Anywhere we leave it up to authors, it will inevitably get messed up<br> <Rossen_> ack dbaron<br> <fantasai> dbaron: I think my original suggestion was pretty wrong<br> <fantasai> dbaron: I think the question is it's not entirely clear to me what the right thin to do about it is<br> <fantasai> dbaron: I think one possibility is that we might be able to write some wording that says, the following steps happen whenever X happens, unless explicitly specified otherwise<br> <fantasai> dbaron: the question is whether we can write that clearly enough that it's actually correct<br> <fantasai> dbaron: because there may be places, there are algorithms like interesctionobserver and resizingobserver<br> <ChrisLilley> q+<br> <fantasai> dbaron: that would need to say something explicitly<br> <fantasai> dbaron: What's not clear to me is whether other algorithms need to say something explicit<br> <fantasai> dbaron: needs someone to sit down and spend a few days trying to figure it out<br> <fantasai> dbaron: I've been intending to do since filing the issue<br> <fantasai> dbaron: Given that, I shouldn't maybe make any promises<br> <emilio> q+<br> <fantasai> dbaron: it's quite substantive<br> <Rossen_> ack ChrisLilley<br> <fantasai> ChrisLilley: Happens whenever is insufficiently precise<br> <fantasai> ChrisLilley: it has to happen immediately before or immediately after<br> <fantasai> dbaron: I meant that<br> <fantasai> emilio: I wanted to say, this problem has gotten more complicated than it needs to be<br> <fantasai> emilio: due to some new features<br> <fantasai> emilio: This containment feature, content-visibility<br> <fantasai> emilio: Prevents flashing of style and layout in some cases, in some subtrees<br> <fantasai> emilio: display-locking<br> <fantasai> emilio: and same for a bunch of other APIs<br> <fantasai> emilio: getComputedStyle, updating style on the element you're queryign<br> <fantasai> emilio: can cause potentially visible side-effect, e.g. not updating transitions in other parts of the page<br> <fantasai> emilio: very trick<br> <Rossen_> q?<br> <Rossen_> ack emilio<br> <fantasai> emilio: defining precisely when an element does style updates, I don't think it's possible<br> <fantasai> emilio: ...<br> <fantasai> emilio: It's not a great spot to be in<br> <dbaron> s/I meant that/I meant before/<br> <fantasai> Rossen_: Just to drive this forward<br> <fantasai> Rossen_: One way is for us to undefine this, and precisely channeling a little of what Tab was saying, is to say this is not to be defined<br> <fantasai> Rossen_: and move on<br> <fantasai> Rossen_: which would allow at least us in TAG to close the event loop issue<br> <fantasai> Rossen_: and say we don't have a well-specified event loop<br> <fantasai> Rossen_: which most of the platform depends on<br> <fantasai> Rossen_: but you get what you get<br> <fantasai> Rossen_: that's an unsatisfying place to be in<br> <fantasai> Rossen_: I think authors, both feature authors and spec authors, would like a bit more specificity or visibility into at least what would cause a forced flush<br> <fantasai> Rossen_: if we can define some of the really big landmines that ought to be avoided if possible<br> <fantasai> Rossen_: that would be a good step in the right direction<br> <fantasai> Rossen_: so at least as ppl add their ??, they might not get a clear picture of batching<br> <fantasai> Rossen_: but if you get a place when forcing flush<br> <fantasai> Rossen_: can avoid it<br> <fantasai> Rossen_: We can't currently do that<br> <fantasai> Rossen_: ...<br> <fantasai> Rossen_: If we can't get to that sort of granularity, at that abstract level<br> <fantasai> Rossen_: that's unsatisfying state to be in<br> <fantasai> emilio: Might be useful to get all the engines to gether, see what the different optimizations are, and see if we can come up with a way to define a minimum common denominator that we can all agree on<br> <fantasai> emilio: Then there's also the work of going through all the APIs<br> <fantasai> emilio: but hopefully getting tricky parts agreed on can help<br> <fantasai> emilio: I agree that it's really unfortunate if we don't end up having it consistently applying<br> <fantasai> Rossen_: Emilio, can you organize this?<br> <fantasai> emilio: I can try. Between me and dbaron maybe we can get it done<br> <fantasai> Rossen_: OK, so this is a good point to take a break<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5115#issuecomment-1201275976 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 August 2022 14:24:16 UTC