15:03:46 <RRSAgent> RRSAgent has joined #css
15:03:50 <RRSAgent> logging to https://www.w3.org/2025/09/18-css-irc
15:03:53 <Zakim> Zakim has joined #css
15:03:59 <noamr> present+
15:04:01 <Zakim> RRSAgent, make logs Public
15:04:03 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:04:16 <jarhar> scribenick: jarhar
15:04:33 <jarhar> noamr: i put up an explainer and a couple of issues for this, and presented at csswg f2f a couple weeks ago
15:04:36 <cwilso> Topic: OpenUI
15:04:37 <cwilso> Agenda: https://github.com/whatwg/html/issues/11625
15:04:39 <zcorpan> zcorpan has joined #css
15:04:49 <jarhar> noamr: its been on some sort of slow burning for the last 2 years since we started cross document view transitions
15:04:59 <jarhar> noamr: its not only a view transitions issue, but that was the driving force behind it
15:05:04 <dbaron> github: https://github.com/w3c/csswg-drafts/issues/12594
15:05:36 <jarhar> noamr: the main thing we wanted to do it allow some experiences that have to do with navigation be more declarative and rely on html and css rather than basically intercept all navigate events and have an if statement in there, which also does not always work for everything if you have cross document things
15:06:29 <jarhar> noamr: this started from looking at a lot of userland code that uses frameworks/js to style things based on navigation experience. frameworks call it pending ui, loading spinners and skeletons, that give you immediate response for a navigation
15:06:36 <jarhar> noamr: in order to do this in frameworks you need this kind of code
15:06:42 <jarhar> noamr: you need to wrap the a element in a "nav link"
15:06:48 <jarhar> noamr: you have to wrap all your links to get this pending ui
15:07:03 <jarhar> noamr: and then the whole idea of whats pending is in the framework, and the framework does the transition and content that has not loaded yet
15:07:29 <jarhar> noamr: this to me, i had to build code like that as a frontend dev and it wasn't guaranteed to be immediate, and its just ui. why cant it be immediate in the platform, change css based on navigating somewhere
15:08:03 <jarhar> noamr: *points out things in code examples*
15:08:27 <fantasai> What does ":remote-link" mean here?
15:08:47 <jarhar> noamr: you have to intercept all your navigations to do this, and you have to clean up after yourself. in cross document navigations, for example
15:09:12 <jarhar> noamr: you might not have a js handle after the navigation. when do you clean up your state? you probably dont, and then if you restore from bfcache, your new style shows some exiting ui
15:09:31 <jarhar> noamr: youre showing some exiting the ui and youre back with bfcache and didn't clean up the animation, and now youre showing this exit ui
15:09:51 <jarhar> noamr: a big use case were working on right now is something that was requested around cross document view transition, i call it two phase view transitions
15:10:04 <jarhar> noamr: people want view transitions to start immediately, but we dont have the end state because we didn't load the new document yet
15:10:27 <jarhar> noamr: we want to use routes so that we can say you can style something like the new document, like a skeleton, create a frame and start to present that
15:10:35 <jarhar> noamr: some people are doing that already
15:10:42 <jarhar> noamr: here is a demo that some css teachers were using
15:11:31 <jarhar> noamr: from the problem to the solution, why dont we put a bunch of url patterns in css and have transitions from that url pattern to this one should behave that way
15:11:43 <jarhar> noamr: that never felt right to me, that a stylesheet should know the navigation url patterns, those can often change
15:11:55 <jarhar> noamr: something so style aware, feels like html or the document should know about it than a stylesheet
15:12:09 <jarhar> noamr: having this can open opportunities in the future that are about ui, not specifically about styling
15:12:28 <jarhar> noamr: the same way we can invoke a dialog open from a button maybe we can invoke it from a link that changes your url, and that url is somehow bound to the dialog
15:12:43 <jarhar> noamr: maybe we can allow scrolling to an element based on path, so that the url change can also apply
15:13:04 <jarhar> noamr: we can have all kinds of interceptions, spa style processes done in the browser rather than in userland
15:13:15 <jarhar> noamr: if all it does is change style, then maybe you dont need code that intercepts the navigation event
15:13:45 <jarhar> noamr: not things we intend to pursue at this moment, but reasoning to have an html representation of roots and using css to style it
15:14:00 <jarhar> noamr: the way we thought to have a script type that is like json, call it routemap
15:14:20 <jarhar> noamr: the main basic thing it does is naming url patterns or combinations of url patterns, so they can be used in css
15:14:33 <jarhar> noamr: later on can be used to create those html ui navigation roles if we decide to do that
15:14:46 <jarhar> noamr: the naming and combination we try as much as possible to be consistent with service worker static routing
15:14:54 <jarhar> noamr: this cant be done in a service worker because navigation is done in the window
15:15:13 <jarhar> keithamus: is there a good reason to have the route map defined in html rather than using css as the language to describe this?
15:15:29 <jarhar> noamr: its one of the alternatives. you mean have it as an html thing but css as the definition language?
15:15:42 <jarhar> keithamus: idk why we have to specify the patterns and roles in html if you also need them in css
15:16:09 <jarhar> noamr: thats one of the options. i think what was strange about it is more of a stylesheet lifecycle. it probably needs to be a script in terms of what it can do if we later connect it to html things
15:16:24 <jarhar> noamr: the precedent for something defined in css but accessible from html is using fonts in canvas, for example
15:16:37 <jarhar> noamr: but it feels a bit different, routes seem more like an html native thing than a style native thing
15:16:44 <jarhar> noamr: using css as a DSL for it seems ok
15:17:06 <jarhar> dbaron: one of the things noam was saying is that it isn't in this proposal right now but using this for more html features in the future that are not as tied to css
15:17:32 <jarhar> keithamus: do the two need to live together? do we need an intrinsic coupling or can we have them as discrete features where one is focused on styling and the other is focused on html?
15:17:55 <fantasai> I think you could do both. Define a "routemap" script type, use CSS syntax so it's easier to use, and allow it to be put into <script> or <style>, with <script>s being available to JS. Or something.
15:18:02 <jarhar> noamr: the other reason to have it in html is to have url matching patterns, so you can name your url patterns in html and refer to them logically with a name in css, rather than you have to change all your styles when you change your navigation path to something
15:18:13 <jarhar> noamr: a bit like how you can name modules in html with importmap
15:18:37 <jarhar> annevk: could you explain more of the basics of how this routing works? im not sure i understand when the states apply to elements
15:19:12 <jarhar> noamr: the states of how this applies to css are based on a navigation - on the navigation process. a current route would become selected in css at the same time that the url bar changes to that route, meaning commit
15:20:11 <jarhar> noamr: if your url says im at article, then all the paths that match article, all those styles would be selected. in the css part of the syntax, the idea is you could say that youre navigating to or from something, and that would be applied while youre navigating
15:20:20 <jarhar> noamr: if you initiated a navigation and its not yet committed , then youre navigating to something
15:20:26 <jarhar> noamr: at that point, youre also navigating from something
15:20:35 <jarhar> noamr: navigation transition object in html is a very good proxy for that
15:20:42 <jarhar> noamr: theres a from and a to
15:20:55 <jarhar> noamr: while were speccing it we will have to fine tune this to be more exact, we havent done that yet, but we have a good handle of it
15:21:05 <jarhar> annevk: isnt navigation often quite quick? i guess you can maybe observe some of it
15:21:14 <jarhar> noamr: it could be, but for things like view transitions, one frame is enough
15:21:27 <jarhar> noamr: for entry animatin between routes, it doesnt matter if its quick
15:21:40 <jarhar> noamr: some navigations are not quick, and you want to show some kind of exit in a safe way
15:21:46 <jarhar> noamr: we hope all navigations are quick
15:22:02 <jarhar> annevk: we already have some kind of routing with service workers, and so now you have to duplicate that all over your code base?
15:22:24 <jarhar> noamr: you dont need duplication, you can use url patterns and the combinators might be different, but its likely that your routes are different in your service workers than in navigation
15:22:36 <jarhar> noamr: service worker might say use cache for evertyihg, but different from styling the routes
15:22:54 <jarhar> noamr: can probably use similar syntax, but you also cant define this in a service worker
15:23:09 <jarhar> noamr: it is true that there are several places that youre routing, but idk if they can be combined in a meaningful way
15:23:21 <jarhar> fantasai: idk about service workers, but could you use your route map script in service workers as an option?
15:24:00 <jarhar> noamr: service workers do have a subset and a superset of this. there are things that dont make sense in a service worker and vice versa. whether something comes from cache is a service worker, and naming things for css is a different thing
15:24:12 <jarhar> noamr: service workers dont have html so theyd have to import this as json
15:24:18 <jarhar> noamr: server side would be able to generate both
15:24:28 <jarhar> noamr: rather than try to reuse the same file, idk its an option
15:24:47 <jarhar> keithamus: presumably you could have a route map as an external resource. there are sites with thousands of routes. you could share that resource between the service worker and the html page
15:25:12 <jarhar> noamr: my thinking so far is that a lot of these are going to be separate routes, what gets cached is a separate decision of what gets styled
15:25:25 <jarhar> keithamus: the naming could be convenient, if you have an article route you could define that in one place
15:25:42 <jarhar> fantasai: the remote link pseudo class, what does it mean?
15:25:52 <jarhar> noamr: we have a separate issue for it, but we currently have a local link for a link that targets the current url
15:26:08 <jarhar> noamr: the idea of remote link is that its a counterpart, its a link that targets the current url that youre navigating to
15:26:27 <jarhar> keithamus: there was a discussion about making it a pseudo fn and using a url pattern in it
15:26:33 <jarhar> keithamus: you could use the same route matching primitives
15:26:38 <jarhar> noamr: i discussed this a bit here
15:26:48 <jarhar> noamr: i didnt know about that conversation, ill look into that
15:26:50 <keithamus> https://github.com/w3c/csswg-drafts/issues/10975#issuecomment-2614013263
15:27:13 <jarhar> noamr: all those link pseudo classes can benefit from either route matching and/or inline url pattern matching, which im less sure about
15:27:22 <jarhar> noamr: not sure how much of a footgun it is
15:27:38 <jarhar> fantasai: local link is just testing the url, its equivalent to checking the href, its not about whether the link is active or not
15:27:49 <jarhar> fantasai: is remote link about whether the link is active or not? or its not pointing to this page
15:28:03 <jarhar> noamr: its the link that is targeting the url of the destination of an ongoing destination
15:28:11 <jarhar> fantasai: ok so its what :active meant in ie6
15:28:27 <jarhar> fantasai: it seems useful, im not sure remote link is a good name but im sad that definition of :active went away
15:29:06 <jarhar> noamr: it has the same semantics of a navigate event without being able to intercept it
15:29:16 <dbaron> fantasai, there's also a subtle distinction about two different possibilities for the link navigating pseudo-class that I mentioned in https://github.com/WICG/declarative-partial-updates/issues/49
15:29:21 <jarhar> noamr: you basically get navigate events for browser ui back, but you cant intercept it
15:29:37 <jarhar> noamr: it would be the same here, youd be able to style that something is going on but you cant say im turning this into a different type of navigation
15:30:00 <jarhar> annevk: i wonder if there some other thing this could be used for
15:30:07 <jarhar> annevk: its a lot of complexity for not that much functionality
15:30:20 <jarhar> annevk: i wonder if it can be used for more things, like the navigation api could use these routes in some way
15:30:30 <jarhar> noamr: its there in the explainer, theres a lot of them, some people said its too much
15:30:49 <jarhar> noamr: we put the css thing as first, but the current use case we envision for that
15:30:55 <jarhar> noamr: connecting it with command invokers etc
15:31:02 <jarhar> noamr: you can invoke opening a dialog by changing the url
15:31:08 <zcorpan> q+
15:31:12 <jarhar> noamr: if a url has settings in it, you could invoke opening the settings dialog
15:31:24 <jarhar> noamr: so you can do it with an a element instead of a command invoker
15:31:53 <jarhar> noamr: saying that for a particular route, youre going to replace history by default instead of push history
15:32:13 <jarhar> noamr: say you have a bunch of pages you dont wnat history for, for all these routes i dont want history
15:32:20 <jarhar> noamr: i just want to intercept it but nothign changed except style
15:32:43 <jarhar> noamr: you can say im just intercepting based on this route, and then you dont have to intercept all  the navigations
15:33:03 <jarhar> keithamus: one thing that gives me pause here is this feels a bit like a good opportunity for devs to accidentally soft lock people
15:33:30 <jarhar> keithamus: if a type a route and then im matching a whole bunch of routes, users who land on that page will struggle to get off of it. if i link to an external resource, users who have it cached its going to cause some breakages
15:33:40 <jarhar> keithamus: i think there was this problem with application manifest and far future expires
15:33:46 <jarhar> keithamus: its a bit concerning, but its just a thing to keep an eye on
15:34:13 <jarhar> noamr: you can do that today by accidentally with the navigation api or by clickjacking
15:34:44 <jarhar> noamr: this can prevent some of these problems. if you have a navigation api with an intercept, and you have a bug in the intercept, like a js error, that could also happen
15:34:48 <jarhar> noamr: here you dont have js errors
15:35:07 <jarhar> noamr: theres actually some cases where this improves, and other cases where it makes interception easiser
15:35:13 <cwilso> ack next
15:35:33 <jarhar> zcorpan: i have two questions. one is, is there a desire to have an external file as the route map, similar to how you can have a speculation rule
15:35:39 <jarhar> noamr: nice to have, but doesnt need to be
15:35:52 <jarhar> zcorpan: is there overlap with speculation rules, would it make sense to combine them?
15:36:16 <jarhar> noamr: we did look at that, there is an overlap in two places, one is it uses url patterns, the combinator syntax could be similar
15:36:28 <jarhar> noamr: speculation rules url pattern is one aspect of it, its really about link matching
15:36:37 <jarhar> noamr: you can link match with css selector or url pattern
15:37:00 <jarhar> noamr: speculation rules overlap is not too big, when it comes down to it the only overlap is url pattern
15:37:08 <jarhar> noamr: more overlap with service worker static routing
15:37:15 <jarhar> noamr: you can probably route match based on http method for example
15:37:48 <jarhar> noamr: you want your speculation rules be as close as possible to the head because they can be read by url bar, so something that needs to be very declarative and meta-ish
15:38:03 <jarhar> noamr: we want to be as close as static routing is to speculation rules
15:38:26 <jarhar> zcorpan: wondering if people end up using the same url patterns in both places, maybe they want to use the named routes in speculation rules for example
15:38:31 <jarhar> noamr: that would be cool
15:38:42 <jarhar> noamr: same way you can use a selector or url pattern in speculation rules you could use a route name
15:38:54 <jarhar> noamr: for complexity, the bsaeline is just giving names to url patterns
15:39:00 <jarhar> noamr: the same way we give names to imports
15:39:10 <jarhar> noamr: probably the complexity i would start with, without combinators
15:39:19 <jarhar> noamr: the rest of the complexity would be in css
15:39:34 <jarhar> noamr: if we wanted to use those names in other places, we could pass those names to the service worker and the speculation rules
15:39:43 <jarhar> noamr: this is the initial complexity in html
15:40:08 <jarhar> zcorpan: we could use html syntax for these, for exeample using link elements with attributes instead of json. idk if that works better or not
15:40:23 <jarhar> zcorpan: one link element per url pattern, or name
15:40:41 <jarhar> fantasai: i think thats not going to work because link has - theres a lot of things that are going to get built on top of this which might not match the syntax of the link element
15:41:03 <jarhar> fantasai: tha twouldnt work well for externalizing the route map, because you dont want to load 150 route patterns on every page, it should be an external file
15:41:23 <jarhar> fantasai: i do think that the syntax as json is kind of noisy and hard to read, maybe we could reuse css syntax even if it isnt actually css
15:41:41 <jarhar> fantasai: you could use a bunch of at rules and conform to css syntax
15:41:51 <jarhar> fantasai: the arguments can reuse benefits of flexibility of css syntax
15:41:56 <jarhar> fantasai: or some other core syntax
15:42:07 <jarhar> fantasai: its noisy and doesnt allow a lot of tailoring for humans to read and write
15:42:21 <jarhar> noamr: im not against it and its in the issue, it would be a first
15:42:29 <jarhar> fantasai: i think its overdue for css syntax to be used for other things
15:42:48 <jarhar> noamr: i wanted to leave space for next topic too
15:43:09 <jarhar> noamr: what i wanted to get here, i want to spec this in css and make this an actual html thing
15:43:24 <dbaron> I think CSS syntax can be bad because it requires a lot of custom parsing and object model (which is then inconsistent between similar things).
15:43:34 <jarhar> noamr: what do people see as blocking from doing that or next steps? id like to get to drafting this in css conditionals or anywhere else, or a whatwg stage 0/1 whatever
15:43:57 <fantasai> dbaron, doesn't need to use CSSOM. It can load directly into a JS object, same as it would if it were any other syntax.
15:44:15 <jarhar> cwilso: everything starts at stage 0, stage 1 means that were moving it to something were discussing. it seems like based on the feedback we are at stage 1
15:44:23 <jarhar> cwilso: does anyone object to moving this to stage 1?
15:44:34 <jarhar> noamr: do you have feedback from developers that this new pattern is something they would use?
15:44:39 <jarhar> ^ was keith, not noam
15:44:49 <jarhar> noamr: yes, from people using view transitions
15:45:00 <jarhar> keithamus: have you had feedback from anyone that this would not be useful for them?
15:45:01 <dbaron> fantasai, but there's also sometimes a big advantage to people knowing what the mapping is just from looking at it
15:45:10 <zcorpan> s/noamr: do you have feedback/keithamus: do you have feedback/
15:45:27 <jarhar> noamr: the kind of objections or less positive views we got about this was about whether this replaces frameworks, or does this work in a context if you already have a router from a framework and does this collide with that?
15:45:47 <jarhar> noamr: most of that is about the later aspect of it, does this do your interception and your patch things by itself, and less baout the styling bit
15:46:15 <jarhar> noamr: lets look at this as a ui thing first that gives you instant reactions to route changes etc, that has been received positively
15:46:24 <jarhar> noamr: from there, we can see if we can build on top of it
15:46:30 <jarhar> noamr: we can check if it feels right at that point
15:46:51 <jarhar> cwilso: did anyone else want to say support or opposition to stage 1?
15:47:17 <jarhar> keithamus: i am supportive of this, it seems like a useful pattern, just want to make sure that web devs agree
15:47:37 <jarhar> cwilso: sounds like we can move it to stage 1
15:47:45 <jarhar> noamr: with css, what would be next stage to have a draft for it?
15:48:34 <jarhar> fantasai: write up a draft, and mark it as an unofficial draft, and then ask the wg about making it an official editors draft
15:48:47 <jarhar> fantasai: that way theres somethign concrete to point to, and say whether this is something we want to adopt
15:49:00 <jarhar> dbaron: the other question is whether it goes in a separate draft or if it goes in something like conditional 4
15:49:15 <jarhar> fantasai: yeah it might end up merging in, but lets start with an unofficial draft because this is a big chunk of functionality
15:49:23 <jarhar> fantasai: then we can decide if its a separate module or not
15:49:34 <dbaron> (or maybe I meant 5?)
15:49:41 <cwilso> topic: w3c/csswg-drafts#12510
15:49:58 <jarhar> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12510
15:49:58 <github-bot> Topic: [css-forms-1] UA styles for base appearance listbox select elements
15:49:58 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12510.
15:49:58 <noamr> scribe+
15:50:33 <noamr> jarhar:we've discussed this a few times already, I want to do base appearance for base appearance listbox select elements
15:50:43 <noamr> jarhar: I have a proposed UA style
15:50:57 <noamr> jarhar: 5 different rules, see in the issue
15:51:17 <noamr> https://github.com/w3c/csswg-drafts/issues/12510#issuecomment-3254406663
15:51:31 <noamr> fantasai: what is the display type for the popup display?
15:51:40 <noamr> fantasai: for the picker
15:52:06 <noamr> fantasai: it should be consistent between the two
15:52:11 <noamr> jarhar: display:block
15:52:19 <noamr> fantasai: cool
15:53:00 <zcorpan> q+
15:53:02 <fantasai> emilio: Default for overflow-inline is hidden, in Gecko
15:53:33 <cwilso> ack fantasai
15:53:50 <noamr> jarhar: I don't remember the default, I think there was overflow-inline:auto from luke, hidden is not ideal, not sure how prevalent it would be
15:54:01 <noamr> emilio: inline-block would shrinkwrap
15:54:21 <noamr> fantasai: a lot of people would resize this. not unusual for the listbox
15:54:25 <fantasai> Listboxes: https://bugs.webkit.org/query.cgi?format=advanced
15:54:43 <noamr> emilio: should we use the overflow shorthand
15:54:48 <noamr> emilio: unlikely to matter
15:55:03 <noamr> fantasai: in a lot of cases people would expect clipping or ellipsis
15:55:21 <cwilso> ack next
15:55:39 <noamr> zcorpan: the spec doesn't currently say much in the listbox case. is this just for base appearance?
15:55:47 <noamr> jarhar: base appearance
15:55:59 <noamr> emilio: it seems to match non-base appearance axcept for colors\
15:56:45 <noamr> zcorpan: some things cannot be explained by CSS
15:57:16 <noamr> emilio: the thing that can't be explained by CSS are the sizing behavior
15:57:27 <noamr> emilio: the rest is not much different
15:57:53 <noamr> emilio: I think you can't currently create an overflow:visible behavior
15:58:20 <noamr> emilio: do we want the size attribute to work with appearance:base
15:58:40 <noamr> jarhar: based on the previous discussions we want to ignore the size attribute and let it grow vertically
15:58:56 <noamr> fantasai: wouldn't they often want the kind of sizing of the native size attribute?
15:59:20 <noamr> dbaron: it's more complex because there is a math expression with a LH value and a px value for the touch-target.
15:59:40 <noamr> dbaron: we should be careful with overflow values that are incompatible across vertical/horizontal axes
15:59:49 <keithamus> q+
16:00:25 <noamr> dbaron: e.g. overflow-block: auto; overflow-inline: visible, they will affect each other
16:00:42 <cwilso> ack next
16:02:46 <jarhar> zakim, end meeting
16:02:46 <Zakim> As of this point the attendees have been noamr
16:02:48 <Zakim> RRSAgent, please draft minutes v2
16:02:49 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/18-css-minutes.html Zakim
16:02:56 <Zakim> I am happy to have been of service, jarhar; please remember to excuse RRSAgent.  Goodbye
16:02:56 <Zakim> Zakim has left #css
16:58:27 <jamesn> jamesn has joined #css
16:58:58 <Adam_Page> Adam_Page has joined #css
18:04:43 <una> una has joined #css