Meeting minutes
noamr: i put up an explainer and a couple of issues for this, and presented at csswg f2f a couple weeks ago
OpenUI
noamr: its been on some sort of slow burning for the last 2 years since we started cross document view transitions
noamr: its not only a view transitions issue, but that was the driving force behind it
<dbaron> github: w3c/
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
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
noamr: in order to do this in frameworks you need this kind of code
noamr: you need to wrap the a element in a "nav link"
noamr: you have to wrap all your links to get this pending ui
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
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
noamr: *points out things in code examples*
<fantasai> What does ":remote-link" mean here?
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
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
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
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
noamr: people want view transitions to start immediately, but we dont have the end state because we didn't load the new document yet
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
noamr: some people are doing that already
noamr: here is a demo that some css teachers were using
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
noamr: that never felt right to me, that a stylesheet should know the navigation url patterns, those can often change
noamr: something so style aware, feels like html or the document should know about it than a stylesheet
noamr: having this can open opportunities in the future that are about ui, not specifically about styling
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
noamr: maybe we can allow scrolling to an element based on path, so that the url change can also apply
noamr: we can have all kinds of interceptions, spa style processes done in the browser rather than in userland
noamr: if all it does is change style, then maybe you dont need code that intercepts the navigation event
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
noamr: the way we thought to have a script type that is like json, call it routemap
noamr: the main basic thing it does is naming url patterns or combinations of url patterns, so they can be used in css
noamr: later on can be used to create those html ui navigation roles if we decide to do that
noamr: the naming and combination we try as much as possible to be consistent with service worker static routing
noamr: this cant be done in a service worker because navigation is done in the window
keithamus: is there a good reason to have the route map defined in html rather than using css as the language to describe this?
noamr: its one of the alternatives. you mean have it as an html thing but css as the definition language?
keithamus: idk why we have to specify the patterns and roles in html if you also need them in css
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
noamr: the precedent for something defined in css but accessible from html is using fonts in canvas, for example
noamr: but it feels a bit different, routes seem more like an html native thing than a style native thing
noamr: using css as a DSL for it seems ok
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
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?
<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.
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
noamr: a bit like how you can name modules in html with importmap
annevk: could you explain more of the basics of how this routing works? im not sure i understand when the states apply to elements
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
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
noamr: if you initiated a navigation and its not yet committed , then youre navigating to something
noamr: at that point, youre also navigating from something
noamr: navigation transition object in html is a very good proxy for that
noamr: theres a from and a to
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
annevk: isnt navigation often quite quick? i guess you can maybe observe some of it
noamr: it could be, but for things like view transitions, one frame is enough
noamr: for entry animatin between routes, it doesnt matter if its quick
noamr: some navigations are not quick, and you want to show some kind of exit in a safe way
noamr: we hope all navigations are quick
annevk: we already have some kind of routing with service workers, and so now you have to duplicate that all over your code base?
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
noamr: service worker might say use cache for evertyihg, but different from styling the routes
noamr: can probably use similar syntax, but you also cant define this in a service worker
noamr: it is true that there are several places that youre routing, but idk if they can be combined in a meaningful way
fantasai: idk about service workers, but could you use your route map script in service workers as an option?
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
noamr: service workers dont have html so theyd have to import this as json
noamr: server side would be able to generate both
noamr: rather than try to reuse the same file, idk its an option
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
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
keithamus: the naming could be convenient, if you have an article route you could define that in one place
fantasai: the remote link pseudo class, what does it mean?
noamr: we have a separate issue for it, but we currently have a local link for a link that targets the current url
noamr: the idea of remote link is that its a counterpart, its a link that targets the current url that youre navigating to
keithamus: there was a discussion about making it a pseudo fn and using a url pattern in it
keithamus: you could use the same route matching primitives
noamr: i discussed this a bit here
noamr: i didnt know about that conversation, ill look into that
<keithamus> w3c/
noamr: all those link pseudo classes can benefit from either route matching and/or inline url pattern matching, which im less sure about
noamr: not sure how much of a footgun it is
fantasai: local link is just testing the url, its equivalent to checking the href, its not about whether the link is active or not
fantasai: is remote link about whether the link is active or not? or its not pointing to this page
noamr: its the link that is targeting the url of the destination of an ongoing destination
fantasai: ok so its what :active meant in ie6
fantasai: it seems useful, im not sure remote link is a good name but im sad that definition of :active went away
noamr: it has the same semantics of a navigate event without being able to intercept it
<dbaron> fantasai, there's also a subtle distinction about two different possibilities for the link navigating pseudo-class that I mentioned in WICG/
noamr: you basically get navigate events for browser ui back, but you cant intercept it
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
annevk: i wonder if there some other thing this could be used for
annevk: its a lot of complexity for not that much functionality
annevk: i wonder if it can be used for more things, like the navigation api could use these routes in some way
noamr: its there in the explainer, theres a lot of them, some people said its too much
noamr: we put the css thing as first, but the current use case we envision for that
noamr: connecting it with command invokers etc
noamr: you can invoke opening a dialog by changing the url
noamr: if a url has settings in it, you could invoke opening the settings dialog
noamr: so you can do it with an a element instead of a command invoker
noamr: saying that for a particular route, youre going to replace history by default instead of push history
noamr: say you have a bunch of pages you dont wnat history for, for all these routes i dont want history
noamr: i just want to intercept it but nothign changed except style
noamr: you can say im just intercepting based on this route, and then you dont have to intercept all the navigations
keithamus: one thing that gives me pause here is this feels a bit like a good opportunity for devs to accidentally soft lock people
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
keithamus: i think there was this problem with application manifest and far future expires
keithamus: its a bit concerning, but its just a thing to keep an eye on
noamr: you can do that today by accidentally with the navigation api or by clickjacking
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
noamr: here you dont have js errors
noamr: theres actually some cases where this improves, and other cases where it makes interception easiser
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
noamr: nice to have, but doesnt need to be
zcorpan: is there overlap with speculation rules, would it make sense to combine them?
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
noamr: speculation rules url pattern is one aspect of it, its really about link matching
noamr: you can link match with css selector or url pattern
noamr: speculation rules overlap is not too big, when it comes down to it the only overlap is url pattern
noamr: more overlap with service worker static routing
noamr: you can probably route match based on http method for example
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
noamr: we want to be as close as static routing is to speculation rules
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
noamr: that would be cool
noamr: same way you can use a selector or url pattern in speculation rules you could use a route name
noamr: for complexity, the bsaeline is just giving names to url patterns
noamr: the same way we give names to imports
noamr: probably the complexity i would start with, without combinators
noamr: the rest of the complexity would be in css
noamr: if we wanted to use those names in other places, we could pass those names to the service worker and the speculation rules
noamr: this is the initial complexity in html
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
zcorpan: one link element per url pattern, or name
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
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
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
fantasai: you could use a bunch of at rules and conform to css syntax
fantasai: the arguments can reuse benefits of flexibility of css syntax
fantasai: or some other core syntax
fantasai: its noisy and doesnt allow a lot of tailoring for humans to read and write
noamr: im not against it and its in the issue, it would be a first
fantasai: i think its overdue for css syntax to be used for other things
noamr: i wanted to leave space for next topic too
noamr: what i wanted to get here, i want to spec this in css and make this an actual html thing
<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).
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
<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.
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
cwilso: does anyone object to moving this to stage 1?
keithamus: do you have feedback from developers that this new pattern is something they would use?
^ was keith, not noam
noamr: yes, from people using view transitions
keithamus: have you had feedback from anyone that this would not be useful for them?
<dbaron> fantasai, but there's also sometimes a big advantage to people knowing what the mapping is just from looking at it
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?
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
noamr: lets look at this as a ui thing first that gives you instant reactions to route changes etc, that has been received positively
noamr: from there, we can see if we can build on top of it
noamr: we can check if it feels right at that point
cwilso: did anyone else want to say support or opposition to stage 1?
keithamus: i am supportive of this, it seems like a useful pattern, just want to make sure that web devs agree
cwilso: sounds like we can move it to stage 1
noamr: with css, what would be next stage to have a draft for it?
fantasai: write up a draft, and mark it as an unofficial draft, and then ask the wg about making it an official editors draft
fantasai: that way theres somethign concrete to point to, and say whether this is something we want to adopt
dbaron: the other question is whether it goes in a separate draft or if it goes in something like conditional 4
fantasai: yeah it might end up merging in, but lets start with an unofficial draft because this is a big chunk of functionality
fantasai: then we can decide if its a separate module or not
<dbaron> (or maybe I meant 5?)
w3c/csswg-drafts#12510
github-bot, take up w3c/
[css-forms-1] UA styles for base appearance listbox select elements
<github-bot> OK, I'll post this discussion to https://
jarhar: we've discussed this a few times already, I want to do base appearance for base appearance listbox select elements
jarhar: I have a proposed UA style
jarhar: 5 different rules, see in the issue
w3c/
fantasai: what is the display type for the popup display?
fantasai: for the picker
fantasai: it should be consistent between the two
jarhar: display:block
fantasai: cool
<fantasai> emilio: Default for overflow-inline is hidden, in Gecko
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
emilio: inline-block would shrinkwrap
fantasai: a lot of people would resize this. not unusual for the listbox
<fantasai> Listboxes: https://
emilio: should we use the overflow shorthand
emilio: unlikely to matter
fantasai: in a lot of cases people would expect clipping or ellipsis
zcorpan: the spec doesn't currently say much in the listbox case. is this just for base appearance?
jarhar: base appearance
emilio: it seems to match non-base appearance axcept for colors\
zcorpan: some things cannot be explained by CSS
emilio: the thing that can't be explained by CSS are the sizing behavior
emilio: the rest is not much different
emilio: I think you can't currently create an overflow:visible behavior
emilio: do we want the size attribute to work with appearance:base
jarhar: based on the previous discussions we want to ignore the size attribute and let it grow vertically
fantasai: wouldn't they often want the kind of sizing of the native size attribute?
dbaron: it's more complex because there is a math expression with a LH value and a px value for the touch-target.
dbaron: we should be careful with overflow values that are incompatible across vertical/horizontal axes
dbaron: e.g. overflow-block: auto; overflow-inline: visible, they will affect each other