14:57:11 <RRSAgent> RRSAgent has joined #css
14:57:15 <RRSAgent> logging to https://www.w3.org/2024/05/08-css-irc
14:57:15 <Zakim> RRSAgent, make logs Public
14:57:16 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:00:12 <jarhar> jarhar has joined #css
15:00:38 <kizu> kizu has joined #css
15:01:46 <davidleininger> davidleininger has joined #css
15:01:53 <akeerthi> akeerthi has joined #css
15:02:08 <dbaron> Meeting: OpenUI-WHATWG/HTML-CSSWG meeting
15:02:12 <dbaron> Present+
15:02:15 <flackr> present+
15:02:24 <davidleininger> present+
15:03:23 <hdv> present+
15:03:26 <lea> lea has joined #css
15:03:32 <gregwhitworth> present+
15:03:53 <masonf> masonf has joined #css
15:07:23 <kizu> present+
15:08:00 <gregwhitworth> q?
15:13:02 <jensimmons> jensimmons has joined #css
15:13:03 <chrishtr> present+
15:13:08 <keithamus> present+
15:13:08 <jensimmons> present+
15:14:16 <akeerthi> present+
15:14:19 <fantasai> present+
15:18:31 <masonf> present+
15:19:20 <lea> present+
15:21:58 <smaug> present+
15:21:58 <dandclark> present+
15:22:03 <Luke> Luke has joined #css
15:22:03 <fantasai> scribenick: fantasai
15:22:08 <hdv> scribenick: hdv
15:22:39 <una> una has joined #css
15:22:45 <masonf> hdv is OpenUI's version of fantasai, in terms of scribing. :-)
15:22:46 <una> present+
15:22:50 <TabAtkins> present+
15:23:11 <jarhar> present+
15:23:46 <jarhar> https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf
15:24:13 <dbaron> Topic: presentation on styleable <select>
15:24:15 <JonDavis> JonDavis has joined #css
15:24:23 <fantasai> slides: https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf
15:24:35 <JonDavis> present+
15:27:28 <RRSAgent> I have made the request to generate https://www.w3.org/2024/05/08-css-minutes.html fantasai
15:27:55 <emilio> q+
15:29:48 <astearns> ack emilio
15:30:17 <lea> q?
15:30:20 <lea> q+
15:30:25 <jensimmons> jensimmons has joined #css
15:30:28 <hdv> emilio: you mentioned having interoperable keyboard behavior… I don't mind one way or another, but wonder… behaviours are quite diffferent between platforms
15:30:29 <masonf> q+
15:30:56 <hdv> emilio: is having completely standardised keyboard behaviour across platforms worth pursuing?
15:31:24 <hdv> jarhar: this point hasn't been discussed a lot… the idea of trying to converge the behaviours came up at Open UI
15:31:30 <astearns> ack lea
15:31:38 <hdv> s/behaviour/behaviour in addition to styling
15:31:59 <hdv> lea: was the datalist wrapper added because of web compat issues?
15:32:01 <hdv> jarhar: yes
15:32:02 <jensimmons> q+
15:32:03 <astearns> ack masonf
15:32:34 <hdv> masonf: emilio, we should definitely talk about the keyboard behaviours, it was brought up at Open UI because of accessibility issues with having differences between platforms
15:32:34 <astearns> ack jensimmons
15:32:38 <jarhar> issue for html parser changes: https://github.com/whatwg/html/issues/10310
15:32:50 <hdv> jensimmons: can you explain the thinking behind using appearance:base-select rather than a generic appearance base?
15:33:04 <hdv> jarhar: yes, it was one of the points of feedback in the first agenda item
15:33:11 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/5998
15:33:11 <github-bot> Topic: [css-ui] appearance: base to enable interoperable styling of controls/components
15:33:11 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5998.
15:33:13 <ydaniv> ydaniv has joined #css
15:33:18 <hdv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/5998
15:33:18 <github-bot> hdv, ignoring request to take up https://github.com/w3c/csswg-drafts/issues/5998 which is already the current github URL
15:33:25 <ydaniv> present+
15:33:27 <hdv> jensimmons: can you explain the thinking behind using appearance:base-select rather than a generic appearance base?
15:33:31 <hdv> jarhar: yes, it was one of the points of feedback in the first agenda item
15:34:04 <hdv> jarhar: one of the points was that it would have forward compat issues, so when we ship the new thing we would break websites
15:34:20 <hdv> jarhar: would be happy to make a bikeshedding issue for this so that we can choose a name
15:34:31 <florian> q+
15:34:33 <TabAtkins> Yeah, this was proposed by the csswg in a previous discussion
15:34:44 <hdv> jensimmons: feels like there is a larger conversation that needs to happen around the strategy, to make big high level decisions, to avoid spaghetti 5 years from now
15:34:56 <emilio> q+
15:34:59 <TabAtkins> The forward compat concern is very real
15:35:23 <hdv> dbaron: in this case we ended up with base-select because of thinking about the future, to try and keep an obstacle out of the way
15:35:35 <astearns> ack florian
15:36:28 <lea> q+
15:36:39 <hdv> florian: I see the forward compat issue with just using `base`… but there is also a different problem with using `base-select`, what about telling other elements that they are a `base-select`?
15:36:46 <hdv> florian: last time we discussed something like that in CSSWG
15:36:58 <TabAtkins> q+ to answer the base-select on wrong elements question
15:37:04 <hdv> florian: I think we talked about it would be useful, but as its own value so that it would not be overly generic or specific
15:37:16 <hdv> florian: so why should this be a CSS property rather than an attribute?
15:37:17 <jensimmons> Are the slides Joey presented available online?
15:37:36 <chrishtr> jensimmons: Joey posted a link to it earlier in this irc chat
15:37:39 <TabAtkins> jensimmons: yes, linked at the beginning of the call
15:39:00 <hdv> jarhar: I've started implementing this. Thing is we can't modify DOM based on computed style, so I was able to do everything in layout
15:39:37 <hdv> jarhar: someone on my style theme existed we could have something like the light and dark function, but then appearance auto vs base, and that seems to work
15:39:45 <lea> q-
15:39:53 <florian> q+
15:39:56 <hdv> jarhar: third point, if we make it appearance base there is forward compat issue, and with base-selectw we avoid that
15:40:28 <astearns> ack emilio
15:40:30 <jensimmons> q+
15:40:32 <TabAtkins> ack TabAtkins
15:40:33 <Zakim> TabAtkins, you wanted to answer the base-select on wrong elements question
15:40:53 <hdv> emilio: to play devil's advocate re base-select being too specific… there are various already existing bits where this happens. If we get to the future where all form controls have their own appearance:base-something we could in theory introduce appearance base
15:41:10 <hdv> emilio: so we could see base-select as an in between step
15:41:21 <chrishtr> q+
15:41:28 <hdv> emilio: I don't feel too bad about the appearance-something approach
15:41:35 <TabAtkins> Yup, I was gonna say exactly what Emilio is saying here, if used in the wrong elements it'll just act like auto
15:41:59 <una> Agree - we can always limit base-select to select elements
15:42:04 <astearns> ack florian
15:42:07 <hdv> emilio: don't think implementing is somewhat tricky to add something for each form control but it should be fine
15:42:14 <jarhar> the -internal-appearance-auto-base() as ive implemented it is only for two properties
15:42:24 <hdv> florian: I think you made a reasonable on why it is doable to do it in CSS, but why is it preferable?
15:43:09 <hdv> florian: re that it is already the case for some properties… yes, but it goes against the design principles, the concluded we needed none and auto and nothing else
15:43:25 <hdv> florian: so native mode or non native mode would be what this flips between
15:43:28 <jarhar> q?
15:44:05 <hdv> florian: final point of consideration: CSS is primarily used with HTML, but not only with HTML, so other languages that are not HTML would need to define what these form controls are, seems less great if this would only work on HTML
15:44:54 <hdv> jarhar: I brought the HTML optin to WHATWG, there is pretty strong pushback by the editors
15:45:11 <akeerthi> q+
15:45:12 <hdv> jarhar: it does seem to have nice developer ergonomics and get the ability to style it with CSS.
15:45:38 <hdv> chrishtr: another argument was made, since it's really just about the styling it would be good to put it in CSS, it's not about behaviours, it is about styling
15:45:39 <keithamus> q+
15:45:43 <TabAtkins> Re: coupling, while we don't do it *a lot*, we do have a number of SVG-specific properties already.
15:45:45 <astearns> ack jensimmons
15:45:46 <chrishtr> q-
15:46:08 <hdv> jensimmons: how much does the state switching affect the functionality of the form control vs how much does it affect styling?
15:46:37 <florian> qq+
15:46:41 <hdv> jarhar: interoperable keyboard behaviour may be part of this, not sure if that is considered functionality
15:46:48 <florian> q-
15:46:59 <ydaniv> ydaniv has joined #css
15:46:59 <hdv> jensimmons: sounds like you're thinking that with the change, other markup can be put in select, whereas without the change that markup doesn't have the same behaviour inside of select?
15:47:11 <hdv> jarhar: the native picker could use markup to try and add stuff
15:47:43 <hdv> jarhar: one idea was that you could put images inside of options, that still works in the appearance auto mode
15:48:13 <gregwhitworth> q+
15:48:28 <florian> +1 to jensimmons
15:48:41 <hdv> jensimmons: seems like the sense is, we want to do a lot of things with select, so we add the ability to add any HTML… so we need some kind of toggle to specify the New Thing is being used. But it's unclear then if that New Thing introduces new behaviour
15:48:53 <hdv> jensimmons: eg what if the CSS doesn't load?
15:49:10 <hdv> jensimmons: am thinking… maybe we don't need a big toggle switch to enable the behaviour?
15:49:41 <hdv> chrishtr: jarhar did think about these things…the prototype he mentioned earlier did implement these things
15:50:08 <astearns> zakim, close queue
15:50:08 <Zakim> ok, astearns, the speaker queue is closed
15:50:33 <hdv> masonf: Anne's point seems to be… most of these things are behaviours and it would not be safe (from privacy/security pov) to allow arbitrary content to pop over
15:50:37 <hdv> emilio: not in Firefox
15:50:54 <hdv> masonf: sorry, meant to say in Chromium
15:51:16 <emilio> s/not in Firefox/Firefox restricts the select area to the top level viewport to avoid this kind of spoofing attack
15:51:27 <hdv> masonf: so the point is that moving between old and new mode with a switch in HTML is that it would need to be done piece by piece, CSS switch would make that easier
15:51:42 <hdv> jensimmons: are you assuming we should have `base-*` for each individual form control?
15:51:52 <hdv> jarhar: yes
15:52:14 <hdv> chrishtr: and then in the future we could introduce `base` as a shortcut so that authors don't need to worry about it
15:52:16 <florian> q+
15:52:28 <lea> q?
15:52:38 <hdv> chrishtr: we want to avoid people using `base` to get the hot new stuff, but then opting in to all the things, including things they don't want
15:52:38 <astearns> ack akeerthi
15:52:46 <lea> q+
15:53:00 <astearns> ack keithamus
15:53:02 <gregwhitworth> ack gregwhitworth
15:53:02 <hdv> aditya: if we're using an attribute authors would need to specify that attribute everywhere in their HTML, would be easier to apply it to all your controls with one property
15:53:09 <hdv> keithamus: that was one of Anne's points as well
15:53:49 <hdv> keithamus: to try and represent Anne's opinions… markup represents the data structures, but not necessarily the UI… so if you put a button inside of an option would that button's text content represent the options content?
15:54:31 <astearns> ack fantasai
15:54:32 <hdv> keithamus: to answer jensimmons's question… a lot of the markup stuff would be ported as good as we can to 'old' `<select>`… `appearance: base-*` would be to turn off all the styling but not as agressively as `none`
15:55:02 <florian> q+
15:55:10 <hdv> fantasai: to the extent this is about largely styling… to have one appearance base I think I agree with florian would be best to not do that
15:55:30 <flackr> q+
15:55:53 <hdv> fantasai: it would be nice if we could look into how appearance base could work for all form controls, so that we could try and ship it as one thing rather than creating all the individual ones, which would be more complicated to learn for folks
15:56:08 <hdv> fantasai: that might require a bit more work, but if we can manage to get it to work it would be better to try and do that
15:56:09 <TabAtkins> Note that this is the same thing we did with reading order, for similar reasons
15:56:11 <gtalbot> gtalbot has joined #css
15:56:46 <TabAtkins> I don't think it's possible, fundamentally, to have "base" work while we haven't designed the behavior on everything else.
15:56:59 <TabAtkins> *especially* the moment we start doing the input types.
15:57:21 <hdv> astearns: I realise we didn't start with 'what we want to get out of this', jarhar what would you like out of this for next time?
15:57:30 <hdv> jarhar: @@@
15:57:30 <masonf> I think redesigning all of the form controls is a bit more than "a bit more work".
15:57:33 <jensimmons> I really appreciate the history meeting mode – especially since much of this work has been done previously inside one or two companies. I am glad to be able to catch up and hear where the discussion is at now.
15:57:40 <gregwhitworth> +1 masonf
15:57:44 <hdv> astearns: let's have a summary comment in the issue next time so that folsk can review
15:57:51 <dbaron> I think one of the underlying issues here is that we have CSS discussions that say "X does not belong in CSS" and WHATWG discussions that say "Y does not belong in HTML" and we need to use some of this meeting sorting out that there isn't overlap between X and Y. :-)
15:57:51 <hdv> s/folsk/folks
15:58:06 <masonf> Much of the work has been done in the open in OpenUI, not within a few companies.
15:58:48 <hdv> jensimmons: do feel it was useful to have a history mode meeting this time, and can be more practical next
15:58:53 <hdv> chrishtr: +1
15:59:07 <jarhar> the @@@ was "i would like to get agreement that we should use css, whatever property or value, to opt in to the new mode instead of html"
15:59:19 <hdv> s/@@@/i would like to get agreement that we should use css, whatever property or value, to opt in to the new mode instead of html
15:59:20 <una> +1
15:59:43 <PaulG> PaulG has joined #css
15:59:47 <khush> khush has joined #css
15:59:50 <schenney> schenney has joined #css
15:59:57 <hdv> astearns: we're out of time, but will start scheduling these regularly
16:00:38 <dbaron> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:41 <kbabbitt> kbabbitt has joined #css
16:00:49 <kbabbitt> present+
16:00:54 <JaseW> present+
16:01:18 <bts_> bts_ has joined #css
16:01:26 <bts> bts has joined #css
16:01:58 <PaulG> PaulG has joined #css
16:02:09 <lea> present+
16:02:11 <bts> present+
16:02:14 <ethanjv> ethanjv has joined #css
16:02:32 <bramus> present+
16:02:48 <khush> present+
16:03:02 <schenney> present+
16:03:07 <fantasai> scribenick: fantasai
16:03:14 <alisonmaher> alisonmaher has joined #css
16:03:17 <bradk> bradk has joined #css
16:03:22 <alisonmaher> present+
16:03:27 <jensimmons> present+
16:03:34 <jfkthame> jfkthame has joined #css
16:03:49 <ydaniv> present+
16:03:51 <astearns> astearns has changed the topic to: agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0005.html
16:03:54 <vmpstr> present+
16:03:57 <jfkthame> present+
16:03:59 <dbaron> Present+
16:04:00 <florian> present+
16:04:00 <emilio> present+
16:04:03 <bradk> present+
16:04:04 <rachelandrew> present+
16:04:05 <fantasai> Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0005.html
16:04:08 <flackr> present+
16:04:20 <fantasai> Topic: View Transitions
16:04:26 <github-bot> Subtopic: [css-view-transitions-1] Should view transition names be tree scoped?
16:04:32 <khush> present+
16:04:37 <kbabbitt> present+
16:05:18 <fantasai> khush: Spec currently traverses all DOM elements, including those in shadow DOM
16:05:26 <fantasai> khush: Suggestion is to limit to tree-scoped
16:05:38 <TabAtkins> +1 to this
16:05:53 <fantasai> khush: so this would exclude things in shadow DOM
16:06:11 <fantasai> astearns: I've written some tests for tree-scoping, btw, and interop is terrible
16:06:46 <fantasai> khush: Are you talking about other features that are similar?
16:07:06 <fantasai> astearns: Yeah, I did @property rules and @xxx rules, which are supposed to be tree-scoped, and they're not handled correctly
16:07:20 <astearns> zakim, open queue
16:07:20 <Zakim> ok, astearns, the speaker queue is open
16:07:21 <fantasai> astearns: so probably some other things are also broken
16:07:56 <matthieud> matthieud has joined #css
16:07:56 <emilio> fantasai: two things, khush does this mean that for v-t that you'll never be doing transitions on anything in the shadow dom?
16:08:15 <emilio> khush: yeah this means that you couldn't use something inside the shadow dom as an independent thing
16:08:19 <kizu> q+
16:08:34 <emilio> ... scoped transitions would allow you to do that
16:08:51 <bkardell_> bkardell_ has joined #css
16:08:51 <emilio> ... but only as a unit inside the DOM
16:09:04 <bkardell_> present+
16:09:07 <emilio> fantasai: to alan, there's two different kinds of scoping, at-rules and name defining
16:09:20 <emilio> ... those are quite different mechanism
16:09:32 <astearns> ack kizu
16:09:34 <fantasai> s/defining/defining on elements/
16:09:35 <emilio> ... I'd expect less issues with things like timeline scopes and so on
16:09:50 <fantasai> kizu: Wrt other scoping things, we also have timeline-scope and anchor-name
16:10:13 <fantasai> kizu: Might want to have a way to expose these names, since might have cases where you want to expose
16:10:14 <pdr> pdr has joined #css
16:10:29 <khush> q+
16:10:36 <fantasai> kizu: maybe this is a more general issue that we need to handle in CSS, and have it work consistently
16:10:37 <astearns> ack khush
16:10:47 <TabAtkins> +1, we need a general mechanic for weakening shadow encapsulation
16:10:56 <TabAtkins> But we should be consistent for now
16:10:58 <fantasai> khush: kizu's point reminds me of ::part(), could use CSS to expose names from within shadow DOM outside it
16:11:01 <kbabbitt> kbabbitt has joined #css
16:11:12 <fantasai> khush: maybe if you expose the element could allow it to match
16:11:21 <fantasai> khush: could make it more complicated to implement
16:11:37 <fantasai> khush: we already have things in the platform that allow such information, in those cases do you want naming in CSS to also be exposed?
16:11:51 <fantasai> astearns: That would be a separate feature, though. This is for default behavior for view transitions
16:12:08 <fantasai> khush: Does it make sense to make this resolution cover other cases also? Have a general principle
16:12:22 <fantasai> astearns: I think a separate issue on general mechanism, because we do want to consider them all
16:12:31 <fantasai> astearns: don't want to have a specific escape route just for VT
16:12:54 <TabAtkins> Agree, separate issues
16:13:26 <fantasai> RESOLVED: view-transition-name lookup is tree-scoped
16:13:42 <bradk> bradk has joined #css
16:13:42 <github-bot> Subtopic: [css-view-transitions-1] Handle startVT for offscreen iframes
16:14:03 <TabAtkins> Khush, ping me with any difficulties or for review
16:14:46 <fantasai> khush: optimization that if an iframe is off-screen, we don't run lifecycle updates or slow them down
16:14:59 <fantasai> khush: So as an optimization, offscreen doesn't get animated
16:15:08 <fantasai> khush: During view transitions, looking for that refresh
16:15:15 <fantasai> khush: but for iframe won't refresh until iframe comes on screen
16:15:26 <fantasai> khush: given it's already off-screen, user isn't going to see any animation
16:15:36 <fantasai> khush: so suggestion that if it's offscreen, treat it as invisible
16:15:45 <fantasai> khush: or if iframe is detached from tree
16:15:51 <fantasai> khush: current spec is to skip the transition
16:16:00 <fantasai> khush: just update the DOM directly, since user won't see the animation anyway
16:16:14 <fantasai> khush: Question here is, what if iframe is not detached, but is far enough off-screen that it's not being animated by the browser
16:16:18 <emilio> q+
16:16:33 <fantasai> khush: currently what happens is transition once you bring it on screen
16:16:38 <fantasai> khush: other option is to skip the transition
16:16:50 <fantasai> khush: third option is to force the update and do the transition
16:17:12 <astearns> ack emilio
16:17:15 <fantasai> khush: once the browser has set up the animation, just like other animations the UA won't need ot run the animation, just update the timeline, as long as it's offscreen
16:17:25 <fantasai> emilio: I'm not a fan of forced-rendering, because it allows [missed]
16:17:34 <fantasai> emilio: you can call requestAnimationFrame and then startViewTransition
16:17:58 <fantasai> emilio: I tend to think current behavior is more consistent with regular animation frame would work
16:18:02 <vmpstr> q+
16:18:04 <fantasai> emilio: so I think current behavior is fine
16:18:15 <fantasai> emilio: skipping transition allows you to detect this more directly, I don't think it's great
16:18:26 <fantasai> emilio: we rely on the page not knowing whether it's throttled
16:18:43 <fantasai> khush: because iframe is not ??, can't they already detect offscreen?
16:18:55 <fantasai> emilio: well yeah, but you don't know if it's because of slow machine or because offscreen
16:18:56 <vmpstr> s/??/getting rAF callbacks/
16:19:12 <fantasai> emilio: can act somewhat differently, but iframe isn't allowed to unthrottle itself, which is what forced rendering would do
16:19:15 <astearns> ack vmpstr
16:19:53 <fantasai> ??: We'll timeout by the time the animation is on screen, so if call startViewTransition callback won't run until at least one rAF callback, and by that time we are likely to skip the transition
16:20:02 <astearns> s/??/vmpstr/
16:20:03 <fantasai> khush: timeout starts after we cache the old state. Just happens to ???
16:20:08 <fantasai> vmpstr: doesn't seem great
16:20:17 <fantasai> emilio: Should we change that so that the timeout starts when you actually call the API?
16:20:27 <fantasai> khush: don't see any reason not to
16:20:29 <khush> q+
16:20:31 <fantasai> astearns: other questions/comments?
16:21:01 <fantasai> emilio: Given we unthrottle not exactly when you're in the viewport bounds, but in some range, likely that by the time you scroll to the iframe transition has finished anyway
16:21:17 <fantasai> stephenfromgoogle: Is throttling behavior thought to be interoperable at this time? Vague in the spec.
16:21:35 <fantasai> stephenfromgoogle: would we introduce an interop issue if we don't force rendering?
16:21:50 <vmpstr> +1
16:21:51 <fantasai> flackr: that was one of my concerns about not forcing rendering. it would expose more of those differences in behavior
16:22:04 <fantasai> emilio: that difference is already exposed by rAF tagging
16:22:13 <astearns> s/tagging/timing/
16:22:25 <fantasai> emilio: I think it's somewhat reasonably interoperable, at least I assume all browsers to be throttling visibility:hidden and very far off screen
16:22:44 <fantasai> emilio: this is an area that could get improvement, especially now that lazyloading thresholds are a thing
16:22:49 <flackr> q+
16:23:12 <fantasai> stephenfromgoogle: I can tell you, our throttling code in Chromium has no margin. If an iframe is even 1px outside viewport, it will be throttled. That's different form lazyloading, which does have a margin.
16:23:22 <fantasai> emilio: worth discussing in an HTML spec issue
16:23:36 <fantasai> emilio: in any case, I still think forced rendering is not a great option
16:23:48 <ydaniv> ydaniv has joined #css
16:23:49 <fantasai> emilio: if you call startVT, then you can force engine to unthrottle you all the time, which is not great
16:23:52 <astearns> ack khush
16:24:01 <fantasai> khush: +1 everything Emilio said
16:24:16 <fantasai> khush: especially for one frame
16:24:29 <vmpstr> q+
16:24:30 <fantasai> khush: with other CSS animations, unless animating we don't need to spend resources on it, but here do
16:24:35 <fantasai> khush: so would prefer current behavior
16:25:06 <fantasai> khush: Yes, different browsers use different margins, and different features have different margins, being exposed doesn't seem like a big constraint
16:25:07 <astearns> ack flackr
16:25:15 <fantasai> flackr: difference with animations is that you can always produce the thing that would have been drawn
16:25:25 <fantasai> flackr: whereas with VT, once you draw the updated, you have destroyed the old state
16:25:34 <fantasai> flackr: can't recover if it suddently becomes visible
16:25:45 <fantasai> flackr: One use case was starting a view transition on a frame, and then bring it into view
16:25:58 <fantasai> flackr: maybe there's an alternative to consider who's starting the transition
16:26:18 <fantasai> flackr: if starting within hidden frame, ... but if starting from root frame, could unskip frame by moving it into view?
16:26:25 <astearns> ack vmpstr
16:26:54 <fantasai> vmpstr: whether we keep these frames alive or not is also a function of whether started when iframe on screen and then moved offscreen or started offscreen
16:27:13 <fantasai> vmpstr: Also don't understand concern wrt frame throttling. You could set timeouts and force rendering in a script
16:27:21 <fantasai> vmpstr: why would they use VT to unthrottle?
16:27:33 <fantasai> flackr: Browsers can force minimum timeouts on setTimeout
16:27:40 <fantasai> vmpstr: it would force it to run rAF?
16:27:44 <fantasai> vmpstr: iframe would do more work?
16:27:56 <fantasai> flackr: yes, it would force it right away, but setTimeout would wait a second
16:28:00 <fantasai> vmpstr: what's the attack vector here?
16:28:19 <fantasai> emilio: I'm not sure whether there's a good way... I've seen frames consuming too much CPU unintentionally
16:28:34 <fantasai> emilio: I can't think of a recent case where they do it intentionally
16:28:59 <fantasai> dholbert: maybe an ad wants to start playing immediately rather than skipping a few frames, so continuously burns CPU in the background so it's ready
16:29:07 <dholbert> dholbert has joined #css
16:29:11 <fantasai> khush: use case I'm concerned is, it's hard for an iframe to do the right thing without a lot of code
16:29:15 <dholbert> present+
16:29:30 <fantasai> khush: whereas with other animations, just browser doesn't spend resources. This is the first case where we would force rendering
16:29:34 <jensimmons> jensimmons has joined #css
16:29:48 <fantasai> vmpstr: more wondering about second case
16:29:55 <fantasai> vmpstr: we could enforce setTimeout limits
16:30:08 <fantasai> vmpstr: concerned that you call your startViewTransition for some effect, and that will only start running when you're on screen
16:30:08 <emilio> q+
16:30:21 <fantasai> vmpstr: so I would force rendering or skip trnasition, but not doing thing until on screen
16:30:24 <astearns> ack emilio
16:30:33 <fantasai> emilio: alternatively set timeout mechanism to start when you call API?
16:31:00 <fantasai> vmpstr: [missed]
16:31:00 <flackr> q+
16:31:04 <fantasai> vmpstr: much better than current behavior
16:31:10 <astearns> ack flackr
16:31:29 <fantasai> flackr: one possibility, when we start the animation we could start it with a negative start delay, so that it would be timed as if it had started on time
16:31:37 <vmpstr> s/[missed]/it's timing dependent -- whether you've scrolled the frame into view within the timeout or not/
16:31:39 <fantasai> flackr: this would basically defer the work until the animation became visible
16:31:46 <fantasai> khush: you'd have to render to cache?
16:32:03 <fantasai> flackr: when it becomes visible. If it doesn't become visible until end of duration, then you can skip it
16:32:22 <fantasai> khush: complexity of all the animation after caching old DOM, you still have to do at least one render to cache it
16:32:31 <fantasai> flackr: or you defer the dom change
16:32:49 <fantasai> khush: which pseudo-elements get rendered depends on the new DOM
16:32:54 <fantasai> khush: we don't know until we run the callback
16:32:59 <fantasai> flackr: you defer until it becomes visible
16:33:21 <fantasai> flackr: when it becomes visible, you do pre-snapshot, you do the update, you determine animations, and you determine that the animations are finished, so immediately jump to end state
16:33:26 <fantasai> khush: sounds like skip
16:33:30 <fantasai> flackr: except it fires all the events
16:33:34 <fantasai> flackr: and [missed]
16:33:41 <fantasai> flackr: it's only "skipped" ...
16:33:50 <fantasai> khush: what's the goal? we don't want the author to know we skipped it?
16:34:00 <fantasai> flackr: there's no difference between whether your frame was on screen or offscreen
16:34:09 <fantasai> flackr: if it comes on-screen during animation, you'll see the animation
16:34:45 <fantasai> flackr: I haven't fully thought this out, but thinking that if you know when the request to start the animation occurred, that's the start of your timeline
16:35:00 <fantasai> khush: like current behavior, except animations will finish faster
16:35:07 <fantasai> emilio: might also be consistent with how time-based CSS animations work
16:35:27 <fantasai> emilio: if you have an iframe, and then scroll down, by the time you scroll up again the browser has done no rendering updates, but animation jumps to the correct point
16:35:35 <fantasai> emilio: that's worth consideration
16:35:52 <fantasai> vmpstr: capture right now can take some amount of time, and so that time would then be immediatley skipped into the animation, which won't be a smooth experience
16:36:09 <fantasai> vmpstr: essentially the animation start waits until the capture is available; with this change it would be a frame or two of delay
16:36:11 <khush> q+
16:36:22 <fantasai> vmpstr: so those first 2 frames would be immediately skipped into the third frame of the animation, which is not ideal
16:36:31 <fantasai> flackr: that's a fair concern, possible ways to mitigate that
16:36:39 <fantasai> flackr: you take the time until the frame started as your negative start delay
16:36:55 <fantasai> vmpstr: worth considering this model, but need to be careful about the math
16:37:03 <astearns> ack khush
16:37:20 <fantasai> khush: my issue is this approach is complicated. What benefit do we derive from it?
16:37:34 <fantasai> khush: ...
16:37:45 <fantasai> khush: what's the benefit of bringing iframe on screen with the old DOM?
16:38:00 <emilio> q+
16:38:02 <fantasai> vmpstr: it supports cases of, suppose your animation is 30s and starts offscreen, and then you scroll it into view partway through
16:38:11 <gtalbot> gtalbot has joined #css
16:38:14 <fantasai> vmpstr: it looks like everything was working all along
16:38:23 <fantasai> khush: you eventually want user to see the new state
16:38:45 <fantasai> khush: point of doing animation is to go from old state to new state nicely
16:39:06 <fantasai> astearns: maybe we should look at the new option and bring it back
16:39:07 <astearns> ack emilio
16:39:23 <fantasai> emilio: perhaps more realistic use case for this model is, consider a lazyloaded iframe
16:39:31 <fantasai> emilio: page being loaded has a view transition while loading
16:39:42 <fantasai> emilio: right now, given stephen's comment about no margin
16:40:06 <fantasai> emilio: lazyloading kicks in first, page is invisible, then you call startViewTransition. If you skip it, then you discard everything the author wanted even though user is about to scroll the iframe
16:40:09 <flackr> +1
16:40:25 <fantasai> emilio: That model doesn't seme too complicated, just need to handle the first two frame jump
16:40:32 <fantasai> emilio: It behaves more consistently with our APIs also
16:40:41 <fantasai> emilio: rAF we just delay your callback, this seems similar
16:40:54 <fantasai> emilio: I think there are more use cases that justify this kind of model
16:41:02 <astearns> ack fantasai
16:41:25 <fantasai> fantasai: basically agree with astearns and emilio
16:41:35 <fantasai> fantasai: let's explore flackr's model, and come back
16:41:48 <fantasai> vmpstr: ok, let's look into the issue and comment with our findings
16:42:06 <github-bot> Subtopic: [css-view-transitions-2] [css-pseudo-4] Clarify ordering of `::view-transition` with other tree-abiding pseudo-elements
16:42:34 <fantasai> khush: spec says ::view-transiiton element originates from the document element
16:42:43 <fantasai> khush: but doesn't say what the ordering of the pseudo-element is wrt other pseudo-elements
16:43:12 <fantasai> khush: proposal is, since conceptually it's lifted into containing block, it's meant to be last thing that paints over entire DOM
16:43:19 <fantasai> khush: so having it be after ::after makes sense to me
16:43:51 <fantasai> fantasai: Agree. Should be after everything, including ::after
16:44:04 <fantasai> emilio: is this observable?
16:44:27 <fantasai> khush: I think maybe hit-testing. If the author removes ? from root element, whether you hit ::after or view-transition?
16:44:37 <fantasai> emilio: that's a painting order problem
16:45:12 <fantasai> emilio: It's worth putting in the spec, but might not be observable right now
16:45:18 <fantasai> khush: which is a good time to do it :)
16:45:44 <fantasai> fantasai: if we all agree, let's just resolve and put it in the spec :)
16:46:03 <emilio> emilio: maybe `document.documentElement.getAnimations({ subtree: true })`, if that returns pseudo-element animations?
16:46:10 <fantasai> RESOLVED: ::view-transition pseudo is the last child of its originating element, after everything else including other pseudo-elements
16:46:43 <fantasai> Topic: Transitions
16:46:48 <github-bot> Subtopic: [css-transitions] Transition to height (or width) "auto"
16:46:49 <khush> > if that returns pseudo-element animations?
16:46:49 <khush> flackr can confirm. I think it's supposed to.
16:47:01 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/626#issuecomment-2071016522
16:47:27 <fantasai> dbaron: We discussed calc-size() proposal. One question was whether we could, instead of or in addition to calc-size(), write what people want to write
16:47:31 <fantasai> dbaron: concern was compat, but did we check
16:47:49 <fantasai> dbaron: one thing I followed up with, since I had implemented, I could implement the natural behavior where you could just transition '0x' to 'auto'
16:47:53 <fantasai> dbaron: I could figure out what could break
16:48:09 <fantasai> dbaron: There's more details in the comment in the issue, but basically what I did was a very conservative study
16:48:25 <fantasai> dbaron: ran through loading top 1000 sites with a special build
16:48:39 <fantasai> dbaron: Even with that limit, I found multiple pages that would break with this change
16:48:54 <fantasai> dbaron: [gives some examples]
16:49:16 <fantasai> dbaron: Several pages animating widths and heights from zero that was not expected
16:49:36 <fantasai> dbaron: at the same time, there was a page on ups.com with an animation that got better
16:49:49 <fantasai> dbaron: but conclusion was, given this very small and conservative sample shows multiple pages that are broken
16:49:52 <flackr> q+
16:49:53 <fantasai> dbaron: we know it's not web-compatible
16:50:06 <fantasai> dbaron: so we know we can't just support CSS tranistion from 0px to auto and equivalents
16:50:21 <fantasai> dbaron: given that, what I want to get out of this is to restate more firmly that we want to move forward with calc-size()
16:50:35 <fantasai> dbaron: given alternative, which would have better developer ergonomics, is not compatible
16:50:37 <astearns> ack flackr
16:50:45 <fantasai> flackr: agree we can't just do it automatically
16:50:57 <fantasai> flackr: what about having a more generic opt-in for authors?
16:51:08 <fantasai> flackr: calc-size() require for each item to change the styling
16:51:19 <fantasai> flackr: whereas a switch could opt in your whole page
16:51:26 <fantasai> dbaron: we could consider something like that
16:51:36 <fantasai> dbaron: maybe use transition-behavior, which is designed to do that
16:51:46 <fantasai> dbaron: it's reset by the transition shorthand
16:51:58 <fantasai> flackr: it's also about transitions only, not animation
16:52:05 <fantasai> dbaron: I think we can do both
16:52:17 <fantasai> dbaron: current behavior with calc-size(), to get the animation you have to wrap at least one endpoint in calc-size()
16:52:39 <fantasai> dbaron: I also do worry about global overrides
16:52:50 <fantasai> dbaron: because pages are built from smaller components
16:52:56 <astearns> ack fantasai
16:53:46 <fantasai> fantasai: Agree with flackr
16:54:01 <TabAtkins> I'm completely fine with a value that can turn on the transition behavior for general values, fwiw, so long as the default behavior requires using calc-size() on at least one side.
16:54:15 <fantasai> fantasai: I think putting in transition-behavior is good, not global, easy to incorporate into transitions and gets reset whenever you do a different ransition
16:54:45 <fantasai> fantasai: for animations, could consider something in the @keyframes rule, so that it gets associated with the keyframes and used wherever the keyframes get used
16:54:57 <fantasai> astearns: but agree that doesn't preclude using calc-size()
16:55:00 <fantasai> fantasai: yes
16:55:30 <fantasai> TabAtkins: Proposed resolution, by default, only get transition if at least one side gets calc-size()
16:55:59 <gtalbot> gtalbot has joined #css
16:56:01 <fantasai> RESOLVED: Animation to/from keyword sizes requires an opt-in, so by default only get transition ifa t least one side gets calc-size()
16:56:12 <fantasai> s/ifa t/if at/
16:56:39 <fantasai> dbaron: At this point it's prototyped in Chromium, but it's getting more stable and closer to matching spec at this point
16:57:38 <fantasai> Topic: End
16:59:03 <astearns> zakim, end meeting
16:59:03 <Zakim> As of this point the attendees have been dbaron, flackr, davidleininger, hdv, gregwhitworth, kizu, chrishtr, keithamus, jensimmons, akeerthi, fantasai, masonf, lea, smaug,
16:59:06 <Zakim> ... dandclark, una, TabAtkins, jarhar, JonDavis, ydaniv, kbabbitt, JaseW, bts, bramus, khush, schenney, alisonmaher, vmpstr, jfkthame, florian, emilio, bradk, rachelandrew,
16:59:06 <Zakim> ... bkardell_, dholbert
16:59:06 <Zakim> RRSAgent, please draft minutes v2
16:59:07 <RRSAgent> I have made the request to generate https://www.w3.org/2024/05/08-css-minutes.html Zakim
16:59:13 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
16:59:13 <Zakim> Zakim has left #css
17:41:37 <bradk> bradk has joined #css
17:53:20 <bradk> bradk has joined #css
18:37:36 <Linux_Kerio> Linux_Kerio has joined #css