14:53:58 <RRSAgent> RRSAgent has joined #css
14:54:02 <RRSAgent> logging to https://www.w3.org/2024/09/25-css-irc
14:54:02 <tpac-breakout-bot> RRSAgent, do not leave
14:54:03 <tpac-breakout-bot> RRSAgent, make logs public
14:54:04 <tpac-breakout-bot> Meeting: Canvas place element
14:54:04 <tpac-breakout-bot> Chair: Khushal Sagar, Fernando Serboncini
14:54:04 <tpac-breakout-bot> Agenda: https://github.com/w3c/tpac2024-breakouts/issues/43
14:54:04 <Zakim> Zakim has joined #css
14:54:05 <tpac-breakout-bot> Zakim, clear agenda
14:54:05 <Zakim> agenda cleared
14:54:05 <tpac-breakout-bot> Zakim, agenda+ Pick a scribe
14:54:07 <Zakim> agendum 1 added
14:54:07 <tpac-breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
14:54:07 <Zakim> agendum 2 added
14:54:07 <tpac-breakout-bot> Zakim, agenda+ Goal of this session
14:54:09 <Zakim> agendum 3 added
14:54:09 <tpac-breakout-bot> Zakim, agenda+ Discussion
14:54:09 <Zakim> agendum 4 added
14:54:09 <tpac-breakout-bot> Zakim, agenda+ Next steps / where discussion continues
14:54:09 <Zakim> agendum 5 added
14:54:09 <tpac-breakout-bot> tpac-breakout-bot has left #css
14:55:31 <Francis_Storr> Francis_Storr has joined #css
15:01:41 <nigel> nigel has joined #css
15:05:39 <nigel> nigel has joined #css
15:06:36 <nigel> nigel has joined #css
15:24:19 <cbiesinger> cbiesinger has joined #css
15:29:07 <alice> alice has joined #css
15:31:12 <kizu> kizu has joined #css
15:33:27 <giacomo-petri> giacomo-petri has joined #css
15:34:25 <ZoeBijl> ZoeBijl has joined #css
15:35:28 <Masakazu> Masakazu has joined #css
15:35:53 <siye> siye has joined #css
15:36:04 <MJ> MJ has joined #css
15:37:10 <TabAtkins> Notes doc at https://github.com/WICG/canvas-place-element/issues/13
15:37:48 <sanketj> sanketj has joined #css
15:40:19 <nigel> nigel has joined #css
15:40:46 <RobKochman6> RobKochman6 has joined #css
15:41:02 <JaseW> Are there slides somewhere?
15:41:12 <Bert> Bert has left #css
15:43:44 <ydaniv> ydaniv has joined #css
15:44:23 <nigel> nigel has joined #css
15:49:28 <bkardell_> bkardell_ has joined #css
15:52:40 <ZoeBijl> Is there a queue?
15:53:21 <schenney> schenney has joined #css
15:55:16 <xfq> xfq has left #css
15:56:39 <hypebeatsmagazine> hypebeatsmagazine has joined #css
15:58:10 <past> past has joined #css
16:01:56 <davidleininger> davidleininger has joined #css
16:02:27 <Jamie> Jamie has joined #css
16:03:57 <davidleininger> davidleininger has left #css
16:05:35 <sefeng> sefeng has joined #css
16:13:11 <jamesn> q+ smfr
16:17:25 <jamesn> ack smfr
16:23:44 <TabAtkins> (this is why we use IRC for scribing and queue control, instead of one-off docs and such)
16:27:46 <smfr> smfr has joined #css
16:31:19 <kizu9> kizu9 has joined #css
16:34:36 <smfr> Aren't we out of time?
16:37:39 <Francis_Storr> Francis_Storr has joined #css
16:38:43 <nigel> nigel has joined #css
16:42:07 <Jamie> Jamie has left #css
16:42:13 <lea> lea has joined #css
16:48:35 <past> past has left #css
17:00:58 <karlcow> karlcow has joined #css
17:02:52 <oriol> oriol has joined #css
17:02:56 <emeyer> emeyer has joined #css
17:03:10 <emeyer> emeyer has left #css
17:03:48 <nigel> nigel has joined #css
17:04:17 <tantek> tantek has joined #css
17:04:23 <nigel> nigel has joined #css
17:04:49 <nigel> nigel has joined #css
17:05:44 <gsnedders> gsnedders has joined #css
17:16:33 <florian_irc> florian_irc has joined #css
17:17:46 <fserb> fserb has joined #css
17:24:39 <fserb> fserb has joined #css
17:28:34 <Domenic> Domenic has joined #css
17:33:30 <kzms2> kzms2 has joined #css
17:33:31 <fserb> fserb has joined #css
17:38:32 <fserb> fserb has joined #css
17:47:48 <fserb> fserb has joined #css
17:58:10 <florian_irc> florian_irc has joined #css
17:58:49 <fserb> fserb has joined #css
18:00:57 <kizu9> kizu9 has left #css
18:06:47 <florian_irc> florian_irc has joined #css
18:12:18 <emeyer> emeyer has joined #css
18:12:25 <mustaq> mustaq has joined #css
18:12:26 <emeyer> emeyer has left #css
18:13:41 <florian_irc> florian_irc has joined #css
18:14:01 <florian_irc> florian_irc has joined #css
18:14:56 <florian_irc> florian_irc has joined #css
18:18:55 <fserb> fserb has joined #css
18:20:41 <jfkthame_> jfkthame_ has joined #css
18:22:13 <tantek> tantek has joined #css
18:23:27 <gsnedders> gsnedders has joined #css
18:34:42 <Penny> Penny has joined #css
18:39:38 <jfkthame_> jfkthame_ has joined #css
19:07:58 <emeyer> emeyer has joined #css
19:08:01 <emeyer> emeyer has left #css
19:17:33 <Francis_Storr> Francis_Storr has joined #css
19:30:47 <Penny> Penny has joined #css
19:32:56 <Linux_Kerio> Linux_Kerio has joined #css
19:33:06 <projecto-> projecto- has joined #css
19:33:36 <nigel> nigel has joined #css
19:33:37 <leaverou_> leaverou_ has joined #css
19:34:38 <Rossen-> Rossen- has joined #css
19:35:08 <shans_> shans_ has joined #css
19:35:38 <sylvaing_> sylvaing_ has joined #css
19:46:13 <Francis_Storr> Francis_Storr has joined #css
20:12:43 <khush> khush has joined #css
20:13:23 <noamr> noamr has joined #css
20:16:00 <kizu> kizu has joined #css
20:17:48 <vmpstr> scribenick: vmpstr
20:17:55 <vmpstr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10945
20:17:55 <github-bot> Topic: [css-view-transitions-*] TPAC breakout session 2024
20:17:55 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10945.
20:17:56 <noamr> present+
20:17:57 <karlcow> karlcow has joined #css
20:18:02 <khush> present+
20:18:11 <vmpstr> present+
20:18:49 <tantek> tantek has joined #css
20:18:58 <vmpstr> vmpstr has changed the topic to: Breakout: View Transitions
20:19:53 <fserb> fserb has joined #css
20:19:58 <ntim> ntim has joined #css
20:20:03 <florian_irc> florian_irc has joined #css
20:20:03 <flackr> present+
20:20:04 <fserb> present+
20:20:05 <Adam_Page> Adam_Page has joined #css
20:20:07 <ydaniv> ydaniv has joined #css
20:20:07 <ntim> present++
20:20:12 <ydaniv> present+
20:20:20 <mmocny> mmocny has joined #css
20:20:21 <vmpstr> noamr: welcome to the future of css view transitions
20:20:23 <moonira> moonira has joined #css
20:20:34 <vmpstr> noamr: <slide 2> previously on view transitions
20:21:01 <vmpstr> ... <slide 3> we have shared element transitions, things that transition into other things that are not the same element. here we have an icon transitioning to a cover
20:21:03 <florian_irc> florian_irc has joined #css
20:21:26 <vmpstr> ... what we did in the last few years and apple webkit did we did same document and cross document view transitions, SPAs and MPAs work with same experience
20:21:36 <vmpstr> ... we don't want the people to change their architecture for the experience
20:21:42 <vmpstr> ... the constraint is that it's same origin
20:22:01 <vmpstr> ... <slide 4> things we have in the oven right now: current view tranisiont are flat
20:22:27 <vmpstr> ... they create a pseudo element tree with snapshots old and new states. this tree is flat. it's a bunch of things stacked on top of each other. so we're working on nested transitions
20:22:42 <vmpstr> ... the other thing is that they are for the whole page, so we're thinking of scoped transitions that are more modular
20:22:46 <vmpstr> ... that's not the topic for today
20:22:59 <vmpstr> ... <slide 4> the story of navigation is incomplete in two ways
20:23:12 <vmpstr> ... first, it's limited to same origin navigations, and the world is not the same origin
20:23:20 <vmpstr> ... second it's gesture driven
20:23:50 <vmpstr> ... <slide 6> you define the transition by defining an image on both things and we use pseudo elements to style what's happening in between
20:24:04 <vmpstr> ... this happens in the new document
20:24:38 <vmpstr> ... <slide 7> in cross document view transition, all the authors can do is slap a rule and it magically works
20:24:49 <vmpstr> ... and the new document runs the transition
20:24:54 <vmpstr> ... <slide 8> why should this be only cross origin
20:25:15 <vmpstr> ... <slide 9> we have requests for this, you saw album to cover transition. what if it's a recommendation to a music provider. this is about a spacial relationship
20:25:29 <vmpstr> ... that allows you to navigate
20:25:40 <vmpstr> ... what about same owner and different origin
20:25:50 <vmpstr> ... origin is the security barrier on the web, with only a few exceptions
20:26:15 <vmpstr> ilya: commerce has a distinct page, where you want to navigate from ecommerce to a wallet provider
20:26:30 <vmpstr> ... when you finish the wallet, you want to transition back to the site. both of those are janky
20:26:34 <vmpstr> ... cross origin would do wonders here
20:26:47 <vmpstr> noamr: <slide 10> this is about the sense of orientation not specific to the app
20:27:10 <vmpstr> ... <slide 11> this is an example syntax, maybe we can say "to: any" to just allow the transition
20:27:17 <vmpstr> ... <slide 12> so why not then?
20:27:27 <vmpstr> ... <slide 13> because security
20:27:43 <vmpstr> ... this is an easy way to kill projects
20:27:53 <vmpstr> ... we were a bit more curious to understand what this means in practice
20:28:11 <vmpstr> ... <slide 4> so the main security thing is ancillary data leaks. this is data that isn't directly related to the request
20:28:23 <vmpstr> ... for instance if you ask for geolocation and you get it, it's not ancillary
20:28:38 <vmpstr> ... here you ask for a visual effect, but you need geometry style information and you can gather whether the user is logged in etc
20:28:53 <nigel> nigel has joined #css
20:28:59 <vmpstr> ... even timing whether the page allows the transition and how long it took, all of this is ancillary data and we don't want to expose any of this
20:29:08 <vmpstr> ... is this reasonable to expose something, but let's assume not
20:29:21 <vmpstr> ... <slide 15> second it's about miscoordination, think about stale links on the web
20:29:36 <vmpstr> ... where it leads to information that is no longer there and you can have buggy looking effects
20:29:49 <vmpstr> ... if it's cross ownership the other side may look bad
20:30:10 <vmpstr> ... <slide 16> third is spoofing, you can start a view transition and bind it to a scroll timeline or pause it
20:30:12 <nigel> nigel has joined #css
20:30:28 <vmpstr> ... the old side can do a bad image like call 1800 givemeallyourmoney and the user will think it's part of the new site
20:30:32 <vmpstr> ... so we can't do it
20:30:49 <vmpstr> ... so we look it at as a tradeoff triangle
20:31:04 <vmpstr> ... first is the expressiveness and then complexity
20:31:16 <vmpstr> ... <Slide 18> with security i think of it as constraints
20:31:26 <vmpstr> ... the first is about the spoofing part, the transition needs to be brief
20:31:37 <vmpstr> ... this transition can't be seconds or scroll timeline, it needs to be 1/2 second or less
20:31:44 <vmpstr> ... it needs to look like an animated transition
20:32:04 <vmpstr> ... the other one is isolated, so unlike same origin transition, here the constraint is that neither document can interrupt or observe the transition
20:32:12 <vmpstr> ... neither document can know if the transition happened
20:32:26 <vmpstr> ... this is a one way street for one document say it wants to transition and the rest is invisible
20:32:30 <eemeli> eemeli has left #css
20:32:32 <vmpstr> ... this is what makes it possible security wise
20:32:46 <vmpstr> ... <slide 19> so let's say we have these principles, now we have 2 dimensions to explore
20:32:55 <vmpstr> ... we have root-to-root element-to-root and element-to-element
20:33:10 <vmpstr> ... <slide 20> this is root to root, the relationship is the whole page not per element
20:33:21 <vmpstr> ... this is still interesting as this is still an opener relationship
20:33:34 <vmpstr> ... this could be something that the page says without each elements
20:33:48 <vmpstr> ... <slide 21> but it's less inspiring than other stuff
20:34:05 <vmpstr> ... like if the opener wants an opacity style animation and the browser can run it by itself
20:34:14 <vmpstr> ... why do browsers control it? maybe there is some relationship there
20:34:32 <gsnedders> gsnedders has joined #css
20:34:34 <vmpstr> ... <slide 22> element-to-root, this is from material design. UXR found that users love this type of transition
20:34:45 <vmpstr> ... from list or from grid open to the whole thing. this is a common usage pattern
20:35:09 <vmpstr> ... this doesn't require coordination since only one page gives us interesting information. the first page gives us geometry etc, but the second page only gives us a surface
20:35:22 <vmpstr> ... <slide 24> we could have a special view transition name that oculd be the new root
20:35:32 <vmpstr> ... and the icon could transition to that name (new-root)
20:35:49 <vmpstr> ... the old page decides what is animation and it needs to brief, but it can do an opacity animations
20:35:55 <vmpstr> fserb: what do you mean by types?
20:36:04 <vmpstr> noamr: it's not important for this
20:36:12 <vmpstr> fserb: and the two is the list of domains?
20:36:14 <vmpstr> noamr: yes
20:36:21 <lea> q+
20:36:26 <vmpstr> noamr: <slide 25> the last is element to element as the last examples
20:37:10 <vmpstr> ... <slide 26> we have an interaction ... you still need to define all your animations in advance, and it allows you shared element
20:37:24 <vmpstr> ... and we need to avoid a way to avoid miscoordinations
20:37:35 <khush> q?
20:37:41 <khush> ack dbaron
20:37:50 <khush> q?
20:38:10 <khush> q?
20:38:23 <khush> ack lea
20:38:28 <flackr> q+
20:38:35 <khush> q?
20:38:42 <lea> oops sorry
20:38:44 <lea> wrong room
20:38:53 <fserb> np :)
20:39:03 <vmpstr> noamr: <slide 28> we have the following implementation options
20:39:19 <vmpstr> ... we can run it on the browser, or run this in a special document
20:39:35 <vmpstr> ... the third one is that we precompile the animation, compute all the keyframes, and then run them one at a time
20:39:53 <vmpstr> ... none of these are simple, this allows interesting UI. security wise it's achievable
20:40:09 <fserb> q+
20:40:10 <vmpstr> ... we're not sure if the expressiveness and complexity trade-off is worth it
20:40:11 <mmocny> q+
20:40:17 <khush> ack flackr
20:40:32 <Adam_Page> q+
20:40:42 <vmpstr> flackr: you mentioned that element to root the style comes from the old page. is that also true for element-to-element? if you're running in the new document you can get the styles
20:40:49 <vmpstr> noamr: <missed>
20:40:56 <vmpstr> ntim: can you go over impl options
20:40:58 <khush> q?
20:41:16 <vmpstr> noamr: one is to run in the browser, one is to do a new document
20:41:22 <vmpstr> ntim: what is browser mean
20:41:24 <aaj> aaj has joined #css
20:41:37 <vmpstr> khush: same as what the browser UI would do, and make it part of the browser UX
20:41:41 <vmpstr> ntim: like swipe animations?
20:41:44 <aaj> q+ aaj
20:41:48 <khush> q?
20:41:50 <vmpstr> flackr: this is defined by css though right?
20:41:54 <vmpstr> noamr: yes
20:42:01 <ydaniv> ydaniv has joined #css
20:42:05 <vmpstr> noamr: another is to have an anonymous document, and that's what's running the animation
20:42:20 <vmpstr> noamr: the third is precompile the animation all of the keyframes in advance to something like display lists and send them over to play
20:42:22 <khush> ack fserb
20:42:45 <vmpstr> fserb: first, because i don't know how it works. for the same origin, how does javascript interact with this. does it execute on the new page before the transition starts
20:42:53 <vmpstr> noamr: when the transition starts, the new page is already active
20:43:04 <vmpstr> fserb: doesn't it break the assumption to be as fast as possible
20:43:20 <vmpstr> noamr: it would be in a different renderer process and only deals with the surface
20:43:27 <vmpstr> fserb: so kind of like loads int he backhground
20:43:41 <vmpstr> khush: what you're saying is an existing problem when you're navigation across the two pages
20:43:57 <vmpstr> ... we just don't want to add more bad things like allowing an inifnite bad animations
20:44:19 <vmpstr> fserb: follow-up -- in the case where we're doing root-to-root or element-to-root, then a lot of time when you use motion to hide loading time
20:44:28 <vmpstr> ... as in you start animating before it's ready so that it looks instance
20:44:39 <vmpstr> ... in the element to element you can'yt do that, but in the element-to-root you could do that
20:44:52 <vmpstr> noamr: yeah, you can animate to an empty surface before it's ready
20:44:57 <vmpstr> ... it's an option vs render blocking
20:45:02 <vmpstr> fserb: both cases exist
20:45:07 <vmpstr> noamr: we'll need to research this
20:45:16 <khush> q?
20:45:30 <vmpstr> fserb: and the only other question: do you have because it needs a coordination that is hard
20:45:42 <vmpstr> noamr: we have requests for same origin and there is an ask for it, and it's a question we need to answer
20:46:07 <vmpstr> khush: the use case is you share a link and you get an image in there but when you click that image expands to an image on the new site
20:46:17 <vmpstr> fserb: but those htings don't track where that image was
20:46:30 <vmpstr> noamr: yeah we'd need to do something with opengraph maybe, and not rely on viewtreansition names
20:46:33 <khush> ack mmocny
20:46:36 <khush> q?
20:47:07 <vmpstr> mmocny: for element-to-element, i envision that the coordination has to happen ahead of time. would it help if ifrmes are involved like if you have an embed and then it's a same origin navigation
20:47:14 <vmpstr> noamr: this is portals
20:47:18 <flackr> q+
20:47:28 <vmpstr> ... this would be a different architecture that would be a different set of use cases, we didn't want to go there
20:47:48 <vmpstr> mmocny: can i ask for shoppify, when you do check out do you see the preview of the card are there iframes
20:47:57 <vmpstr> ilya: no
20:48:13 <vmpstr> mmocny: but you might only need element-to-root or root-to-root
20:48:27 <vmpstr> ilya: yes, element-to-root is a better experience
20:48:38 <khush> ack Adam_Page
20:48:41 <khush> q?
20:49:10 <vmpstr> Adam_Page: i'm on the aria working group, and only know css superficially, but i have two accessibility related questions: could there be anything that can disruptive to the mechanics of unloading a page
20:49:25 <vmpstr> ... when you're having something across the new page
20:49:48 <vmpstr> khush: this would be the same with cross document transition
20:49:59 <vmpstr> ... all of this animation happens on the new dom
20:49:59 <khush> q?
20:50:15 <emeyer> emeyer has joined #css
20:50:20 <vmpstr> Adam_Page: the second question is that accessibility was sensitive to the motion
20:50:31 <emeyer> emeyer has left #css
20:50:37 <khush> q?
20:50:42 <vmpstr> noamr: all of the things we are there in css to do prefers-reduced-motion
20:50:52 <vmpstr> noamr: we might have different defaults
20:50:55 <khush> ack aaj
20:50:57 <khush> q?
20:51:24 <vmpstr> aaj: i had a question about what the perceived benefit is, since there is increasing complexity. does the root-to-root use-case, can we estimate how much of the problem that solves
20:51:33 <vmpstr> ... is that enough to be happy or do we go beyond that
20:51:47 <vmpstr> ntim: it would be weird an dinconsistent if we only did one of the use cases
20:51:55 <khush> q?
20:52:04 <vmpstr> noamr: it would be something we need to take a look <missed>
20:52:24 <vmpstr> aaj: you start with a simple implementation and go beyond that
20:52:40 <vmpstr> ntim: for developers it's confusing if you only cover cross origin but only have same origin it's confusing
20:53:03 <vmpstr> noamr: you can have a long animation or something else
20:53:16 <vmpstr> noamr: none of these are all shared element transitions
20:53:32 <vmpstr> khush: we haven't decided what page we are running this on
20:53:56 <khush> q?
20:53:58 <khush> ack flackr
20:54:12 <vmpstr> flackr: if we have element-to-root then going back would be weird that you can't do the opposite (shrink page)
20:54:18 <vmpstr> s/shrink page/shrink back/
20:54:25 <vmpstr> noamr: it's an open question
20:54:28 <vmpstr> fserb: good point
20:55:00 <vmpstr> khush: the other thing we want to talk about what's in the works, and talking about in view transitions next
20:55:15 <vmpstr> ... most users use gestyures to navigate and view transitions aren't supported there
20:55:54 <vmpstr> ... <slide 2> this is an example of cross document view transition and you click and you see the animation, when you do the back arrow it navigates you back
20:56:22 <vmpstr> ... <slide 3> this is something we're working on, and this is in other browser. the interaction when you clicked a link is the same, but when you did the swipe gesture and we're doing a animation when we do the swipe
20:56:29 <vmpstr> ... so we can't run the view transition there
20:56:39 <vmpstr> ... so we gave the users an ability to customize and took it away
20:57:18 <vmpstr> ... i wanted to mention that the way this is done is we capture a screenshot of the page, so when you swipe back, you can get the peek of where you're going and choose to go there or not
20:57:31 <vmpstr> ... <slide 4> here, we have a couple of example of other transition where customixation might be helpful where the browser can't do it automatically
20:57:43 <vmpstr> ... one is grid of items where you want the animaiton of detailed item to collapse to where it came from
20:57:56 <vmpstr> ... the browser can't do it, but the browser can't do it
20:58:00 <vmpstr> ntim: how is it related
20:58:33 <vmpstr> khush: if we didn't have gesture then the browser can run the transition but if you're running it with a gesture, then we can't do the view transition for that customization
20:58:45 <vmpstr> ... the browser isn't doing a job as good as the author could
20:58:51 <vmpstr> ... the second example is we're dealing with two tabs
20:59:05 <Penny> Penny has joined #css
20:59:06 <vmpstr> fserb: we're talking about gestures, but you're only mentioning back gestures
20:59:15 <vmpstr> khush: yes, we're starting with back gestures
20:59:37 <vmpstr> noamr: thinking of dismissing dialogs, there are other gestures that exist and we were discussing whether to call it swipe to back or a gesture problem in general
20:59:54 <vmpstr> flackr: the tab switch is going forward as well
21:00:10 <vmpstr> khush: <slide 5> so i'm diving deep into how to solve this problem
21:00:24 <vmpstr> ... the red and green part is showing you whether you're on the old or new part of the navigation
21:00:31 <vmpstr> ... most of the interesting stuff happens on the green side
21:00:49 <vmpstr> ... on the old state all we do is do the navigation and do captures, but everything else including animation happens on the new page
21:01:16 <vmpstr> ... <slide 6> this is what the box tree/pseudo tree looks like you have old pseudo that is static images, and the new pseudo is content that is coming from the current document and that's why it's live
21:01:33 <vmpstr> ... <slide 7> this model doesn't work, because by design you would need to run the animation before you've navigated
21:02:03 <vmpstr> ... just to mention why that's bad: there's a lot of state we can undo accidentally, like if you swipe a page and that cancels a payment page without committing to the back gesture
21:02:11 <vmpstr> ... this is why we need to do it on the old pahge
21:02:41 <vmpstr> ... <slide 8> the model we're proposing, we construct the pseudo tree on the old page, and now the line is red since all of the interesting stuff is happening on the old page
21:02:51 <vmpstr> ... if the user decides to cancel and we snap back, nothing happens
21:03:02 <vmpstr> ... if they decide to invoke we flip to the new state
21:03:20 <vmpstr> ... <slide 9> the pseudo tree looks the same, but now the old pseudo is live content from the old page and new pseudo is static content
21:03:34 <vmpstr> ... <slide 10> so where is that content coming from, since we haven't navigated there
21:03:39 <ydaniv> ydaniv has joined #css
21:03:44 <vmpstr> ... if it's a new navigation we don't know what we can do other than prerender
21:04:04 <vmpstr> ... for the history navigation, we have a few options. first is the UA screenshot, which is what we're doing for browser ui
21:04:14 <vmpstr> ... let's wrap it up as a pseudo and give it to the page
21:04:43 <vmpstr> ... the other option is when you went from page A to page B, we broke down the page and captured all of that state, we currently discard it. maybe we can persist it which gives you more interesting information
21:05:11 <vmpstr> ... the last one is back-forward cache. if it's already there, maybe we can ask it to produce one frame and that gives you a high fidelity content
21:05:19 <fserb> q+
21:05:32 <vmpstr> ... we're proposing starting with UA screenshot
21:05:58 <vmpstr> ... <slide 11> mostly this is what we already have but changing how we do this, but something that is missing is that we don't have a notion of gestures that navigate
21:06:03 <vmpstr> ... for this feature we need this
21:06:11 <vmpstr> ... we're thinking of introducing these concepts
21:06:31 <vmpstr> ... one nice thing is that we're not eh first ones to do this
21:06:38 <vmpstr> ... scroll driven animations solved that problem
21:06:52 <vmpstr> ... <slide 12> so the idea as far as CSS is concerned, this gesture can be introduces as a timeline
21:07:18 <vmpstr> ... <slide 13> the one we're htinking of is similar: the first block customize-ua-gestures, is the author saying that i want to run a custom animation, so suppress your own (browser's)
21:07:28 <vmpstr> ... and the second part says this animation is driven by that timeline
21:07:37 <vmpstr> ... so far this is nothing view transition-y going on
21:08:00 <vmpstr> ... for same document navigations, you don't have use view transitions so maybe you can do something simpler
21:08:00 <vmpstr> ... the goal is modularity
21:08:21 <vmpstr> ... the other thing is important: we're not giving developers power of what the gesture does, back gesture still navigates back
21:08:26 <vmpstr> ... all you get to do is customize the back gesture
21:08:36 <vmpstr> ... <slide 14> this is how you would glue it into view trnasiitons
21:09:01 <vmpstr> ... you give it a navigation component that says gesture(--back-timeline) and how UA css will automatically use that timeline
21:09:15 <vmpstr> ... the ideal goal is you defined a transition and it doesn't matter if the user clicked a button or swiped
21:09:22 <flackr> q+
21:09:28 <vmpstr> ... i'm happy to hear question
21:09:43 <vmpstr> ack fserb
21:10:06 <vmpstr> fserb: there are two things: gestures to the timeline, and automatically creating back transitions depending on the forward transitions
21:11:23 <vmpstr> khush: so distinction if you go back, then you load the last page
21:11:29 <vmpstr> fserb: this. might be nice to have without gestures
21:11:41 <vmpstr> ack flackr
21:11:42 <ntim> q+
21:12:10 <vmpstr> flackr: one thing you mentioned it has to run on the old page.. if we have a bfcache, you might unload the page and bfcache it and then reload it
21:12:24 <vmpstr> khush: yes and no, since we still run pagehide and things like that, and the page can cleanup the state
21:12:58 <vmpstr> flackr: it may not be that bad, but setting that aside: at hte point when you're capturing the screenshots, you can capture all of the info that you want to execute targeted transitions with captures and named elements
21:13:07 <vmpstr> khush: it has some intersection state
21:13:09 <vmpstr> ack ntim
21:13:30 <vmpstr> ntim: what if the website puts a vierw transition that is completely incompatible with the gesture
21:13:32 <vmpstr> ntim: where it doesn't makes sense with it
21:13:49 <vmpstr> khush: the site can do weird things with click based animations as well, it's all withint hte context of that
21:13:55 <vmpstr> ??: the site can scroll up when you scroll down
21:14:07 <vmpstr> fserb: the back one is decided by the ua
21:14:24 <vmpstr> khush: the action decided by the UA but the visuals are up to the author
21:14:45 <vmpstr> ntim: what if the page decides that we swipe from the right instead of from the left
21:15:07 <vmpstr> khush: if the site decides, and some of the semantics we have to decide
21:15:23 <vmpstr> ??: does that change if the page is RTL
21:15:40 <vmpstr> khush: yes, as a browser we change the direction of the UX
21:15:51 <vmpstr> noamr: you'd have the coordinates that are relative to the gesture and relative to the history
21:16:16 <vmpstr> fserb: have you thought of the next step, you're presenting as a linear timeline, but that doesn't work in 2d gestures
21:16:35 <vmpstr> noamr: you can have several coordinate systems, you can have two additional ones that are relative to teh gesture and to the historuy
21:16:52 <vmpstr> ... are you going in the direction of the browser history or finger direction.
21:16:57 <vmpstr> ... this is the type of thing to figure out
21:17:17 <vmpstr> khush: we went into a lot of thinking in browser UI so authors don't have to think about it
21:17:30 <vmpstr> fserb: the expressiveness is a complex problem
21:17:34 <khush> q?
21:17:55 <vmpstr> ntim: i'm concerned that you have a different platform that you want a different gesture to go back
21:18:06 <vmpstr> khush: you can start without exposing this gesture to this platform
21:18:19 <vmpstr> noamr: it's a progressive enhancement, if you don't support it nothign breaks
21:18:31 <vmpstr> fserb: have you thought about naming the gestures and then having those
21:20:39 <khush> q?
21:21:24 <vmpstr> tim: i was going to say that there is a case either way, being able to hook into the intent of the gesture is likely more good (but can make arguments for both)
21:21:39 <vmpstr> ... if you're hooked into the gesture itself
21:21:46 <vmpstr> ... history back is history back
21:22:07 <vmpstr> ntim: if you're hook into intents and you assume a certain visual effect, the gesture doesn't make sense
21:22:17 <vmpstr> khush: yeah you need a combination of both
21:22:24 <vmpstr> noamr: these are all the great questions
21:22:40 <vmpstr> topic: end
21:24:34 <Penny> Penny has joined #css
21:24:41 <karlcow> karlcow has joined #css
21:29:08 <florian_irc> florian_irc has joined #css
21:31:12 <TabAtkins> ScribeNick: TabAtkins
21:31:27 <nigel> nigel has joined #css
21:33:17 <TabAtkins> TabAtkins has changed the topic to: Carousel
21:34:19 <karlcow> karlcow has joined #css
21:35:03 <TabAtkins> TabAtkins has changed the topic to: Carousel https://www.w3.org/events/meetings/38e6f53c-458a-484e-b2f0-c85f7dd7d968/
21:35:28 <mmocny3> mmocny3 has joined #css
21:36:17 <mmocny> mmocny has joined #css
21:36:25 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9745
21:36:25 <github-bot> Topic: [css-pseudo-4] Enabling carousel design patterns in CSS
21:36:25 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9745.
21:38:22 <sabidussi_marco> sabidussi_marco has joined #css
21:44:29 <florian_irc> florian_irc has joined #css
21:45:03 <wendyreid> wendyreid has joined #css
21:45:11 <wendyreid> present+
21:45:29 <jarhar> jarhar has joined #css
21:45:39 <tantek> tantek has joined #css
21:45:41 <florian_irc> florian_irc has joined #css
21:45:51 <fserb> fserb has joined #css
21:47:04 <hdv> present+
21:47:27 <Adam_Page> Adam_Page has joined #css
21:47:30 <mustaq> present+
21:47:30 <BrianE> BrianE has joined #css
21:47:32 <TabAtkins> flackr: [introduces self]
21:47:48 <rachelandrew> present+
21:47:49 <TabAtkins> flackr: I've been doing a lot of exploration into new UI patterns on the web, one of which is carousels.
21:48:10 <TabAtkins> flackr: if you look up "should I use a carousel", the common answer is no
21:48:13 <TabAtkins> flackr: session complete
21:48:23 <gsnedders> gsnedders has joined #css
21:48:30 <Penny> Penny has joined #css
21:48:42 <TabAtkins> flackr: this website goes into a bunch of pitfalls people often run into when they write carousels
21:49:02 <TabAtkins> flackr: This particular example is a bad carousel too, it auto advances, I can't swipe, etc
21:49:22 <TabAtkins> flackr: despite the fact that they're often done poorly, there are many many carousel components
21:49:29 <nigel> nigel has joined #css
21:49:56 <TabAtkins> [tech issues]
21:49:59 <jfkthame_> jfkthame_ has joined #css
21:50:01 <oriol> present+
21:50:01 <cyns> cyns has joined #css
21:50:15 <cyns> present+
21:50:30 <karlcow> karlcow has joined #css
21:50:49 <MJ> MJ has joined #css
21:51:00 <BrianE> Present+
21:51:06 <smfr> smfr has joined #css
21:51:18 <giacomo-petri> giacomo-petri has joined #css
21:51:29 <ydaniv> ydaniv has joined #css
21:51:40 <ydaniv> present+
21:51:44 <TabAtkins> flackr: this is bootstrap, for example
21:51:57 <TabAtkins> flackr: OpenUI has done a long exploration of carousel pattern
21:52:03 <cyns> cyns has joined #css
21:52:10 <bkardell_> present+
21:52:11 <TabAtkins> flackr: Adam created a demo showing all the different "shapes" for a carousel
21:52:31 <TabAtkins> flackr: dots, thumbnails, no page markers, no arrows, previews of the next item
21:52:37 <TabAtkins> flackr: you can have shopping carousels, where you move be3tween *pages* of items
21:52:48 <TabAtkins> flackr: whether we like them or not, devs create carousels, so we should make them better
21:52:55 <TabAtkins> flackr: looking at most of these, there's some common features
21:53:11 <TabAtkins> flackr: CSS today comes pretty close to letting you build something like this in a scrolling elmeent
21:53:24 <TabAtkins> flackr: with Scroll Snap you can make something that slides from pane to pane, supports touch
21:53:36 <TabAtkins> flackr: because eit's just a scroll, any scrolling mechanism works, better than explicit event handlers
21:53:42 <TabAtkins> flackr: you just have to roll a few pieces yourself
21:53:52 <TabAtkins> flackr: that's what Adam did on his site, making a few extra bits in JS
21:54:08 <TabAtkins> flackr: so I looked into what we can do better, so it's just scrolling, we can accelerate that, and navigate it in the browser so it's more accessible
21:54:21 <TabAtkins> flackr: I have an explainer where I touch on these features
21:54:26 <TabAtkins> flackr: you have scroll-snap, as mentioned
21:54:32 <TabAtkins> flackr: you often have buttons to scroll between items/pages
21:54:41 <flackr> demo: https://gui-challenges.web.app/carousel/dist/
21:54:42 <Patrick_H_Lauke> Patrick_H_Lauke has joined #css
21:54:42 <TabAtkins> flackr: there's often a progress indicator
21:54:52 <Patrick_H_Lauke> present+
21:54:54 <TabAtkins> flackr: the progress updates as you scroll
21:55:11 <TabAtkins> flackr: and if you have all of these things, you can make a carousel
21:55:13 <TabAtkins> flackr: you can change where these things are positioned, you can make vertical carousels, any combo
21:55:18 <janina1> janina1 has joined #css
21:55:22 <TabAtkins> flackr: breaking these down, I think we can make it possible to express in css
21:55:38 <nigel_> nigel_ has joined #css
21:55:40 <TabAtkins> flackr: i've outline a set of features i'd like to dive into, to explain what part each is offering and how it's used to build a carousel
21:55:44 <TabAtkins> flackr: first, some form of stylable fragmentation
21:55:49 <TabAtkins> flackr: to create automatic pagination
21:55:58 <TabAtkins> flackr: if you use multicol fragmentation, columns:1
21:56:05 <TabAtkins> flackr: you'll get a layout with one page of content per fragment
21:56:12 <TabAtkins> flackr: you'll get a long list of columns, split up into "pages"
21:56:21 <TabAtkins> flackr: if we let yous corll-snap to that, you get a paginated experience
21:56:30 <TabAtkins> flackr: scroll markers if about those progress indicators
21:56:48 <TabAtkins> flackr: skipping the "flow into Grid areas" temporarily
21:56:54 <TabAtkins> flackr: scroll buttons are the next/prev buttons
21:57:02 <TabAtkins> flackr: You can roll them on your own, but it would be convenient to auto create them
21:57:07 <TabAtkins> flackr: finally, inert
21:57:39 <TabAtkins> flackr: the ARIA authoring guidelines for carousels recommend that tonly the onscreen content is present in tab order, and the next/prev buttons are used to bring up the next slide
21:57:47 <TabAtkins> flackr: so you don't trap people in a long list of slide contents
21:57:59 <TabAtkins> flackr: currently authors have to do this manually, updating the inert attribute on each slide
21:58:09 <TabAtkins> flackr: but you could imagine updating this automatically as you scroll or click the buttons
21:58:30 <TabAtkins> flackr: so that's a quick overview, I want to dive into some of them
21:58:52 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10720
21:58:52 <github-bot> Topic: [css-overflow-5] Scroll-markers
21:58:52 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10720.
21:59:04 <TabAtkins> flackr: you can imagine this like a ToC for a scrolalble element
21:59:18 <TabAtkins> flackr: in my example, one way to do it is create a set of anchor links to your content
21:59:34 <TabAtkins> flackr: I'm proposing you add `focusgroup` to get the input semantics you expect - can arrow between them, only one is active at a time
21:59:45 <TabAtkins> flackr: And the browser has some tracking to update which one is "active" at a time
22:00:04 <TabAtkins> flackr: if your page only contains top-level sematnic items - a list of items - you can create pseudo-elements for these
22:00:19 <TabAtkins> flackr: this is crucial for autoamtic pagination, like columns, so you can have one marker per page, not one per item
22:00:24 <flackr> https://github.com/flackr/carousel
22:01:06 <TabAtkins> flackr: here's a simple live example, three sections, declared that each creates a scrol lmarker, and they've been flowed into the scroll marker group on the left
22:01:34 <BrianE> BrianE has joined #css
22:01:46 <hdv> q+
22:02:04 <TabAtkins> flackr: [showing source] roughly speaking, you add a pseudo-element for each thing that needs a marker, and a scoll-marker-group pseudo is automatically created to hold them
22:02:19 <TabAtkins> hdv: what are the a11y semantics of something that becomes a scroll marker?
22:02:41 <bkardell_> q+
22:02:46 <TabAtkins> flackr: shoudl be whatever makes the most sense for these use-cases. given that we upgrade links, i assume it woudl ahve the same sematnics as an anchor link
22:02:59 <Di> Di has joined #css
22:03:04 <bkardell_> q-
22:03:19 <Patrick_H_Lauke> link with aria-current="true"...
22:03:40 <hdv> ack me
22:03:43 <TabAtkins> TabAtkins: and note that in this example it's *generating* fresh anchor links, they can be whatever. if reusing elements on the page, they have to be links already
22:04:05 <TabAtkins> flackr: this example reuses existing links. The ToC links are in a focusgroup, and we track sc roll progress to indicate which is active
22:04:22 <bkardell_> q+
22:04:23 <TabAtkins> flackr: I also have a separate scroll marker group on the right to track the top-level sections.
22:04:35 <TabAtkins> flackr: each group has its own "current" marker
22:04:49 <TabAtkins> flackr: inline links, not in a focus group, dont' get considered in this, they're never marked as "current"
22:04:59 <flackr> https://drafts.csswg.org/css-overflow-5/
22:05:01 <TabAtkins> flackr: This is the most mature of these specs, it's currently in the CSS Overflow 5 spec
22:05:15 <dholbert> dholbert has joined #css
22:05:21 <flackr> https://codepen.io/flackr/pen/MWMLPpP
22:05:30 <TabAtkins> flackr: what i've shown so far is a polyfill, but we have an impl in Chrome Canary with experimental web paltform features turned on
22:06:06 <TabAtkins> flackr: the only content on this page is a bunch of items. they're automatically grouped into pages, with  scroll markers for each page, and next/prev buttons, and it's all automatic from CSS
22:06:13 <TabAtkins> flackr: any questions about scroll markers or move on?
22:06:30 <TabAtkins> bkardell_: This is dependent on the focusgroup attribute? what's the progress on that right now?
22:06:44 <TabAtkins> flackr: to make a scroll marker group from link elements, that's dependent on focusgroup
22:06:57 <TabAtkins> flackr: we implicitly have the semantics for the pseudo-elements, but it doesn't depend on the attribute
22:07:10 <TabAtkins> bkardell_: does the implementation support focusgroup?
22:07:33 <jarhar> q?
22:07:44 <TabAtkins> flackr: the pseudo-element impl has an implementation of focusgroup semantics, by hand. we do have a `focusgroup` impl behind a flag in Chrome, but not shipping yet.
22:07:52 <jarhar> q+
22:07:57 <TabAtkins> flackr: The use of it in my earlier demo used the polyfill
22:08:03 <TabAtkins> ack bkardell_
22:08:03 <bkardell_> q-
22:08:14 <TabAtkins> jarhar: i'm not super familair with the pseudo-element API  shape
22:08:24 <TabAtkins> jarhar: kinda seems like these are more element-like than other pseudos
22:08:36 <TabAtkins> jarhar: we had to make some changes to make them receive events in ways other pseudos can't
22:08:55 <TabAtkins> jarhar: we have, in blink, a pseudoelement class that's a subclass of Element so it kinda works
22:09:06 <TabAtkins> jarhar: talking with Tim, he said their pseudos are more strictly different. might be difficult for them to implement.
22:09:14 <TabAtkins> jarhar: wonder if there are any webkit folks around to talk about
22:09:41 <TabAtkins> flackr: good question. pseudos *can* be targeted by clicks and other events. we hide that the pseudo was targeted (use the owner element instead), but i fyou click on a ::before you can listen for the click event
22:10:11 <TabAtkins> jarhar: and you can use like hover pseudoclass?
22:10:18 <TabAtkins> TabAtkins: Yes, and :focus/:active if they're focusable/etc
22:10:20 <bkardell_>  maybe we can tag ntim so they can find it when there's time and let us know :)
22:10:43 <TabAtkins> flackr: the CSS pseudo spec has a full definition of PseudoElement interface, subclassing Element, so there's a route to them being full-blown event targets
22:10:56 <TabAtkins> jarhar: okay, probably less crazy than i thought it was
22:11:14 <TabAtkins> ack jarhar
22:11:40 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10722
22:11:40 <github-bot> Topic: [css-overflow-5] Scroll button pseudo-elements
22:11:40 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10722.
22:11:50 <kzms2> present+
22:11:51 <TabAtkins> flackr: scroll buttons are conceptually simialr to scroll markers
22:12:01 <TabAtkins> flackr: they are focusable, they hang off the scroll container
22:12:17 <TabAtkins> flackr: and they scroll that element in the indicated direction, as specified by their selector
22:12:44 <TabAtkins> flackr: here i used ::scroll-down-button, but we have syntax alternatives like ::scroll-button(down), this would better let authors specify logical or physical directions, dpeneding on which is appropraite
22:12:53 <ntim> WebKit does want to move away from the PseudoElement class that extends Element
22:13:08 <flackr> https://flackr.github.io/carousel/examples/scroll-button/
22:13:21 <TabAtkins> flackr: so i have a demo built on the polyfill - you also saw them in the Canary live demo
22:13:32 <TabAtkins> flackr: Here's a terms of service agreement or something, page down buttons to go down
22:13:41 <ntim> WebKit only uses that for ::before / ::after. The other pseudos that generate boxes are hooked to render tree building
22:13:42 <TabAtkins> flackr: they should implicitly become inactive when you can't scroll further
22:13:51 <TabAtkins> flackr: and they scroll equivalent to one page, like pressing PgDn
22:14:02 <TabAtkins> smfr: is that the equivalent of a smooth programmatic scroll
22:14:27 <bkardell_> q+
22:14:41 <TabAtkins> TabAtkins: I assume it's basically a PgDn press (possibly in other directions)
22:14:42 <CurtBellew> CurtBellew has joined #css
22:14:49 <bkardell_> q-
22:14:54 <TabAtkins> smaug: maybe a little tricky, maybe not scrolling a full view of height
22:15:00 <jfkthame_> jfkthame_ has joined #css
22:15:06 <TabAtkins> flackr: my understanding is most browsers scroll 85% of the optimal viewing region of the scroller
22:15:12 <TabAtkins> flackr: so you can still see osme of the previous content
22:15:20 <TabAtkins> flackr: of course, with snap areas it'll align as necessary
22:15:42 <TabAtkins> dbaron: I think some may avoid letting the overlap get too big relative to the default font size, you don't want too many lines repeated
22:15:57 <TabAtkins> smfr: so this is independent from carousels, right? basically a generic "fake scroller" control
22:16:00 <TabAtkins> flackr: yes
22:16:07 <TabAtkins> smfr: and you could have one for the root scroller?
22:16:09 <TabAtkins> flackr: yes
22:16:17 <TabAtkins> dbaron: is it problematic for pseudos to be focusable?
22:16:20 <TabAtkins> flackr: i don't think so
22:16:24 <smfr> q+
22:16:40 <flackr> TabAtkins: we presumably want to make psuedos focusable
22:16:43 <flackr> TabAtkins: i hope it's fine
22:16:51 <TabAtkins> dbaron: I think there's a bunch of things taht assume the curently focused thing is an Element
22:17:00 <TabAtkins> flackr: my thinking is that .activeElement
22:17:06 <jarhar> q?
22:17:06 <TabAtkins> dbaron: that's one of the pieces, yes
22:17:18 <TabAtkins> flackr: it'd give you an actual element, in the case of these buttons its the scroll container
22:17:32 <TabAtkins> flackr: this is similar to having focus in a shadow dom, the host element is the activeElement
22:17:39 <TabAtkins> dbaron: that seems like a reasonable model
22:17:45 <TabAtkins> dbaron: it does need to define tab order and such
22:17:51 <TabAtkins> bkardell_: what's the role?
22:18:00 <TabAtkins> flackr: depends on the pseudo, but needs to be well-defined for each.
22:18:05 <TabAtkins> flackr: for scroll buttons, presumably a button
22:18:23 <cyns> cyns has joined #css
22:18:23 <TabAtkins> flackr: i definitely want feedback on things like "what is the focus order"
22:18:38 <TabAtkins> flackr: i think general guidance is buttons for navigating should be together in a group, so they hit the buttons, then into the contents
22:19:11 <TabAtkins> bkardell_: right now scrollers don't have focus behavior, right? you focus the area.
22:19:16 <TabAtkins> ??: it depends!
22:19:27 <TabAtkins> flackr: notaby this is not reproducing the scrollbar, it's adding new scrolling affordances
22:19:42 <TabAtkins> hdv: is there a precedent for gencontent to have their own roles
22:19:56 <flackr> TabAtkins: there hasn't been yet as so far they haven't been given focusability
22:20:39 <smfr> q-
22:20:42 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10715
22:20:42 <github-bot> Topic: [css-overflow-5][css-scroll-snap-2] Snapping and generating scroll-marker pseudo-elements from fragments
22:20:42 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10715.
22:21:03 <karlcow> karlcow has joined #css
22:21:09 <TabAtkins> flackr: Final thing that really helsp make this fall together is being able to use fragmentation to automatically create the "pages"
22:21:23 <TabAtkins> flackr: So if you specify that you have columns:1, that'll make one fragment per page
22:21:33 <TabAtkins> flackr: You could do multiple columns
22:21:40 <TabAtkins> flackr: we want to support some styling on these columns
22:21:51 <TabAtkins> flackr: scroll-snap-align is a notable one, to align the columns itself
22:22:00 <TabAtkins> flackr: not useful to stop a scroll halfway between columns, would rather it snap
22:22:01 <flackr> demo of columns: https://jsbin.com/modewaj/edit?html,output
22:22:15 <TabAtkins> flackr: the other use is generating a scroll marker
22:22:28 <TabAtkins> flackr: if a column is a destination you want to get to, you might want a scroll marker for it
22:22:31 <flackr> https://codepen.io/flackr/pen/yLmyPEV
22:22:34 <TabAtkins> flackr: combining these features, you can make this demo
22:22:48 <TabAtkins> flackr: note snap alingment isn't working yet
22:23:04 <TabAtkins> flackr: you can see the number of scroll-markers i generate changes as i chagne the container size, since different number of items fit on a scroll page
22:23:17 <TabAtkins> flackr: with snap-align support it would automatically snap to pages, arrows would work properly
22:23:30 <TabAtkins> flackr: this lets authors just write a list of content, and have it present in a full paginated experience
22:23:34 <florian_irc> florian_irc has joined #css
22:24:15 <flackr> TabAtkins: while this is fully generated, all of this can be done with real elements
22:24:26 <flackr> TabAtkins: allowing additional structure / semantics
22:25:04 <TabAtkins> syns: This really excited me, as someone who's lead a dev team thru a carousel
22:25:18 <TabAtkins> TabAtkins: our exploration revealed that there were basically *zero* correct carousels on the web
22:25:22 <gsnedders> gsnedders has joined #css
22:25:23 <wendyreid> q+
22:25:27 <TabAtkins> syns: but there are more correct ones ^_^
22:25:32 <TabAtkins> github-bot, end topic
22:26:00 <TabAtkins> wendyreid: I noticed in a lot of examples - and i've also struggled with this for devs - I haven't seen a lot where each item in the carousel contains a bunch of other content
22:26:08 <TabAtkins> wendyreid: Like say each has an image, text, and a call to action button
22:26:23 <TabAtkins> wendyreid: but you also want item-by-item interaction as well as interaction in each
22:26:37 <florian_irc> florian_irc has joined #css
22:26:50 <CurtBellew> present+
22:26:57 <TabAtkins> wendyreid: so in this example (image with label) what if there's a button inside of each, too
22:26:58 <MJ> MJ has joined #css
22:27:06 <bkardell_> q+
22:27:07 <TabAtkins> flackr: this is just content inside a scrollable element, we're not treading new ground
22:27:30 <flackr> polyfilled demo: https://flackr.github.io/carousel/examples/carousel/image/
22:27:51 <dbaron> s/syns:/cyns:/g
22:28:03 <TabAtkins> TabAtkins: the only particularly new thing here is the auto-inerting. only the visible stuff in the scroller show up in the tab order, until you scroll pages
22:28:20 <TabAtkins> wendyreid: in this example I might have expected focus to move to the next button at the end, rather than past
22:28:31 <cyns> q+
22:28:37 <TabAtkins> flackr: we've seen both. the APG example has the buttons together in tab order, but they're visually together there.
22:28:45 <Patrick_H_Lauke> Agree with Wendy here ... APG pattern may not be the be all/end all
22:28:47 <TabAtkins> wendyreid: Yes, it depends on the visual placement
22:29:15 <TabAtkins> flackr: I haven't mentioned this yet, thinking of having invokercommand to let you make your own buttons that scroll; you can put them anywhere
22:29:27 <TabAtkins> flackr: maybe for generated content, we could use reading order to change where they are
22:30:06 <TabAtkins> TabAtkins: except those are abspos usually, so they "wont' participate" in reading order. but we could build on the machinery.
22:30:07 <cyns> ack me
22:30:25 <TabAtkins> cyns: we were talkinga bout that in aria, having to go thru the entire slide to get to the next button can be annoying
22:30:50 <TabAtkins> bkardell_: I have now twice tried to tackle tabs
22:31:01 <TabAtkins> bkardell_: panels and panelsets
22:31:03 <bkardell_> https://github.com/openui/open-ui/issues/559
22:31:06 <TabAtkins> bkardell_: most recently in openui
22:31:17 <flackr> demo showing scroll-marker based tabs: https://flackr.github.io/carousel/examples/scroll-marker/tabs/
22:31:43 <TabAtkins> bkardell_: got far, then got feedback that a bunch of the cases, Sarah higgley and I discovered that sometimes things that look like tabs shoudlnt' be ARIA tabs, but what should they be instead?
22:31:46 <TabAtkins> bkardell_: this might be the answer
22:32:07 <TabAtkins> bkardell_: these look a lot like tabs, but they're actually panels in a document, a kind of scroll
22:32:09 <dbaron> s/Higgley/Higley/
22:32:10 <TabAtkins> bkardell_: I like that
22:32:18 <dbaron> s/higgley/Higley/
22:32:28 <TabAtkins> bkardell_: especially since with a MQ you could change how it's displayed, maybe on your phone it's just a long scroll of content
22:32:46 <TabAtkins> bkardell_: it's kinda a design affordances sometimes, different from browser tabs. those aren't design, they're a doc manager
22:33:05 <TabAtkins> bkardell_: I'd love to hear from more a11y people if you think this might be a decent pattern for attacking this kind of tabs
22:33:12 <florian__> florian__ has joined #css
22:33:35 <smfr> q+
22:33:36 <TabAtkins> flackr: that's also one of the benefits that semantically it's just a list of content. you can just change the way it's presented based on form factor
22:33:42 <TabAtkins> ack bkardell_
22:33:50 <TabAtkins> cyns: would you change the a11y mapping based on that?
22:33:54 <TabAtkins> bkardell_: that's the question
22:34:10 <TabAtkins> bkardell_: maybe we already have things sorta like that, like collapse the menu up
22:34:19 <TabAtkins> bkardell_: but it seems more known-quality and subtle
22:34:25 <TabAtkins> cyns: the browser can do it in this case
22:34:45 <TabAtkins> bkardell_: yeah, and this is like scrollbars. we don't say "this is a scroll area" like in Java, you just get a scroller if you need it
22:35:15 <TabAtkins> bkardell_: here we can see "if you have the real estate, show them in panels" but if it's small make it just scrollable
22:35:22 <TabAtkins> cyns: I like how simple the code is, especially compared to other carousels
22:35:35 <TabAtkins> hdv: so this example wouldn't be ARIA tabs?
22:35:49 <TabAtkins> bkardell_: I think so, I think just having it be a scroller would be a better solution
22:36:07 <TabAtkins> bkardell_: ARIA tabs are cases where they're app-style tabs, more like browser tabs. those should be tabs.
22:36:14 <TabAtkins> bkardell_: but they're also not likely to change, they're not a style choice
22:36:29 <florian_irc> florian_irc has joined #css
22:36:44 <smfr> q-
22:36:56 <TabAtkins> dbaron: I spent an hour talking to Brian and Sarah Higley a year or so ago. I'm rereading my comments, from the long issue Brian linked.
22:37:18 <TabAtkins> dbaron: One thing - do you want find in page to find things in the other tab? do you want all tabs to show in a printout or all?
22:37:40 <TabAtkins> dbaron: I think suggestion was if find-in-page shouldn't switch the tab, and user only wants one tab in the printout, it's probably aria tabs. if it's the other way around, probably the panel-set tabs
22:37:51 <TabAtkins> dbaron: I haven't internalized it enough to be sure I believe it
22:37:58 <TabAtkins> dbaron: especially that those two things correlate well
22:38:22 <TabAtkins> bkardell_: i'm not sure *I* believe it. but enough people I respect have articulated it in a way that makes me think we need to take it seriously
22:38:30 <TabAtkins> bkardell_: if we find something that lets us make that distinction, we should do it
22:38:45 <TabAtkins> bkardell_: but yeah, I don't think everybody has the same feelings
22:38:58 <TabAtkins> bkardell_: not everyone agrees on the breakdown, or even that there should be a breakdown
22:39:05 <TabAtkins> bkardell_: but I think we've articulated differences that do make sense
22:39:44 <TabAtkins> hdv: user research about whether they prefer panel-sets vs aria tabs, doesn't seem to be a clear preference
22:39:53 <TabAtkins> bkardell_: does seem to likely be a user preference, people can prefer either
22:40:01 <TabAtkins> hdv: we saw people who liked either, makes it hard to choose
22:40:20 <florian_irc> florian_irc has joined #css
22:40:22 <TabAtkins> wendyreid: also it's not always semantically easy to express "going to different place on this page" vs "going to different page"
22:40:32 <TabAtkins> wendyreid: sometimes "tab navigation" is doing either
22:40:45 <TabAtkins> wendyreid: not clear to the user
22:40:52 <TabAtkins> wendyreid: and not really a semantic way to indicate that
22:41:20 <TabAtkins> ydaniv: wild idea, if I put overflow:clip (and rest is inert) it would be tabs?
22:41:51 <Patrick_H_Lauke> overflow:hidde (hdv)
22:42:02 <TabAtkins> flackr: one idea that came up in ARIA, could have a role on the scrolling element that determines the generated content role
22:42:22 <dbaron> (https://github.com/openui/open-ui/issues/559#issuecomment-1585043874 was the summary of the discussion that I mentioned above)
22:42:50 <TabAtkins> smfr: I had questions about the real ARIA tabs, presented today was high-level functionality
22:42:59 <Patrick_H_Lauke> bkardell I'm neutral on this. users often...don't care, as long as it works correctly and makes semantic sense
22:43:01 <TabAtkins> smfr: for scrolling carousels, wonder if we should do it for tabs too
22:43:16 <Patrick_H_Lauke> q+
22:43:17 <TabAtkins> smfr: you can do tabs today with radio buttons and :checked
22:43:23 <TabAtkins> smfr: do we want this to work better in this interface?
22:43:34 <TabAtkins> smfr: id' probably want non-visible tabs to be display:none for perf reasons, for example
22:43:54 <TabAtkins> flackr: so something similar to scroll markers, but display:nones the non-active content
22:44:16 <TabAtkins> there's definitely something good in there
22:44:32 <TabAtkins> smfr: also, you said the scroll buttons are siblings of the scroller, how does that work for the root scroller?
22:44:45 <TabAtkins> flackr: they're children  in that case, you'd use fixpos to position them
22:45:23 <TabAtkins> Patrick_H_Lauke: heard about some devs doing this with radio buttons/etc
22:45:30 <TabAtkins> Patrick_H_Lauke: that's obvs semantically very dubious
22:45:36 <TabAtkins> Patrick_H_Lauke: much more positive with what i'm seeing here
22:45:47 <TabAtkins> Patrick_H_Lauke: more bespoke, rather than a perversion of CSS
22:46:08 <TabAtkins> Patrick_H_Lauke: explaining to a screen reader that, yes, there are radio buttons but they actually switch visual tabs, it's bad
22:46:08 <TabAtkins> Patrick_H_Lauke: so this is a good step forward
22:46:23 <TabAtkins> flackr: We're at time, wrapping up
22:46:31 <Patrick_H_Lauke> (in answer to brian's earlier question, i hid in my hotel room for the session)
22:47:17 <Patrick_H_Lauke> great stuff, thanks all
22:48:53 <Patrick_H_Lauke> Patrick_H_Lauke has joined #css
22:53:12 <janina1> janina1 has joined #css
22:56:27 <karlcow> karlcow has joined #css
22:59:56 <jarhar> jarhar has joined #css
23:00:11 <dholbert_> dholbert_ has joined #css
23:00:12 <ethanjv> ethanjv has joined #css
23:00:23 <dandclark> topic: Styling form controls
23:00:29 <dandclark> scribenick: dandclark
23:00:30 <aardrian> aardrian has joined #css
23:00:35 <alisonmaher> alisonmaher has joined #css
23:00:37 <aardrian> present+
23:00:42 <alisonmaher> present+
23:00:56 <tantek> tantek has joined #css
23:01:11 <kbabbitt> kbabbitt has joined #css
23:01:11 <oriol> present+
23:01:13 <kbabbitt> present+
23:01:21 <dholbert> present+
23:01:24 <kschmi> kschmi has joined #css
23:01:34 <vmpstr> vmpstr has changed the topic to: Breakout: Styling form controls
23:01:42 <vmpstr> present+
23:01:48 <estelle> estelle has joined #css
23:02:05 <wendyreid> wendyreid has left #css
23:02:17 <gregwhitworth> present+
23:02:23 <estelle> present+
23:02:34 <JJ> JJ has joined #css
23:02:36 <JJ> present+
23:02:58 <Adam_Page> Adam_Page has joined #css
23:03:04 <moonira> moonira has joined #css
23:03:04 <dandclark> ntim: <presents slides>
23:03:15 <dandclark> ...I've given this presentation in joint csswg-openuicg meeting
23:03:25 <dandclark> ...I've heard many haven't seen it
23:03:36 <giacomo-petri> giacomo-petri has joined #css
23:03:37 <dandclark> ...It's presentation on how we want to make form control styling easier
23:03:48 <gsnedders> gsnedders has joined #css
23:03:56 <dandclark> ...It's gathering of ideas from what's already been discussed in csswg/whatwg and some ideas from webkit team
23:04:18 <dandclark> ...Problem is consistent styling of form controls is a pain
23:04:40 <dandclark> ...If you've worked with form controls before you may have faced inconsistent default styles, or different parts are inconsistent
23:04:44 <bkardell_> present+
23:04:54 <dandclark> ...webkit-prefixed pseudos, others in different browsers
23:05:06 <dandclark> ...The way we want to address this is address incrementally
23:05:18 <dandclark> ...But it's also important to look at this holistically, look at all controls
23:05:25 <dandclark> ...Important to not repeat past mistakes
23:05:37 <dandclark> ...One of the main ideas from CSSWG is appearance:base.
23:05:46 <dandclark> ...`appearance` is prop with 2 other values, `auto` and `none`
23:05:59 <dandclark> ...`base` is new value opting you in to nicer interoperable mode
23:06:07 <dandclark> ...Gives you consistent pseudo elements for styling
23:06:19 <dandclark> ...for UA stylesheets we want to base ourselves on a few principles.
23:06:26 <khush> khush has joined #css
23:06:28 <Rain> Rain has joined #css
23:06:36 <khush> present+
23:06:37 <Rain> present+
23:06:54 <moonira> present+
23:07:25 <dandclark> ...Needs to be identical cross browsers. Controls need to be recognizable. Styling needs to be accessible (e.g. contrast). Styling should be consistent across controls; like a design system. Need to be able to customize appearance easily without needing to reset a bunch of properties. Styling needs to be comprehensive, cover all states.
23:07:54 <dandclark> ...appearance auto is native control styles. appearance: none is basically random. appearance: base is more consistent.
23:08:10 <zcorpan> zcorpan has joined #css
23:08:11 <dandclark> ...Note sizing is inconsistent, maybe appearance:base can solve some of this.
23:08:14 <zcorpan> present+
23:08:28 <dandclark> ...Can't really apply styles on appearance: auto, it's a non-starter for form control customization
23:08:48 <dandclark> ...appearance:none is a mess. Sometimes use system colors. Checkboxes and radios just vanish.
23:08:55 <dandclark> ...So not usable as starting style.
23:09:05 <dandclark> ...pseudo-element tree is inconsistent
23:09:18 <janina1> janina1 has joined #css
23:09:29 <dandclark> ...For appearance:base UA stylesheet we inherit fonts and text colors.
23:09:47 <tantek> tantek has joined #css
23:09:50 <dandclark> ...background is transparent. Border is currentColor.
23:10:22 <dandclark> ...Want to hear feedback from you all about this proposal. What do you think the pain points are with styling form controls, what defaults you're annoyed about
23:10:29 <dandclark> chrishtr: Do you have screenshots of the rest?
23:10:31 <giacomo-petri> q+
23:10:35 <dandclark> ntim: I just have these but can make more
23:10:35 <estele> estele has joined #css
23:10:36 <aardrian> q+
23:10:43 <estele> q+
23:11:16 <kbabbitt> q+
23:11:22 <ethanjv> ethanjv has joined #css
23:11:24 <dandclark> emilio: I think it's good we're focusing on a few simple properties that make the control look like that without adding extra stuff. Focusing on border, background-color and pretty much that is great. I think the different sizing you fixed by just inheriting font. That's because textarea and input have different default fonts. But looks reasonable to me.
23:11:33 <dandclark> ...The other controls may be a lot harder but for these looks pretty good
23:11:33 <gregwhitworth> q?
23:11:46 <dandclark> ntim: Pitch for this is when you style from control it's as easy as styling div.
23:11:56 <dandclark> ...Very simple properties, everything else inherits by default
23:12:06 <gregwhitworth> q+
23:12:08 <emilio> q+
23:12:15 <jarhar> q?
23:12:21 <gregwhitworth> ack giacomo-petri
23:12:32 <jarhar> q+ dbaron
23:12:53 <florian_irc> florian_irc has joined #css
23:12:59 <dandclark> giacomo-petri: It's great. I have concern with placeholders for the color. Browsers provide min high-contrast area. If I can decide text color by default, contrast ratio might not be sufficient
23:13:11 <dandclark> ntim: Right now I use currentColor at 50% capacity but that might not be ideal default
23:13:15 <CurtBellew> CurtBellew has joined #css
23:13:27 <dandclark> gregwhitworth: Important part is you are getting the same styles without us doing computation heavy stuff
23:13:49 <dandclark> ...Complexity can grow quickly if e.g. you have background image
23:14:01 <dandclark> ...At least with this all browsers are now rendering the same stuff
23:14:11 <dandclark> ...Shouldn't be on UA to handle this
23:14:21 <dandclark> ntim: If there's a better default
23:14:26 <gregwhitworth> ack aardrian
23:14:29 <dandclark> gregwhitworth: sure but that's can of worms
23:15:08 <dandclark> aardrian: I love what I'm seeing. Bring in a bunch of props using inherit. Would also bring in letter-spacing and word-spacing. Both those cases inherit.
23:15:14 <gregwhitworth> ack estele
23:16:05 <dandclark> estelle: My concern is the contrast ratio. Considering a new value named mask. I'm also wondering about width. Did you make it display:block?
23:16:20 <dandclark> ntim: In my prototype I did but may not need to force it
23:16:22 <JJ> JJ has joined #css
23:16:32 <dandclark> emilio: These are inline blocks by default
23:17:01 <astearns> s/I did/I used `stretch`/
23:17:05 <dandclark> estelle: If you put width would it listen to that or to appearance:base?
23:17:11 <kbabbitt> q-
23:17:16 <dandclark> emilio: We shouldn't change defaults
23:17:43 <dandclark> estelle: My concerns are not just the color contrast but if someone declares yellow or orange which has hard time meeting contrast ratio, if you put placeholder in there, what happens?
23:18:14 <dandclark> ...The placeholder is text but has to be different color because it's lighter. E.g. orange on blue and ratio is already below AA generally.
23:18:36 <Di> Di has joined #css
23:18:40 <dandclark> ...Those are concerns that if you inherit and you have placeholder text, need to ensure there's contrast so user can tell it's placeholder
23:18:58 <dandclark> ...Mask is new thing presented yesterday. An HTML attribute
23:19:09 <dandclark> emilio: Still very under construction
23:19:11 <dandclark> chrishtr: If added, need to take that into account in appearance:base mode?
23:19:14 <dandclark> estelle: Yes
23:19:34 <dandclark> gregwhitworth: Is this the end of your presenttation?
23:19:36 <dandclark> ntim: no
23:20:02 <gregwhitworth>  https://github.com/salesforce/standards-explainers/blob/master/indicator-psuedo/explainer.md
23:20:09 <estelle> estelle has joined #css
23:20:12 <xiaochengh> xiaochengh has joined #css
23:20:20 <Francis_Storr> Francis_Storr has joined #css
23:20:23 <xiaochengh> q?
23:20:32 <estelle> another thing to consider: ::focus ring style
23:20:32 <dandclark> gregwhitworth: Was going to ask what Chris asked. I want to hold off on having strong opinions because you can just introduce UA stylesheet we can review. My questions are about, e.g. with checkboxes and stuff, how do you guys aim to approach this? Not straightforward to solve given all the use cases for checkboxes
23:20:46 <dandclark> ...Problems with details/summary, range, datetime, get really complicated
23:20:53 <emilio> ack emilio
23:20:56 <gregwhitworth> ack dbaron
23:21:18 <dandclark> dbaron: I wanted to point out one of the concerns with complexity of stylsheet and complexity of overriding is also the states.
23:21:26 <xiaochengh> q+
23:21:32 <dandclark> ...E.g. button has hover style, focus style, combinations of these things
23:21:39 <dandclark> ...Does appearance:base have all that complexity?
23:21:48 <dandclark> ...When the author overrides, must they reproduce all that?
23:22:00 <zcorpan> q+ our current ua css for placeholder is opacity: 0.54 - https://searchfox.org/mozilla-central/source/layout/style/res/forms.css#172
23:22:12 <dandclark> ...One of the issues there is if we limit stylesheet, then it's easy to override those styles
23:22:13 <zcorpan> q+ to say our current ua css for placeholder is opacity: 0.54 - https://searchfox.org/mozilla-central/source/layout/style/res/forms.css#172
23:22:19 <dandclark> ...I think there are tradeoffs there
23:22:29 <dandclark> emilio: That's fine. It's the current state with appearance:none
23:22:33 <dandclark> gregwhitworth: We're overthinking this.
23:22:45 <miriam> present+
23:22:55 <hdv> present+
23:23:10 <dandclark> ...The whole purpose of this is everybody is doing block/flex/inline...I don't have a strong opionion, I just want to see unified UA stylesheet
23:23:19 <emilio> q+
23:23:25 <dandclark> ...and to review that
23:23:30 <aardrian> Agreeing with gregwhitworth that I want to see a massive UA stylesheet.
23:23:52 <dandclark> ntim: Re: dbaron's question, this is UA styesheets and those have lowest pri/specificity in cascade, so authors override anyway
23:24:12 <dandclark> dbaron: The point is partly that the moment you set anything on the control for ignoring states you've overwritten all state specific styling
23:24:25 <dandclark> gregwhitworth: The second you've opted into base you've said you don't like the native styles
23:24:43 <dandclark> dbaron: Goes back to list of 6 principles. Points out how that list conflicts with itself
23:24:51 <gregwhitworth> q?
23:25:08 <dandclark> ntim: Re: states, we had that convo internally about styling disabled elements. As soon as author overrides, they forget to define :disabled.
23:25:22 <dandclark> ...So you define in UA stylesheet for :enabled
23:25:42 <dandclark> ...Once they have disabled one on screen, will see something's wrong
23:25:43 <gregwhitworth> ack xiaochengh
23:26:03 <dandclark> xiaochengh: I'm wondering about the @@@ how much is going to style the internals of the form controls?
23:26:23 <khush> q?
23:26:30 <dandclark> ...Is this UA stylesheet also going to style internal pseudo elements or just the form controls?
23:26:40 <khush> q+
23:26:44 <dandclark> ntim: Want to make sure styling on internal parts also applies to the principles.
23:27:16 <dandclark> xiaochengh: I feel like this is dilemma. Internal impl of form controls shouldn't be controlled by specs. By introducing this you force implementations to do it a certain way.
23:27:27 <dandclark> ntim: We also want to solve problem of inconsistent internals
23:27:32 <dandclark> ...Web devs also want to style internals
23:27:43 <dandclark> ... E.g. with input[type=range] they want to style those internal parts
23:28:00 <dandclark> dbaron: Lot of part of the plan here is that doing appearance: base is defining those internal pseudo elements
23:28:03 <khush> q-
23:28:03 <gregwhitworth> ack zcorpan
23:28:04 <Zakim> zcorpan, you wanted to say our current ua css for placeholder is opacity: 0.54 - https://searchfox.org/mozilla-central/source/layout/style/res/forms.css#172
23:28:39 <dandclark> zcorpan: Placeholder uses opacity already in Gecko
23:28:47 <khush> q+
23:28:52 <dandclark> emilio: Other browsers use hardcoded color
23:28:57 <dandclark> ...It's changeable
23:29:04 <gregwhitworth> ack emilio
23:29:22 <dandclark> emilio: Don't know if you've considered -- if we use currentColor for all these, things like color schemes stop working
23:29:41 <dandclark> ntim: If you inherit color, normally the color from the scheme inherits too
23:30:02 <dandclark> emilio: If I want to make button dark, I say input color scheme dark, it works even if ancestor is light. With this approach it doesn't
23:30:19 <dandclark> chrishtr: So if you have div with currentColor and put color scheme it has no effect
23:30:22 <dandclark> emilio: Right
23:30:29 <dandclark> miriam: But you're opting into that
23:30:44 <dandclark> gregwhitworth: Point is you have a massive stylesheet we can all look at
23:30:57 <dandclark> chrishtr: If it's an issue you need some mechanism to fix
23:31:21 <dandclark> zcorpan: Common usage of color scheme is set on root. Then transparent still gives you a dark control. Wouldn't look different if you only set color scheme on input
23:31:24 <dandclark> emilio: Maybe it's fine
23:31:27 <gregwhitworth> ack khush
23:31:51 <dandclark> khush: Implementation-wise how complicated do you expect set of pseudos to get? Tree-abiding or UA shadow DOM?
23:31:56 <dandclark> ntim: Chromium folks can speak to that
23:31:58 <emilio> zcorpan: https://phabricator.services.mozilla.com/D223657 ;)
23:32:22 <gregwhitworth> q+
23:32:32 <dandclark> jarhar: Yeah, the select element for appearance base has a bunch of different elements. I'm tweaking it, some for appearance:auto and :base, exclude some for base to make it work
23:32:40 <dandclark> gregwhitworth: With new select there are new elements too
23:32:42 <emilio> ack gregwhitworth
23:32:48 <dandclark> ...it's not just the pseudo elements
23:33:10 <dandclark> ntim: Next part of styling controls consistently is pseudo elements
23:33:44 <dandclark> ...Driving principle of designing pseudo element scheme is to cover reasonable use cases, consistency, inherit appearance from originating elements
23:34:03 <dandclark> ...Could do this by `appearance: inherit !important`
23:34:46 <dandclark> emilio: Depending on how we make this work, I agree we should aim for that. Appearance is not inherited property, if we make the psedudos such that they have elements in between it gets set to auto.
23:34:52 <dandclark> ntim: That's implementation detail
23:35:13 <dandclark> gregwhitworth: He's saying youi're calling it out as principle but maybe that's not always true
23:35:25 <dandclark> ntim: <shows example of slider-like control>
23:35:42 <dandclark> ...Have consistent tree as soon as you use appearance:base
23:36:22 <dandclark> ... (for `<progress>`, or `<meter>`,  `<input type=checkbox switch`, `<input type=range>`
23:36:38 <dandclark> ...(shows tree for text-based input)
23:36:52 <dandclark> ...And there's more we are thinking about
23:37:01 <dandclark> ...Planning to take over form styling module level 1 doc
23:37:06 <gregwhitworth> q+
23:37:06 <dandclark> ...Hoping to make it an actual spec
23:37:13 <dandclark> astearns: Don't look at it now, we'll start fresh
23:37:19 <dandclark> ntim: Last part is about styling pickers
23:37:29 <dandclark> ...Like w/ customizable select
23:37:40 <dandclark> ...Pickers are the part of the control that pops out of the page
23:37:58 <dandclark> ...For this want to introduce `::picker()` pseudo with an element
23:38:15 <dandclark> ...Devs can check support. Once all supported, we'll add non-functional version
23:38:34 <dandclark> ...to opt-in for customization of select picker, add `::picker(select) { appearance:base}`
23:38:39 <emilio> q+
23:38:43 <dandclark> ...This makes it no longer exceed window bounds to prevent spoofing
23:39:04 <karlcow> karlcow has joined #css
23:39:06 <dandclark> ...For particular platforms like Apple Watch, UA might force picker to use native picker but that's up for discussion
23:39:15 <dandclark> ...As for status, we're waiting on approval to publish spec
23:39:29 <jarhar> q?
23:39:33 <dandclark> ...There's already spec work for appearance:base in CSSWG and we' re prototyping
23:40:05 <dandclark> gregwhitworth: I'm not necessarily opposed. Have seen  use cases I've seen that pseudos don't cover.
23:40:23 <dandclark> ...We initially reached for psedudos because we were concerned about fricition, but people wanted new elements.
23:40:32 <dandclark> ...In new select there are two
23:40:49 <khush> q?
23:40:50 <dandclark> ...The thumbs, tracks, those shouln't be pseudos. But I'll wait for the stylesheet.
23:41:13 <hdv> s/stylesheet/spec
23:41:18 <dandclark> ...I feel there's a lot going on that can't be covered by pseudos. But the value they bring is you end up with a spectrum of capabilities.
23:41:30 <dandclark> ...May not want to extend control, just adjust styles. That's the value of pseudos
23:41:37 <dandclark> ...But need to deal with that collision
23:42:08 <dandclark> ntim: Pseudos need to cover reasonable use cases. For more complex, might need HTML change to introduce new control
23:42:08 <gregwhitworth> q?
23:42:09 <gregwhitworth> ack gregwhitworth
23:42:12 <gregwhitworth> ack emilio
23:42:34 <dandclark> emilio: I see args for both but if you don't plan to support picker on given platform, could just fail to parse the selector
23:42:40 <dandclark> ...Allows the dev to detect it
23:42:42 <xiaochengh> q+
23:42:47 <dandclark> ntim: That's probably a better solution
23:43:00 <dandclark> gregwhitworth: I don't like the UA saying we don't care what you said
23:43:10 <dandclark> ntim: We'll do that regardless, at least this way you can detect it
23:43:16 <gregwhitworth> ack xiaochengh
23:43:35 <dandclark> xiaochengh: Are we taking the openui approach of specifying anatomy of every form control?
23:43:45 <dandclark> ntim: What I've worked on is specifying tree for all form controls
23:43:59 <dandclark> astearns: Yes to form controls, maybe not for non form controls
23:44:41 <dandclark> astearns: This presentation, send it zipped to wwarchive.
23:45:01 <janina1> janina1 has joined #css
23:45:02 <khush> q+
23:45:07 <dandclark> ntim: Would love your feedback. Pain points I didn't address that I should?
23:45:07 <khush> q-
23:45:36 <dandclark> khush: Specifying the structure and the pseudos, that's only with appearance:base? Or also with appearance:auto?
23:45:46 <dandclark> ...When are we guaranteeing you get this structure
23:45:59 <dandclark> ntim: Prefer not to with appearance:auto. Not mixing native and non-native UI.
23:46:03 <kbabbitt> q+
23:46:15 <dandclark> ...For appearance:none that would be nice but not sure we can because of compat
23:46:31 <dandclark> khush: So we'll have different stucture based on appearance?
23:46:35 <dandclark> emilio: We should aim to unify
23:46:50 <dandclark> ntim: I agree we should unify as much as possible
23:47:03 <dandclark> zcorpan: The compat prevents us from using appearance:none
23:47:08 <dandclark> emilio: Ideally we woulnd't have base
23:47:21 <dandclark> khush: The fact that CSS changes the tree...
23:47:30 <kbabbitt> q-
23:47:44 <dandclark> emilio: It's subtle. How I'd implement it is that you don't make it change tree, but change the layout tree by hiding/unhiding elements
23:48:02 <dandclark> emilio: HTML attribute would be saner
23:48:10 <dandclark> gregwhitworth: CSSWG told us not to do that, to use appearance
23:48:34 <dandclark> ntim: UAs could set display to hide/unhide based on `appearance`
23:48:44 <dandclark> khush: So it has to be change in structure
23:48:51 <dandclark> emilio: Not necessarily
23:49:08 <dandclark> dbaron: How much change depends on what you're doing. With select there's more changes required in the DOM to account the work happening here
23:49:22 <dandclark> ...Some of the stuff is enabled depending on what youi're doing so you can get hybrid cases
23:49:33 <dandclark> ...Aren't there different condiditions for when you enable the new stuff?
23:50:01 <dandclark> gregwhitworth: I think it's all conditioned on `base` now
23:50:02 <dandclark> chrishtr: And `::picker`
23:50:10 <dandclark> gregwhitworth: Great work ntim
23:50:25 <zcorpan> RRSAgent: make minutes
23:50:27 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-css-minutes.html zcorpan
23:51:07 <gsnedders> gsnedders has joined #css
23:57:53 <nigel> nigel has joined #css