- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Aug 2024 15:55:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Optionally capture some properties (e.g. opacity/border) as style instead of snapshot`, and agreed to the following: * `RESOLVED: Change the capture mode for all view-transitions and specify how each property is affected by this capture mode change` * `RESOLVED: Blink will experiment and come back with changes needed if there are compat concerns` <details><summary>The full IRC log of that discussion</summary> <bramus> noamr: biggest issue we want to discuss today<br> <bramus> … how we capture and display nested componets<br> <bramus> … but also applies to non-nested vt elements<br> <bramus> … derived frm the nested conversation<br> <bramus> … when we nest groups, some css properties that were previously not that important to capture are now very important because otherwise it looks broken<br> <bramus> … two groups<br> <bramus> … - tree effects like opacity, mask, clip-path, filters, perspective<br> <bramus> … these apply to entire tree<br> <bramus> … - borders and border-radius because once you have a hierarchy of groups and you have overflow then the overflow affects the origin where you draw the borders and shadows<br> <bramus> … these also paint after backgrounds<br> <bramus> … so it comes down to when doing just default capture, nesting is visually broken<br> <bramus> … but this also was something we discussed when vt started<br> <bramus> … that animating ?? directly looks better, e.g border and border-radius<br> <bramus> … than just capturing it as one image and cross-fading it<br> <bramus> … otoh we already shipped the old thing, so its a compatibility issue<br> <bramus> … we see three options<br> <bramus> … 1. change everything by default and dont just capture snapshot but add more things that get captured as ?? instead of a flat snapshot (opacity, filter, transform, bg borders, )<br> <bramus> … will change things because these styles are part of the group<br> <bramus> … but have changed things before (but this is different as it changes observable computed style)<br> <bramus> … 2. add new property `v-t-style` or `v-t-capture-mode`<br> <bramus> … fane of the first as it reminds me of `transform-style`<br> <bramus> … 3. to have this new property but give it auto value<br> <bramus> … if group contains other groups when you get the new mode<br> <bramus> … so users using nesting get the new mode<br> <bramus> … but can have a property to change the behavior<br> <khush> q?<br> <khush> q+<br> <astearns> q+<br> <bramus> … if people want the old crossfade behavior theycan always do so by regular DOM nesting<br> <astearns> ack khush<br> <bramus> khush: hoping we can split this in 2 resolutions<br> <bramus> … 1 on the new capture mode<br> <bramus> … and 2 to change the default or not<br> <bramus> q+<br> <bramus> astearns: confused about third option (adding current capture for non-nested but auto new nested for grouping without giving opt out)<br> <bramus> noamr: there is an opt out<br> <bramus> astearns: not entirely sure about backwards compat concern since we ar estill working on this<br> <bramus> … i’d have to have somebody look at the data<br> <bramus> … changing mode for non-grouped things seems OK if its better<br> <astearns> ack astearns<br> <astearns> ack bramus<br> <flackr> +1<br> <fantasai> scribe+<br> <fantasai> bramus: Yes, this would be breaking, but it would break in a good way<br> <fantasai> bramus: Regarding the name of the property, one of the values proposed is cross-fade, which is a value I wouldn't recommend<br> <fantasai> bramus: because authors can change the animation, e.g. to scale-up/scale-down, etc.<br> <noamr> q+<br> <fantasai> bramus: I would suggest a different name for the property, view-transition-capture-mode: flat | layered<br> <astearns> ack noamr<br> <bramus> noamr: fine with any type of bikeshedding<br> <bramus> … if we choose option 1 we dont need new property<br> <bramus> astearns: yet<br> <bramus> noamr: propably wouldnt need one<br> <bramus> … if we change default then optoin of using crossfade is always possible with nesting DOM<br> <khush> q+<br> <bramus> … defers the conversation about naming it<br> <astearns> ack khush<br> <bramus> khush: my vote is for option 1, is risky but can try it with a flag<br> <ntim> q+<br> <bramus> … one instance i have seen where it could break things, and partner let us know that they would welcome the change<br> <astearns> ack ntim<br> <bramus> ntim: is this changing by default for all capture modes or just nested ones?<br> <bramus> … i mean, nested or everything?<br> <bramus> noamr: option 1 is everything, option 3 only for groups<br> <bramus> … option 1 would be “breaking change” / modification to view transitions 1<br> <bramus> astearns: and option 3 would not be<br> <bramus> noamr: i proposed that one as i am very skiddish about backwards compat<br> <vmpstr> q+<br> <bramus> vmpstr: also supportive of option 1<br> <bramus> … future looking this mode seems to be strictly better in a lot of cases (e.g. border radius that animate instead of cross-fade)<br> <bramus> … one concern is breakages and specifically if Apple is also on board with making this change then we want to do this<br> <bramus> … want to avoid interop problem where blink switches modes and webkit doesnt<br> <bramus> … hard to feature detect<br> <bramus> … and sites would have to deal with two different modes<br> <bramus> … that is the biggest risk I see<br> <bramus> astearns: tim, do you have preference?<br> <bramus> ntim: dont know how fast if we can adopt this<br> <bramus> … guess if there is a compat concern it maybe is possible?<br> <bramus> … cant give definitive answer<br> <bramus> fantasai: we can reasonable say that if this is the direction to go we should … but cant commit to a timescale though<br> <bramus> noamr: there is some sentiment to 1 but I feel ppl need to think about this more?<br> <bramus> astearns: could resolve on option 1 and have blink try it out to see how much breakage there is<br> <bramus> … and if its manageable then we’re good and come back to this<br> <bramus> … would be resolving one 1 unless it’s not possible<br> <bramus> … i’d rather not define a new capture mode without a switch<br> <khush> q+<br> <vmpstr> q-<br> <bramus> ntim: do you know how much work this will be for you?<br> <bramus> noamr: I am prototyping it right now, can report back<br> <bramus> … doesnt seem like huge amount of work<br> <bramus> … mainly adding more things to list of captured props and not painting them when element is being captured<br> <bramus> ntim: OK<br> <astearns> ac khush<br> <astearns> ack khush<br> <bramus> khush: when we prototype we]ll find edge cases<br> <bramus> … we will take those back to the WG in that case<br> <bramus> … want to get this right<br> <bramus> noamr: it involves a lot of CSS props<br> <bramus> … some of them are captured and not painted, while others are painted<br> <flackr> q+<br> <bramus> … the ones specifically would all be specified<br> <astearns> ack flackr<br> <bramus> flackr: is it that we need a specific property list or is it that your children are captured as a painting and only props that affect the child dont matter instead of the box that is captured?<br> <bramus> noamr: depends on how handwavey we want to be<br> <bramus> … we would need WPTs<br> <bramus> flackr: just want to avoid situation where it is hard to guess<br> <vmpstr> q+<br> <bramus> noamr: there could be general wording plus exceptions<br> <bramus> astearns: as goes for specifying it should be about its characteristics so that it extends to new future properties<br> <astearns> ack vmpstr<br> <bramus> noamr: agreed<br> <bramus> vmpstr: agree as well<br> <bramus> … dont want to maintain a list of props for all eternity<br> <bramus> noamr: could we add it to a property descriptor?<br> <ntim> q+<br> <bramus> astearns: we have a lot of things in description tables … if we can avoid addig a field there I would prefer that<br> <astearns> ack ntim<br> <bramus> noamr: no strong opinion<br> <khush> q+<br> <bramus> ntim: from impl POV it would be good to have list well defined in some way. new field in prop table or whatever workds<br> <bramus> … to make sure impls dont miss things<br> <bramus> astearns: for most part weshould be able to define groups of props with some exceptions and then encode things in WPTs<br> <bramus> … having a list of props in the WPT seems better than in the spec<br> <astearns> ack khush<br> <bramus> khush: gonna second what ntim said<br> <vmpstr> q+<br> <bramus> … right now spec has UA stylesheet that is very well defined so there is no interop issue there<br> <bramus> … when having a property descriptor in the prop table makes it easier for interop too<br> <bramus> … e.g. animatable<br> <astearns> ack vmpstr<br> <bramus> … you dont miss it<br> <ntim> I'm also OK with the list being maintained into a WPT, it just needs to be maintained somewhere<br> <noamr> q+<br> <bramus> vmpstr: middle ground could be to define groups of props such as “clipping properties”<br> <bramus> … and props should add themselves to those groups<br> <astearns> ack noamr<br> <bramus> … that might be a nice middle ground, but that’s only a guess right now<br> <bramus> noamr: can have a default per spec<br> <bramus> … eg box shadow spec to include sth that says all the props work in one way or the other<br> <bramus> astearns: elika, do you have an idea?<br> <bramus> fantasai: like the idea of doing it per spec. will simplify thinking about it<br> <fantasai> https://www.w3.org/TR/css-backgrounds-3/#placement<br> <bramus> … other option to put it in propdef table<br> <bramus> … we current have a ?? so we could have a statement in one of those sections<br> <astearns> s/??/module interaction sections/<br> <bramus> s/??/some boilerplate text in module interactions<br> <bramus> … how x interacts with other modules<br> <bramus> … or “this also applies to first letter”<br> <bramus> … can add another paragraph for VTs<br> <bramus> astearns: how about we specify this in VTs with an explicit list to begin with and a note saying that this info needs to move to individual modules and module interaction section?<br> <bramus> fantasai: and if vt editors want to work on some PRs to update specs that need that section, that would be welcome in a single PR<br> <bramus> noamr: OK<br> <khush> q+<br> <bramus> fantasai: some specs are missind that section though, so youll need to add it<br> <bramus> khush: so is the conclusion we have an explicit list but it is define by each module?<br> <bramus> … it describes which group it belongs to, and then vt handles the group behvior<br> <astearns> ack khush<br> <khush> +1<br> <vmpstr> +1<br> <bramus> fantasai: yes, but at first you can have an explicity list in the vt spec and then later on group them<br> <fantasai> once you feel confident in your groupings/descriptions<br> <bramus> astearns: so propsed resolution is to change capture mode for all view-transitions and specify how each property is affected by this capture mode change<br> <bramus> … does that sound right?<br> <bramus> … astearns any concerns?<br> <bramus> bramus: should we also add that blink will experiemnt and come back with compat concerns?<br> <bramus> astearns: sounds good<br> <bramus> RESOLVED: Change the capture mode for all view-transitions and specify how each property is affected by this capture mode change<br> <bramus> RESOLVED: Blink will experiment and come back with changes needed if there are compat concerns<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10585#issuecomment-2302433008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 August 2024 15:55:43 UTC