- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Nov 2022 17:49:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] when to update the pseudo element styles`, and agreed to the following: * `RESOLVED: UA styles on the pseudo-DOM stay in sync with author DOM for any developer observable API` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [css-view-transitions-1] when to update the pseudo element styles<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7812<br> <fantasai> khush: Resolution in the last meeting, recap<br> <fantasai> khush: feature creates a pseudo-element which has snapshot and position from new DOM<br> <fantasai> khush: live, in sense that new DOM's painting changes will be reflecting<br> <fantasai> khush: also if position / layout changes, will be reflected<br> <fantasai> khush: keeping these two in sync requires step where we do layout on author DOM, and then generate a UA stylesheet<br> <fantasai> khush: do we conceptually see this UA style sheet generation as part of style resolution<br> <fantasai> khush: e.g. if author changes something about the DOM element, should they get those changes reflected in the pseudo-element if they query via script?<br> <fantasai> khush: or do we treat this as an explicit step that's part of the feature, and there's a specific point where we get these two things synced up<br> <fantasai> khush: last time we resolved on two explicit points<br> <fantasai> khush: this is only relevant if dev queries using script<br> <fantasai> khush: two options are:<br> <fantasai> khush: 1. Always keep in sync, treat as part of style resolution. If you call getComputedStyle(), we'll have to resolve style, generate styles and give an answer<br> <fantasai> khush: 2. Defined point on a frame, so you'll get stale data, whatever was computed in the last frame<br> <flackr> q+<br> <fantasai> khush: I think keeping in sync is more correct, but it's also harder because you have to do this loop to resolve style<br> <fantasai> khush: and we don't have a strong use case for why author would need this to always be in sync<br> <emilio> q+<br> <fantasai> khush: so my suggestion is go with 2 defined points where we do this step<br> <fantasai> khush: if they query after updating DOM, they'll get stale data<br> <fantasai> khush: and in the future if we want we can make it more correct<br> <fantasai> khush: so that all updates are guaranteed to reflect correctly<br> <Rossen_> ack flackr<br> <fantasai> flackr: My preference is for reflecting up to date values, because that's what will be presented on screen<br> <fantasai> flackr: so more consistent<br> <fantasai> flackr: we only have to do this if the author queries the style, so most of the time we won't be doing this extra style update<br> <Rossen_> ack emilio<br> <fantasai> emilio: what's the use case for querying these pseudo-elements, and is there a defined answer assuming can target elements in the pseudo tree?<br> <fantasai> emilio: can't you write selectors that match multiple of these elements?<br> <fantasai> khush: use case is developer customization, could use information about what the element's transform or size is<br> <fantasai> khush: can query existing API<br> <fantasai> khush: element's size will be its border-box size<br> <fantasai> khush: Some things not available now, e.g. ink overflow bounds<br> <fantasai> khush: unless we expose no API for it<br> <fantasai> khush: I don't have any strong use case, just a speculative maybe you want to do a funky animation thing<br> <fantasai> emilio: My point is there's no good answer, if you write ::part() and that something matches 2-3 elements, what does getComputedStyle return?<br> <Rossen_> q?<br> <fantasai> khush: getComputedStyle has option to query an exact pseudo-element, so you can pass ::view-transition-group(name) and get from that element<br> <fantasai> emilio: a pseudo-element selector can match multiple pseudo-elements, so is it well-defined what happens?<br> <fantasai> khush: Similar discussion for web animations API, if it matches multiple pseudo-elements, treat it like querySelector and return the first one<br> <fantasai> emilio: so well-defined, ok<br> <fantasai> emilio: if there's a good answer, then sure<br> <fantasai> emilio: I assume if it works for web animations, making it work for gcs also makes sense<br> <fantasai> khush: I think flackr mentioned he preferred if we get these in sync<br> <vmpstr> q+<br> <fantasai> khush: also my ideal preference, but would it be ok for implementation complexity if we didn't do that for now, and if a use case do it right later?<br> <fantasai> flackr: if you don't do that, values would always be a frame out of date<br> <fantasai> flackr: wouldn't be able to use them<br> <fantasai> khush: answer for first frame is correct<br> <fantasai> khush: after UA does consruction<br> <fantasai> khush: It's only if you change as part of RAF as part of ??<br> <fantasai> khush: We don't retarget animations now anyway, so you'll get visual jumps<br> <fantasai> flackr: I've seen authors do things in RAF every frame, to manually position other elements in response to frames<br> <Rossen_> ack vmpstr<br> <fantasai> vmpstr: My preference is not keeping it always up to date, it's because there's a distinction between keeping styles conceptually up to date<br> <fantasai> vmpstr: but this isn't technically style, but UA style sheet that needs to be updated<br> <fantasai> vmpstr: ensuring that these values are kept up to date as style is unnecessary, other than point flackr raised<br> <fantasai> vmpstr: so I would preferred to have a defined step and update rendering, this is when the stylesheet is updated to reflect DOM changes<br> <fantasai> vmpstr: reason is, from implementation perspective, we would have to force style and layout to get this information to put in stylesheet and it's a lot more forced work<br> <fantasai> vmpstr: seems a lot more rendering needs to be forced in these cases<br> <Rossen_> fantasai: why not both?<br> <fantasai> s/both/allow both/<br> <Rossen_> ack fantasai<br> <dholbert> fantasai: text wrapping<br> <fantasai> fantasai: make it a quality of implementation issue<br> <emilio> q+<br> <fantasai> fantasai: and if it becomes a problem, people can file bugs against the implementations<br> <flackr> sgtm to leave it up to implementer<br> <fantasai> fantasai: to improve their fidelity<br> <fantasai> khush: I think for wording, use "should"<br> <flackr> This is also similar to the way reading scroll position may be more or less out of sync on diff browsers<br> <khush> UA styles on the pseudo-DOM should stay in sync with author DOM for any developer observable API<br> <fantasai> emilio: I think this is quite different from text-wrapping, it's an API you're asking a question<br> <fantasai> emilio: I think we can't do hard thing if we do the hard thing if we do the easy thing at the beginning?<br> <fantasai> emilio: people will rely on whatever ansewr you give them<br> <dholbert> fantasai: but if you give them more accurate answers, would that be a problem?<br> <fantasai> emilio: maybe relying on perf characteristics<br> <fantasai> emilio: if in a loop, and then changing DOM, implicitly relying on existing behavior or else stuff becomes super slow<br> <fantasai> emilio: maybe I'm being too pessimistic...<br> <fantasai> emilio: my preference would be to define one answer<br> <fantasai> Rossen_: more correct and harder way?<br> <fantasai> emilio: Don't particularly care. Do understand the implementation complexity. Also don't see a lot of use cases for this to begin with<br> <fantasai> Rossen_: I want us to move forward here, take a resolution that's going to unblock us quicker<br> <flackr> I suppose if we do the easy thing first we can always try to change it to the more correct thing and consider the compat risk then<br> <fantasai> Rossen_: going back to original proposal, that was for the easier one which we can get to basically go to market quicker<br> <fantasai> Rossen_: get implementation experience and feedback, that's initial ask?<br> <fantasai> khush: That would be nicer, that said my proposal was on the assumption that this would be easy to change later<br> <fantasai> khush: that is, if we make API more correct we would not have a compat risk<br> <fantasai> khush: but if we have a compat risk, then I'm ok to do the harder thing first<br> <fantasai> Rossen_: from point of view of API and its evolution, taking scoped resolution here doesn't preclude us doing better later<br> <fantasai> Rossen_: our decisions today are open to improvement tomorrow<br> <fantasai> khush: I didn't quite follow, what are we resolving on?<br> <fantasai> Rossen_: the easier one<br> <fantasai> khush: Emilio was concerned changing later would be bad for compat<br> <fantasai> emilio: I think so<br> <fantasai> emilio: since these are relatively expensive updates<br> <fantasai> emilio: it's very easy to depend on not doing hard work<br> <fantasai> Rossen_: If I'm hearing, you want to do harder work now now<br> <fantasai> emilio: I don't mind which we choose, as long as we choose one<br> <fantasai> khush: If we have to make one choice right now, and given uncertaintly about valid use case, we prefer developer ease over implementer ease so we do harder thing first<br> <fantasai> emilio: No strong opinion on which one<br> <fantasai> emilio: my point is, I think if we start with easy one, we can't switch to hard one<br> <fantasai> emilio: not leave it up to UA or future<br> <fantasai> emilio: let's just decide what we want<br> <fantasai> emilio: I've no strong opinion, but khush seems to think harder one is better for devs<br> <khush> UA styles on the pseudo-DOM stay in sync with author DOM for any developer observable API<br> <fantasai> khush: proposal ^<br> <fantasai> RESOLVED: UA styles on the pseudo-DOM stay in sync with author DOM for any developer observable API<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7812#issuecomment-1309121830 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 November 2022 17:49:57 UTC