- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 18 Sep 2025 15:49:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `OpenUI`. <details><summary>The full IRC log of that discussion</summary> <cwilso> Topic: OpenUI<br> <cwilso> Agenda: https://github.com/whatwg/html/issues/11625<br> <jarhar> noamr: its been on some sort of slow burning for the last 2 years since we started cross document view transitions<br> <jarhar> noamr: its not only a view transitions issue, but that was the driving force behind it<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/12594<br> <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<br> <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<br> <jarhar> noamr: in order to do this in frameworks you need this kind of code<br> <jarhar> noamr: you need to wrap the a element in a "nav link"<br> <jarhar> noamr: you have to wrap all your links to get this pending ui<br> <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<br> <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<br> <jarhar> noamr: *points out things in code examples*<br> <fantasai> What does ":remote-link" mean here?<br> <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<br> <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<br> <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<br> <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<br> <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<br> <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<br> <jarhar> noamr: some people are doing that already<br> <jarhar> noamr: here is a demo that some css teachers were using<br> <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<br> <jarhar> noamr: that never felt right to me, that a stylesheet should know the navigation url patterns, those can often change<br> <jarhar> noamr: something so style aware, feels like html or the document should know about it than a stylesheet<br> <jarhar> noamr: having this can open opportunities in the future that are about ui, not specifically about styling<br> <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<br> <jarhar> noamr: maybe we can allow scrolling to an element based on path, so that the url change can also apply<br> <jarhar> noamr: we can have all kinds of interceptions, spa style processes done in the browser rather than in userland<br> <jarhar> noamr: if all it does is change style, then maybe you dont need code that intercepts the navigation event<br> <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<br> <jarhar> noamr: the way we thought to have a script type that is like json, call it routemap<br> <jarhar> noamr: the main basic thing it does is naming url patterns or combinations of url patterns, so they can be used in css<br> <jarhar> noamr: later on can be used to create those html ui navigation roles if we decide to do that<br> <jarhar> noamr: the naming and combination we try as much as possible to be consistent with service worker static routing<br> <jarhar> noamr: this cant be done in a service worker because navigation is done in the window<br> <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?<br> <jarhar> noamr: its one of the alternatives. you mean have it as an html thing but css as the definition language?<br> <jarhar> keithamus: idk why we have to specify the patterns and roles in html if you also need them in css<br> <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<br> <jarhar> noamr: the precedent for something defined in css but accessible from html is using fonts in canvas, for example<br> <jarhar> noamr: but it feels a bit different, routes seem more like an html native thing than a style native thing<br> <jarhar> noamr: using css as a DSL for it seems ok<br> <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<br> <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?<br> <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.<br> <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<br> <jarhar> noamr: a bit like how you can name modules in html with importmap<br> <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<br> <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<br> <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<br> <jarhar> noamr: if you initiated a navigation and its not yet committed , then youre navigating to something<br> <jarhar> noamr: at that point, youre also navigating from something<br> <jarhar> noamr: navigation transition object in html is a very good proxy for that<br> <jarhar> noamr: theres a from and a to<br> <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<br> <jarhar> annevk: isnt navigation often quite quick? i guess you can maybe observe some of it<br> <jarhar> noamr: it could be, but for things like view transitions, one frame is enough<br> <jarhar> noamr: for entry animatin between routes, it doesnt matter if its quick<br> <jarhar> noamr: some navigations are not quick, and you want to show some kind of exit in a safe way<br> <jarhar> noamr: we hope all navigations are quick<br> <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?<br> <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<br> <jarhar> noamr: service worker might say use cache for evertyihg, but different from styling the routes<br> <jarhar> noamr: can probably use similar syntax, but you also cant define this in a service worker<br> <jarhar> noamr: it is true that there are several places that youre routing, but idk if they can be combined in a meaningful way<br> <jarhar> fantasai: idk about service workers, but could you use your route map script in service workers as an option?<br> <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<br> <jarhar> noamr: service workers dont have html so theyd have to import this as json<br> <jarhar> noamr: server side would be able to generate both<br> <jarhar> noamr: rather than try to reuse the same file, idk its an option<br> <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<br> <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<br> <jarhar> keithamus: the naming could be convenient, if you have an article route you could define that in one place<br> <jarhar> fantasai: the remote link pseudo class, what does it mean?<br> <jarhar> noamr: we have a separate issue for it, but we currently have a local link for a link that targets the current url<br> <jarhar> noamr: the idea of remote link is that its a counterpart, its a link that targets the current url that youre navigating to<br> <jarhar> keithamus: there was a discussion about making it a pseudo fn and using a url pattern in it<br> <jarhar> keithamus: you could use the same route matching primitives<br> <jarhar> noamr: i discussed this a bit here<br> <jarhar> noamr: i didnt know about that conversation, ill look into that<br> <keithamus> https://github.com/w3c/csswg-drafts/issues/10975#issuecomment-2614013263<br> <jarhar> noamr: all those link pseudo classes can benefit from either route matching and/or inline url pattern matching, which im less sure about<br> <jarhar> noamr: not sure how much of a footgun it is<br> <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<br> <jarhar> fantasai: is remote link about whether the link is active or not? or its not pointing to this page<br> <jarhar> noamr: its the link that is targeting the url of the destination of an ongoing destination<br> <jarhar> fantasai: ok so its what :active meant in ie6<br> <jarhar> fantasai: it seems useful, im not sure remote link is a good name but im sad that definition of :active went away<br> <jarhar> noamr: it has the same semantics of a navigate event without being able to intercept it<br> <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<br> <jarhar> noamr: you basically get navigate events for browser ui back, but you cant intercept it<br> <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<br> <jarhar> annevk: i wonder if there some other thing this could be used for<br> <jarhar> annevk: its a lot of complexity for not that much functionality<br> <jarhar> annevk: i wonder if it can be used for more things, like the navigation api could use these routes in some way<br> <jarhar> noamr: its there in the explainer, theres a lot of them, some people said its too much<br> <jarhar> noamr: we put the css thing as first, but the current use case we envision for that<br> <jarhar> noamr: connecting it with command invokers etc<br> <jarhar> noamr: you can invoke opening a dialog by changing the url<br> <zcorpan> q+<br> <jarhar> noamr: if a url has settings in it, you could invoke opening the settings dialog<br> <jarhar> noamr: so you can do it with an a element instead of a command invoker<br> <jarhar> noamr: saying that for a particular route, youre going to replace history by default instead of push history<br> <jarhar> noamr: say you have a bunch of pages you dont wnat history for, for all these routes i dont want history<br> <jarhar> noamr: i just want to intercept it but nothign changed except style<br> <jarhar> noamr: you can say im just intercepting based on this route, and then you dont have to intercept all the navigations<br> <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<br> <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<br> <jarhar> keithamus: i think there was this problem with application manifest and far future expires<br> <jarhar> keithamus: its a bit concerning, but its just a thing to keep an eye on<br> <jarhar> noamr: you can do that today by accidentally with the navigation api or by clickjacking<br> <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<br> <jarhar> noamr: here you dont have js errors<br> <jarhar> noamr: theres actually some cases where this improves, and other cases where it makes interception easiser<br> <cwilso> ack next<br> <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<br> <jarhar> noamr: nice to have, but doesnt need to be<br> <jarhar> zcorpan: is there overlap with speculation rules, would it make sense to combine them?<br> <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<br> <jarhar> noamr: speculation rules url pattern is one aspect of it, its really about link matching<br> <jarhar> noamr: you can link match with css selector or url pattern<br> <jarhar> noamr: speculation rules overlap is not too big, when it comes down to it the only overlap is url pattern<br> <jarhar> noamr: more overlap with service worker static routing<br> <jarhar> noamr: you can probably route match based on http method for example<br> <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<br> <jarhar> noamr: we want to be as close as static routing is to speculation rules<br> <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<br> <jarhar> noamr: that would be cool<br> <jarhar> noamr: same way you can use a selector or url pattern in speculation rules you could use a route name<br> <jarhar> noamr: for complexity, the bsaeline is just giving names to url patterns<br> <jarhar> noamr: the same way we give names to imports<br> <jarhar> noamr: probably the complexity i would start with, without combinators<br> <jarhar> noamr: the rest of the complexity would be in css<br> <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<br> <jarhar> noamr: this is the initial complexity in html<br> <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<br> <jarhar> zcorpan: one link element per url pattern, or name<br> <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<br> <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<br> <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<br> <jarhar> fantasai: you could use a bunch of at rules and conform to css syntax<br> <jarhar> fantasai: the arguments can reuse benefits of flexibility of css syntax<br> <jarhar> fantasai: or some other core syntax<br> <jarhar> fantasai: its noisy and doesnt allow a lot of tailoring for humans to read and write<br> <jarhar> noamr: im not against it and its in the issue, it would be a first<br> <jarhar> fantasai: i think its overdue for css syntax to be used for other things<br> <jarhar> noamr: i wanted to leave space for next topic too<br> <jarhar> noamr: what i wanted to get here, i want to spec this in css and make this an actual html thing<br> <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).<br> <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<br> <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.<br> <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<br> <jarhar> cwilso: does anyone object to moving this to stage 1?<br> <jarhar> noamr: do you have feedback from developers that this new pattern is something they would use?<br> <jarhar> ^ was keith, not noam<br> <jarhar> noamr: yes, from people using view transitions<br> <jarhar> keithamus: have you had feedback from anyone that this would not be useful for them?<br> <dbaron> fantasai, but there's also sometimes a big advantage to people knowing what the mapping is just from looking at it<br> <zcorpan> s/noamr: do you have feedback/keithamus: do you have feedback/<br> <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?<br> <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<br> <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<br> <jarhar> noamr: from there, we can see if we can build on top of it<br> <jarhar> noamr: we can check if it feels right at that point<br> <jarhar> cwilso: did anyone else want to say support or opposition to stage 1?<br> <jarhar> keithamus: i am supportive of this, it seems like a useful pattern, just want to make sure that web devs agree<br> <jarhar> cwilso: sounds like we can move it to stage 1<br> <jarhar> noamr: with css, what would be next stage to have a draft for it?<br> <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<br> <jarhar> fantasai: that way theres somethign concrete to point to, and say whether this is something we want to adopt<br> <jarhar> dbaron: the other question is whether it goes in a separate draft or if it goes in something like conditional 4<br> <jarhar> fantasai: yeah it might end up merging in, but lets start with an unofficial draft because this is a big chunk of functionality<br> <jarhar> fantasai: then we can decide if its a separate module or not<br> <dbaron> (or maybe I meant 5?)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12594#issuecomment-3308242696 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 18 September 2025 15:49:45 UTC