15:02:10 RRSAgent has joined #css 15:02:14 logging to https://www.w3.org/2023/03/15-css-irc 15:02:14 present+ 15:02:14 RRSAgent, make logs Public 15:02:15 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:02:16 present+ 15:02:59 Present+ 15:03:24 gtalbot has left #css 15:03:53 emeyer has joined #css 15:04:08 ScribeNick: emeyer 15:04:11 castastrophe has joined #css 15:04:15 present+ 15:04:23 present+ 15:04:53 Topic: [css-view-transitions-1] Capturing fragmented elements 15:04:54 present+ 15:05:01 github: https://github.com/w3c/csswg-drafts/issues/8339 15:05:25 masonf has joined #css 15:05:29 present+ 15:05:35 present+ 15:05:55 JakeA: When an element is captured as part of a transition, we ignore all the transforms and then figure out what transforms we need to apply to place it correctly 15:06:15 …so if the transition is a 90 deg rotation, you get a rotating transition 15:06:44 …The columns case is particularly interesting because you can apply transitions across fragments, which transitions each fragment individually 15:07:03 …That’s not compatible with the View Transitions model, which we want to be a single image and single transform 15:07:22 …It’s unclear to us if View Transitions are desirable in fragmented cases 15:08:01 …Prior art indicated fragmented elements should be treated as if joined flush 15:08:30 …We looked at Firefox’s implementation; it seems to capture the union of the fragments before a transition is applied 15:08:31 TabAtkins: That’s per-spec 15:08:43 JakeA: Good to know Firefox is doing the right thing 15:09:05 khush: I was confused bewtween what old specs said and what Firefox does 15:09:17 TabAtkins: The capturing of dimensions is spec-compliant; other things may not be 15:09:35 JakeA: Trying to figure out View Transitions in this case 15:10:04 …Option 1: You Are Not Allowed; the captured element must not fragment, which means you skip to the end of the transition 15:10:43 futhark has joined #css 15:10:50 present+ 15:10:50 …Is a constraint broken when an element fragment, or if an element ever can fragment 15:11:18 …Previous resolutions have been that if a constraint can be broken, then the treatment is as if it has been broken 15:11:44 …If you’ve given a name a none-none value, should it prevent an element from being fragmented? 15:12:19 …Option 2: View Transition only applies to the first fragment; doesn’t seem useful, but could be done 15:13:06 …Option 3: Take a bit from the element() function and remove any transform from the elemenbt, figure out union of fragment quads, reapply transform to each fragment and capture image with that transform baked in 15:13:24 …Not sure if that’s useful, but it’s a non-failing treatment 15:13:25 q+ 15:13:37 …We’re stuck here. 15:13:42 ack vmpstr 15:13:43 q+ 15:13:48 present+ 15:13:49 gtalbot has joined #css 15:13:52 present+ 15:13:56 chris has joined #css 15:14:08 vmpstr: One of the constraints we have is that the element has a box, so we don’t check if the element can lose its box; we only care whether it has a box 15:14:39 …I prefer option 1, because as you said this adds a lot of complexity to both model and implementation 15:14:52 …I don]t think there are compelling use cases to transition a fragmented element 15:15:13 …You could work around by putting a box around the fragmented element 15:15:13 +1 to Vlad's comment. 15:15:15 ack TabAtkins 15:15:25 TabAtkins: I also think Option 1 is probably the right idea 15:15:26 +1 to not doing something complex if there aren't actual use cases for it. (I think that most strongly says "not Option 3".) 15:15:40 …none of the options are great, but I don’t think there is a good way to do it 15:16:06 …I think making thing with view transitions not-fragmentable makes sense 15:16:15 q+ to disagree with making non fragmentable 15:16:33 also disagree with making things non-fragmentable 15:16:36 present+ 15:16:45 fantasai: The problem is a people will apply this to a lot of elements and if you force things to be not-fragmentable they’ll break in print 15:17:09 …I would just not go down this path; the problem here is the combination o f fragmentation and transforms 15:17:26 …if you capture the bounding box and say this is a the view transition snapshot, that’s okay 15:17:56 ack dbaron 15:17:56 dbaron, you wanted to react to TabAtkins 15:18:12 dbaron: We seem to be focused on Tab’s variant of Jake’s option 1, not the original option 1 15:18:30 astearns: I think we’re agree Tab’s variant is Right Out 15:18:37 q- 15:18:53 ack fantasai 15:18:53 I'd be ok with that. Ignore the element if it fragments. 15:19:03 It feels a little unpredictable, but I think I'm okay with the "just don't VT if it's fragmenting" 15:19:10 q+ 15:19:14 q+ 15:19:23 q+ 15:19:24 fantasai: We could not transition when fragmented, or take the bounding box and transition the whole thing, which will interact weirdly with transforms 15:20:10 astearns: I’m fine with not transitioning view-fragmented things, but I’m concerned this is like other things we’ve punted for being too complicated and then never got back to 15:20:21 fantasai^: but would let you do simple transitions like translations or fades 15:20:38 …We already have the optoin to apply a view transition to multiple elements, so we could treat fragmented elements as if they created separate view transitions 15:21:11 JakeA: The difficulty there is how you’d address each fragment with CSS, and what do you do if the number of fragments changes 15:21:29 astearns: I wouldn’t expect being ablke to address each fragment directly 15:21:47 s/directly/directly, until we have fragment pseudos (which we have talked about)/ 15:21:51 …As in regular view transitions, if you have an element that appears in one state but not the other, it doesn’t participate 15:22:05 ack astearns 15:22:14 ACK florian 15:22:31 florian: I agree with dbaron and fantasi 15:22:55 lea has joined #css 15:23:09 …Another concern: a user agent that’s interactive but paginates is not common today, but there are things like e-readers that could do that, and we don’t want a model incompatible with that 15:23:17 q+ 15:23:36 …It’s hard to make a union of things that don’t share the same coordinate space, like columns 15:23:38 ack TabAtkins 15:23:57 TabAtkins: That union of non-oriented coordinate spaces is why element() stitches them together 15:24:22 …line-box-clamp could intersect with this; it’s at least fragmentation-adjacent 15:24:42 …I think option 2, transitioning the first fragment, is the best choice 15:24:53 q+ 15:24:57 …I think it’s better to get some of the element rather than none of the element during a transition 15:25:18 astearns: If we fragment the first box, we’ll find out if people want other fragments to transition 15:25:35 JakeA: Different transitions names for different fragments would be a nice way to address that 15:25:37 ack jensimmons 15:25:48 jensimmons: +1 to actually solving this and taking it seriously 15:26:11 …I can see a future where simple and elegant transitions make it so web sites use a lot of transitions to go between pages and even sites 15:27:02 +1 to solving both 15:27:10 present+ 15:27:17 "using overflow fragments to solve the regions use case" 15:27:38 …We also need to figure out overflow fragments to solve the Regions use case, and make ihs and view transitions work together 15:27:45 present+ 15:28:09 JakeA: I would worry that because we don]t know how the regions thing will work, we might pick a solution today that clashes 15:28:12 ack khush 15:28:44 khush: As an implementor, if we ignore a fragmented element, the fallback is you get a crossfade rather than a nice animation 15:29:14 …I think I prefer we either ignore the element if it’s fragmented, or we use the first fragment, I’d be okay with either 15:29:34 …Doing a union like element() does, we could try, but I really want to see how that pans out 15:30:03 ack fantasai 15:30:47 fantasai: If we take option 2 and go back to Alan’s idea, we could apply the same transition to all the fragments that is being applied to the first fragment 15:30:57 q+ 15:31:06 q+ 15:31:07 …In the future, we might be able to address each fragment individually, through something like :nth-fragment 15:31:22 …I think Alan’s proposal is the best going forward, but it’s not the easiest to implement 15:31:39 …We could start with first-fragment use, and leave the door open to individual-fragment later 15:31:39 ack khush 15:32:20 khush: I think the problem is the View Transition API has a way to address fragments individually 15:32:20 fantasai: The selector would select all of them 15:32:39 JakeA: We could ask for the devloper to give view transition names to each fragment, and we could ignore in the meantime 15:32:57 fantasai: The whole element has a name, and we could use :nth-fragment 15:33:00 ack vmpstr 15:33:22 ???: Would that mean the pseudo representing these elements is itself fragmented? 15:33:28 vmpstr: 15:33:33 fantasai: I’m not sure of the distrinction 15:33:52 vmpstr: So the new selector would select both, but they would be their own fragments? 15:34:35 JakeA: My understanding is if you give a name to an element, we’ll operate on the first fragment, but we can use :nth-fragment to address fragments? 15:34:48 dino7 has joined #css 15:35:03 fantasai: You can transition an
element, and then transition that element 15:35:13 …Each fragment gets snapshotted 15:35:30 JakeA: So what happens if you give an individual fragment a view transition name? 15:35:39 fantasai: I suppose you could do that 15:36:18 astearns: I like the idea of individually transitioning fragments, but don’t know if it’s useful to do before we have fragment pseudos 15:36:25 …That seems like the path forward 15:36:41 I think the ideal would be if you have an element that has n fragments transition to another element with n fragments it pairs them up? 15:36:53 …Not transitioning fragmented elements is a way of saying we’ll address this in the future, but don’t want to have a suboptimal solution now 15:36:58 JakeA: I like it 15:37:14 astearns: Any arguments that it would be better to transition the first fragment, rather than none? 15:37:18 (silence) 15:37:33 +1 15:37:34 sounds good 15:37:39 astearns: Proposed resolution is that if an element if fragmented into more than one element, it does not participate in View Transitions 15:38:04 RESOLVED: if an element if fragmented into more than one element, it does not participate in View Transitions (plus note that we want to do such things in the future) 15:38:16 Next one is easier... I hope. :P 15:38:30 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8548 15:38:30 Topic: [css-view-transitions-1] Define the constraints which must be satisfied by a named element during the transition 15:38:30 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8548. 15:39:45 A view-transition-name value that isn't none gives an element stacking context, grouping element, backdrop root, similar to non-1 opacity, as view transitions need these constraints. 15:39:45 JakeA: If you give an element a transition name that isn’t none, it acts as if opacity is not 1 15:39:51 s/Topic:/Subtopic:/ 15:39:53 s/Topic:/Subtopic:/ 15:40:04 i/Subtopic: [css-view-transitions-1] Capturing/Topic: View Transitions 15:40:10 I have made the request to generate https://www.w3.org/2023/03/15-css-minutes.html fantasai 15:40:25 …Name is only checked during transition, but because the new view is live, we need to check constraints per frame 15:40:26 Rossen_ has joined #css 15:40:32 jfkthame has joined #css 15:40:43 present+ 15:40:46 …If constraints are not satisfied mid-transition, element is dropped from the rest of the transition 15:40:46 present+ 15:41:03 …If an element isn’t rendered during setup, it’s ignored 15:41:19 …If an element becomes fragmented during transition, it’s dropped 15:41:27 …How do we check these conditions? 15:42:00 …Option 1: we assert extra conditions, then check to see if the view transition name is not none 15:42:17 …If a name ever becomes none, element is dropped 15:42:26 gtalbot has joined #css 15:42:28 Option 2: We assert these all individually, regardless of name 15:42:42 q+ 15:42:52 ack flackr 15:43:14 flackr: Option 3, if an element is undergoing view transition, it is subject to the constraints 15:43:24 I'd be ok with that. 15:43:33 JakeA: We can’t enforce rendering and we wouldn’t enforce fragmenting 15:43:39 +1 15:43:45 flackr: Right, we could continue to enforce name-based constraints 15:43:46 ack fantasai 15:43:50 TabAtkins: My preference as well 15:44:12 fantasai: That makes sense; other thought I had was if the name changes at all, I wouldn’t be surprised if the transition is suddenly dropped 15:44:42 JakeA: We avoided that because it means we can’t deal with elements that suddenly gain a transition name 15:45:01 fantasai: I’m not saying you’d start a new transition, I’m saying if someone messes with names, it should be dropped 15:45:27 JakeA: If a paragraph isn’t in a transition and halfway through JS gives it a name, should it be ignored? 15:45:50 …If we deal with every element changed names, then you have to check every frame 15:46:15 astearns: It sounds like Option 2, except names are kept throughout the transition and so need to be checked? 15:46:25 JakeA: I think people like flackr’s option 15:46:36 …I’m happy with that 15:46:38 +1 15:46:52 fantasai: Wouldn’t you also be enforcing that it’s not fragmented? 15:47:02 JakeA: We would skip the transition in that case 15:47:23 fantasai: What if a thing becomes fragmented partway through? Would you just ignore that? 15:47:38 JakeA: The new views are live and updated per frame 15:47:51 …If an element becomes not-renderable… 15:47:54 fantasai: I get it 15:47:59 astearns: Option3 15:49:09 If an element is involved in a transition, the ``view-transition-name` constraints are enforced during the transition 15:49:22 It's skipped if other constraints are broken 15:49:35 (eg rendering and now fragmenting) 15:49:53 RESOLVED: If an element is involved in a transition, the `view-transition-name` constraints are enforced during the transition 15:50:12 RESOLVED: Conditions are checked per-frame; transition is skipped if other constraints are broken 15:50:40 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8278 15:50:40 Topic: [css-view-transitions-1] UA CSS should size ::view-transition to 0x0 15:50:40 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8278. 15:50:46 s/Topic/Subtopic/ 15:50:58 https://github.com/w3c/csswg-drafts/issues/8278#issuecomment-1460153943 15:51:23 JakeA: Trying to decide default styles for the main pseudo-element 15:51:33 …It currently fills the snapshot root 15:51:52 …Use case one: rootless transitions 15:52:10 …By default we giive a name of root, but authors could change it to none 15:52:37 …Now when the transition runs, only components will be involved, but you can see the document beneath 15:52:50 …This is like a scoped transition, but it’s not quite a scoped transition 15:53:02 …I feel like this is rare and it will be more rare when we ship scoped transitions 15:53:19 Use case two: animating a view transition container and expecting it to move everything inside 15:53:46 Use case three: If you move your root view away, you might want to create a background for the rest of the area 15:54:02 Use case four: transitioning relative to the viewport 15:54:16 …We always go from top left, but in custom cases you might do something different 15:54:36 …I’ve done transitions to the center or bottom of the viewport 15:54:48 …So, the question is, what styles to give this by default. 15:55:10 …Option 1. It fills the viewport, which is great in all but the rootless use case 15:56:02 …Option 2. we do pointer-event: none to the transition and p-e: auto to the parts of the transition, so you can click the real DOM 15:56:25 …This is great except in cases where you fill in an opaque background; clicks will go through it 15:56:52 …Option 3: Make the transition element 0x0 in the top left, which breaks the ability to fill in the background 15:57:07 …Also break cases where you’re trying to position relative to places other than top left 15:57:15 …This feels like making the common things hard 15:57:19 q+ 15:57:35 …I think we’re in favor of option 1 15:57:44 q+ 15:57:51 ack TabAtkins 15:58:21 TabAtkins: I agree, I think option 1 is the right idea and is least restrictive, also fails in a way that’s safer than the other options 15:58:36 ack fantasai 15:58:39 ack flackr 15:58:42 q+ fantasai 15:58:57 flackr: I’m good with 1 or 3; 2 could override authors setting pointer-event on child elements 15:59:08 …We should add as few enforced UA styles as possible 15:59:08 ack fantasai 15:59:40 fantasai: Conclusion seems fine; have slight concern that positioning default is top left, rather than being writing-mode dependent 16:00:09 khush: That’s correct, spec says to place but doesn’t say how to compute 16:00:35 JakeA: I understand the writing mode concerns, but this should result in the same effect in the default case 16:00:48 PaulG has joined #css 16:00:53 fantasai: Should look into whether there are things that compete differently 16:01:04 astearns: We should have a separate issue about writing mode being considered 16:01:23 khush: We did have that, but then made it relative to the center of the containing block 16:01:34 …I’ll reopen that issue so we can get things into the spec 16:01:46 astearns: Sounds like we’re converging on option 1 16:01:47 +1 to this proposal 16:01:56 s/compete/compute/ 16:02:04 RESOLVED: The view transition fills the viewport and captures clicks 16:02:08 tantek has joined #css 16:03:30 topic: break 16:03:32 present+ 16:11:22 github-bot, take up https://github.com/w3c/csswg-drafts/issues/7797 16:11:22 Topic: [css-view-transitions-1] User input should be ignored when rendering is suppressed. 16:11:22 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7797. 16:11:22 https://github.com/w3c/csswg-drafts/issues/7797#issuecomment-1469931231 16:11:28 Jake's getting 'em all! :) 16:11:29 s/Topic/Subtopic/ 16:11:33 s/topic: break// 16:11:52 JakeA: During a transition, elements involved are hidden from the DOM 16:11:54 q 16:12:15 …That usually means every element is hidden, because the root element has a transition name 16:12:46 …Clicks during a transition will almost always hit the pseudo and fall to the document root 16:12:58 …Authors could change this by changing the root’s transition name to none 16:13:21 …Question is: what do we do with clicks while promises haven’t settled and the transition is frozen? 16:13:38 …Similar case: if you block the event loop using a while loop, it will block rendering 16:13:52 …If a user clicks anywhere, those events are queueing up 16:14:21 …Once the freeze is thawed, the events and hit tests and such are resolved then, which may resolve hits against things that moved 16:14:59 …We can’t do a full event block, but we could take from tasksources and then resolve when the transition starts 16:15:28 …Deadlocks are still possible in this option, which may also conflict with scoped transitions 16:15:44 …We don’t want to block all input events while scoped transition is happening 16:15:52 …Option 2: we apply all events to the document element 16:16:19 q+ 16:16:19 …In that case, a click may hit the document element whereas if we’d queued it, it might have hit a more specific element 16:16:22 q+ 16:16:25 +1 for option 2. 16:16:54 Rossen: I want to make sure we’re sticking to CSS 16:17:24 TabAtkins: +1 for option 2, which seems a little safer; also I hate when things resolve against DOM I wasn’t expecting; also makes things more predictable 16:17:24 ack TabAtkins 16:17:40 ack flackr 16:17:51 flackr: I think a common case is that by the time you’d dispatch the events in option 1, the elements will be where they should be 16:18:05 q+ 16:18:07 …Worried that we’re seen cases transitions to move small pieces of sub-documents 16:18:15 …I strongly prefer option 1 16:18:23 ack khush 16:18:32 bkardell_ has joined #css 16:18:44 khush: If we decide to buffer until rendering is done, the first question is do we dispatch before or after creating the pseudo-DOM? 16:18:57 …Why not just give it to the document? 16:18:59 present+ 16:19:35 JakeA: I think flackr’s point is that if you have a pseudo-element is in a certain place, option 2 raises the chances of a thing not being where it was when the click was made 16:20:07 khush: So this is for the case of rootless transitions? 16:20:23 JakeA: This is all about rootless transitions 16:20:43 flackr: If I start a transition on mousedown, as long as my pseudo is pointer-events: none, I can still get that click 16:21:03 …I also feel like you have a halting issue regardless, since there’s no requirement a transition ever finish 16:21:27 q+ 16:21:27 JakeA: Should have clarified that this deadlocks are already limited to four seconds 16:21:40 flackr: So this isn’t new, it’s just we could make them more likely 16:22:06 …If a developer doesn’t finish setting up for a view transition, there will be problems 16:22:59 chrishtr: With option 2, if the dev starts a transition but then does nothing and we wait four seconds, if the user clicks in that 4s window, is the click lost? 16:23:25 JakeA: Yeah, in option 2, the click won’t work 16:23:37 ack chrishtr 16:23:38 chrishtr: So the default UA behaviors are suppressed 16:23:44 q+ 16:24:06 flackr: In option 1, we wait for the transition to fail to start, the events are processed after the transition is canceled 16:24:57 chrishtr: Could we do an option 3 where user events are still processed and applied to the original target? 16:25:22 ack khush 16:25:41 khush: Option 1 is very hard to reason about with scoped transitions, whichis why I’m advocating option 2 16:26:04 …The easiest thing is to dispatch an event at the root of the subtree, 16:26:06 +1 16:26:12 ack khush 16:26:31 flackr: An event targeted at the document provdes XY coords, yes? 16:26:34 khush: Yes 16:27:06 Rossen: We seem to be sliding to option 2; flackr, you were the main proponent of 1 16:28:09 flackr: I like that option 2 supports scoped transitions better 16:28:26 …I think it’s okay 16:28:53 Rossen: Any other opinions or objections to resolved on option 2? 16:28:58 (silence) 16:29:24 Target pointer events to the document element 16:29:28 This is what will happen during the transition in most cases anyway, except in the edge case mentioned above, where the root's view-transition-name is set to none, and the clicks don't hit the pseudos. In that case, click may hit the document element, where they would hit a more specific element during the transition. 16:29:43 RESOLVED: target pointer events to the document element 16:29:57 Or to the root of the transition for future compat with scoped transitions! 16:30:13 Subtopic: [css-view-transitions-1] Define behaviour when capturing image for a large element. 16:30:18 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8561 16:30:18 emeyer, ignoring request to take up https://github.com/w3c/csswg-drafts/issues/8561 which is already the current github URL 16:30:49 JakeA: When we capture the content of an old view, we don’t know how it might be animated yet 16:31:01 …Part of the element might be out of view, and could come in view as part of the transition 16:31:16 …Some elements are very large and we can’t feasibly capture all of it 16:31:23 …Image transitioning the body element 16:31:58 …Proposal is, we’ll base the dimensions of the transition group on the element, but say that browsers don’t have to capture every pixel, while suggesting they capture beyond the viewport 16:32:14 …If possible/performant to do so 16:32:30 …Are we okay to handwave like that, so we let UAs act as they see best? 16:32:58 q+ 16:32:59 …Further, what should the natural width and height of the in- and out-states be when a browser chooses not to capture every pixels? 16:33:11 …Also, should those things be script-visible? 16:33:51 q+ 16:33:54 TabAtkins: I think we should require at least the visible area and some amount outside is good, maybe with a minimum explicit margin like 50% beyond 16:33:56 ack TabAtkins 16:34:17 …We should expose the size of the thing being captured 16:35:01 fantasai: +1 to Tab, plus the size should be the size it actually is, even if there isn’t painting inside the entire range 16:35:06 +1 16:35:19 …We should require or very strongly recommend capturing beyond the viewport as well 16:35:42 ack fantasai 16:36:05 JakeA: So if there’s a case with many elements layered on top of each other, they’re all in the viewport; if device can’t handle all that, should we just skip the transition? 16:36:26 …I think that’s a good general case, that if a UA doesn’t feel it can handle a given transition, it should skip the transition 16:37:21 s/as well/as well, probably +1 viewport in each direction as the minimum range to capture/ 16:37:21 khush: +1 to fantasai, which is kind of what I was implementing anyway, so I’m okay with the spec recommending taking the root as a barometer for how much to expand beyond the visible viewport 16:37:50 …The spec says the natural size of the image is equal to what you capture and everything around it is transparent 16:38:10 …object view box exposes how much the UA decided to paint 16:38:33 q+ 16:38:33 fantasai: I don’t think you should use object view box to set this, even if you use the same computation internally 16:38:49 khush: So the computed value is meant to be ink-overflow-rectangle 16:39:19 ack khush 16:39:23 chrishtr: We would just not raster things we can’t put into memory, so developers can’t observe anything about this behavior 16:39:29 fantasai: Exactly 16:39:33 +1 16:39:38 q? 16:39:55 JakeA: We can say the exposed value doesn’t say anything about optimizations 16:40:19 vmpstr: I think the object view box is the problem, because we need to make it the same as ink overflow, but if that’s infinite\ 16:40:39 flackr: It’s the same as if you hadn’t rendered everything 16:41:15 khush: In the spec it says to paint everything in the ink overflow rectangle 16:41:27 …We pretend an image is the size of the ink overflow rect 16:41:50 chrishtr: A dev wouldn’t know whether we painted the whole thing or not, only the user can tell 16:42:28 q+ 16:43:24 ack khush 16:43:44 khush: Base case where the UA can raster the whole thing, and element has drop shadow, so ink overflow is bigger than object box 16:43:50 q+ 16:44:18 …UA should compute a view box it applies to the element such that when you render this, the boxes should coincide at the same origin 16:44:50 …If the UA hasn’t painted the whole thing, and the dev msses with the object view box, the effect is the same as if the whole thing was painted 16:45:27 …My question is, to implement this, can we not let devs change object view box? 16:46:05 …When they read it, we can give the the value the spec wants; also the device specs wouldn’t be exposed? 16:46:08 q+ 16:46:25 fantasai: What is the ink overflow rectangle of something that has a box shadow? 16:46:41 chrishtr: There’s spec language about this 16:46:56 fantasai: Do we want to expose this? 16:47:13 q- 16:47:18 khush: You could call getcomputedstyle and don’t see anything, which would make implementation easier 16:47:36 fantasai: That seems better, and if the dev wants to manipulate they don’t have to know about the internals 16:47:56 chrishtr: We could take this and whether we should add a new !important to a new rule 16:48:16 fantasai: I think we agree the rasterization is not exposed to devs but the returned values are spec-consistent 16:48:28 ack chrishtr 16:48:55 proposal: UA can limit rasterization for perf limitations, but must size the element as if it was fully rasterized 16:49:23 chrishtr: Agreed 16:49:49 JakeA: I think we generally agreed the spec should suggest an overflow amount, was it one viewport in each direction? 16:49:56 proposal: rasterization should cover at least the visible area of the viewport + one viewport in each direction 16:50:05 JakeA: Also in out-of-memory cases the transition is skipped 16:50:15 proposal: if the UA cannot performantly perform the view transition (for any reason) it must skip the transition 16:50:22 TabAtkins: We don’t usually specify memory problem recovery because it can show up whenever 16:50:30 fantasai: I think we have three proposed resolutions 16:50:43 …One (see above) 16:50:48 Exception is if OOM actually causes a security issue. In all other cases OOM behavior is explicitly undefined. 16:51:00 …Two look one viewport in each direction for overflow handling 16:51:15 …Three is the error fallback is to skip the transition 16:51:23 q+ 16:51:43 …And that you never do half a transition, you either do all or none 16:52:07 khush: One viewport in each direction should be a recommendation rather than a requirement 16:52:20 …Only requirement is that what’s visible must be captured 16:52:40 proposal: UA can limit rasterization for perf limitations, but must size the element as if it was fully rasterized 16:52:43 proposal: if the UA cannot performantly perform the view transition (for any reason) it must skip the transition 16:52:49 proposal: rasterization should cover at least the visible area of the viewport + one viewport in each direction 16:53:07 RESOLVED: user agent can limit rasterization for performance limitations, but must size the element as if it was fully rasterized 16:53:46 proposal: Must: rasterization should cover at least the visible area of the viewport Should: + one viewport in each direction 16:54:50 proposal: Must: rasterization should cover at least the visible area of the viewport 16:54:51 must + should = ? 16:55:18 proposal: Must: rasterization covers at least the visible area of the viewport 16:55:43 RESOLVED: rasterization must cover at least the visible area of the viewport 16:56:32 JakeA: We need to consider the directions and how much overflow SHOULD be captured async 16:56:45 q+ 16:56:48 fremy has joined #css 16:57:11 ack khush 16:57:34 I think no 16:57:38 flackr: Skipping the transition is dev-visible so we’re exposing device capabilities 16:58:18 fantasai: You can limit rasterization but if you’re getting to the point you can’t even transition what’s on-screen, you should skip the whole thing 16:58:21 q+ 16:58:31 ack bkardell_ 16:58:34 flackr: We could not paint the transition but still run it so the dev knows it happened 16:59:37 bkardell_: You’re saying skipping the transition is dev-visible but is it? Because a device can just not support that or animations can be turned off with prefers-reduced-motion 16:59:54 Jake:We’ve decided those can be exposed, but giving away GPU memory is a fingerprint 17:00:06 bkardell_: I see 17:00:20 khush: Is it safer to say that this should silently fail by not painting things? 17:00:45 …We can already hit this with filters and blurs and such and that’s silent in Chrome 17:01:13 JakeA: I think we have to go back and come up with a plan here 17:01:24 Rossen: So we’ll have to postpone this resolution 17:02:18 topic: end_of_meeting 17:02:33 s/I see/So, are saying you could do something like try a _small_ transition and then kind of scale them up until it fails and then fingerprint with that? I see. 17:02:52 Zakim, end meeting 17:02:52 As of this point the attendees have been ydaniv, flackr, rachelandrew, miriam, JakeA, emilio, dbaron, castastrophe, emeyer, dholbert, vmpstr, masonf, futhark, jensimmons, fantasai, 17:02:55 ... chris, chrishtr, lea, jfkthame, Rossen_, PaulG, bkardell_ 17:02:55 RRSAgent, please draft minutes v2 17:02:56 I have made the request to generate https://www.w3.org/2023/03/15-css-minutes.html Zakim 17:03:02 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 17:03:02 Zakim has left #css 17:03:20 emeyer has left #css