Eric Meyer: Hello. I'm Eric Meyer, a developer advocate at Igalia.
Brian Kardell: And I am Brian Kardell, also a developer advocate at Igalia.
Eric Meyer: And, this week, we're going to talk about the recent CSS Working Group Face-to-Face meeting. We've done an episode like this before and one of the reasons that we do these episodes is that, when the Working Group gets together for a few days, they discuss a lot of things. And, often, stuff that works best at a whiteboard with a bunch of people in a room are saved for these face-to-face meetings, and that's sometimes where fairly important things get worked out. Everybody in the room figuring out, 'Okay, if we do this, then there's this effect, and then if we do the other thing, there's that effect,' and blah, blah, blah. So we thought we'd review the high points of the big decisions that were made to let everyone out there in Listener Land know what's going on with the Working Group.
Brian Kardell: Yeah, it's fun to recap these, because there's a little bit of... I think people don't really know what happens in them and I think there's not a lot of people who are super well-positioned to give a breakdown, so let's do it.
Eric Meyer: Yeah. And Brian and I are both members of the Working Group as Igalia representatives. We are not the only ones, Oriol from Igalia was there physically in person.
Brian Kardell: He's the editor on CSS Grid.
Eric Meyer: Yeah, Stephen Chenney also from Igalia was there remotely as well, and a bunch of people from Google, Apple, there was a representative from Mozilla. I can't remember if anyone showed up in person from Microsoft, but they were definitely on the call.
Brian Kardell: Yeah, that's an interesting thing, too, that before I got involved with CSS Working Group about... I can't believe it's been a decade already I've been on CSS Working Group, but before I got involved, I didn't know what one of these was like. And I don't know that people talk about them so much like, 'What is it like, the size and the composition?' So maybe we can say that we try to meet in person four times a year and we always have had ability for remote participation somehow. Sometimes it's not been so good, but since COVID, it's gotten a lot better. People really appreciate the remote.
Eric Meyer: Yeah.
Brian Kardell: So what is it like? Let's talk about that real quick.
Eric Meyer: So what is it like, Brian? What's it like in person?
Brian Kardell: So boring, it's so boring. No, no, no. So it's usually three, sometimes four days. We try to rotate where we meet. This one was hosted at Google in California, and we'll have another one in June that will be hosted at Igalia. Yay.
Eric Meyer: Yep, in Spain. A Coruna.
Brian Kardell: So we try to meet four times a year, but it relies on people being able to agree on times and places and then finding a host. It's not as easy as you would think.
Eric Meyer: Yeah.
Brian Kardell: It's not like the W3C has offices all around the world where you could just be like, 'We're going to go crash this office,' and just rotate around that way. It's more like member companies... A few times a year, we say, 'Okay, who wants to... Could Apple do it? Could Google do it? Could Adobe do it?'
Eric Meyer: Right? 'Could Microsoft do it?'
Brian Kardell: Yeah, right.
Eric Meyer: 'Could Igalia do it? Could,' whoever. Right, because the host has to feed people during the day. Doesn't necessarily have to feed them 24/7, but there's a breakfast service and a lunch service and there's coffee for people to be able to stay awake if they do find a particular conversation not of interest.
Brian Kardell: Yeah, and when Igalia hosted, we had childcare even.
Eric Meyer: Yeah, it is a little bit of a commitment. Not to mention you need to have access to facilities that will host, let's say, 20 people in a room and give decent remote access, so that the people who are remote can hear what's being discussed. And, even more ideally, if there's going to be work at the whiteboard, that the people who are remote can see the whiteboard.
Brian Kardell: Yeah. Which was a problem for the beginning of this one.
Eric Meyer: Yeah, the first day, there was a little bit of a problem with that, but they had it sorted out by the second day. So let's talk about some of the big points. There was a big discussion about colors, which I thought was both interesting and also, at the same time, I was like, 'Wow, how did we even get here?'
Brian Kardell: It's fascinating how spicy it got, right?
Eric Meyer: Yeah, it did get a little spicy. Not in a people attacking each other personally kind of way, but just someone would explain their position and then someone else would say, 'There were things that were factually incorrect in what you just said,' and then they would explain and why they felt that and the other person would say, 'You know, wrong.' Yeah, it got a little spicy, but what fascinated me was we've gotten to a point now in CSS with the newer color syntaxes, like OKLCH and OKLAB and some others where it's very easy to specify a color that's outside of the display range of common monitors or, for that matter, you can specify color points that are outside the range of human visual perception. And that of the point where I was like, 'Wait, what are we doing?' Where you can specify colors that are, to the human eye, literally impossible.
Brian Kardell: It would be infrared?
Eric Meyer: I don't know.
Brian Kardell: We're tying about some things here that are... There are people who have masters and doctorates and a decade, two decades worth of experience in colors.
Eric Meyer: Right.
Brian Kardell: These are people who just... They're dedicated so much of their life to colors and understanding colors, so they're having conversations that are a little bit outside my-
Eric Meyer: A little about outside our range of understanding, but I mean, what the discussion was really about was, 'Okay, so if you define a color that can't be displayed, you've defined a color that not even Display P3 can handle, because it's just so far outside of that color space, then what do browsers do? How do they,' quote, unquote, ''Clip that'? How do they constrain that? What is the color that should be shown that the display can produce?' And depending... There was an example that showed, 'If you do it this way, you get this color, but if you do it this other way, you get this other color,' and they look very different. They're both maybe shades of purple, but one is light dusky purple and the other one is super intense, close to neon purple, and which one is the one that browser should do? And that was part of what got contentious was some people were saying, 'Well, you should do this,' and other people say, 'Well, we should do that.' Each had very defensible reasons for why they thought that, but they didn't agree.
Brian Kardell: Yeah.
Eric Meyer: And it's fascinating in a way. I mean, for a real long time on the web, we were used to... Well, for a real long time, we had 216 colors that wouldn't get dithered and that was what we dealt with. That was part of the longer stretch of time where computers had basically what we now call SRGB display and you could only define RGB colors. Color, syntaxes were basically constrained by the hardware of the time, but now there's been a lot of work done to have colors be device independent, so you're supposed to get the same color, basically, regardless of the device. The point being that using one of these newer color spaces like OKLAB, or whatever, I want this super intense green, I want the green that they put on ambulances. You might then send that page to a monitor that can't produce that exact shade of green, so now what?
Brian Kardell: Yeah. I mean, I wrote this article on unlocking colors in 2019, I think, and I was having a conversation with, I think, Chris Coyer and Dave Rupert trying to explain why I was excited about this and why I thought it was important. I was trying to explain and I was giving analogies. Like, 'Okay, so when I first got started with computers, you had your choice of an amazing array of two colors, black and white or green and white.'
Eric Meyer: Or amber and black.
Brian Kardell: Yeah, amber was mine, I had amber. So green and black or amber and black or some were blue and black, but yeah, binary. It was binary, and so-
Eric Meyer: Pretty much, yeah.
Brian Kardell: That works great if you can reduce everything down to a binary, but most things in life are somewhere in the range. So there's not really a good way to make a binary representation of an image that looks really a lot like the image. I mean, it's going to look pretty bad. And then we got to 16 colors and then we got to 64 colors, 256 colors. Every time, you're able to make approximations somehow, but the way that you do those approximations is really fascinating. The way that you store the information and the way that you recall it to the screen, and then the fact that people always have different screens. So it's always been a matter of, 'How do you store the information, how do you do the math?' And then the fact that everybody's set up and hardware capabilities even is different, and so how do you display something that looks like the designer intended? I like to think about it like Pantone cards, right? A lot of people have seen... Or when you go to the paint store and you go pick out a bunch of swatches and then you bring them home, and you're like, 'Wow, that looks nothing like I thought it would look in my room, in my lighting.' And then you pick a color and then you paint with it and you start painting and you're like, 'Wow, that looks so much different than I imagined it would like,' right?
Eric Meyer: Did I make a mistake?
Brian Kardell: Yeah, or did they make a mistake when they mixed it? Or something, right?
Eric Meyer: Yeah.
Brian Kardell: And so when this gets into these... Especially super saturated colors, very intense colors that we couldn't do before that maybe can't even be displayed on really high-end equipment, there's clipping that occurs, and how do you do that? And it's going to look probably very much not like you intended. We're way down into the weeds on colors.
Eric Meyer: Yeah, no, but that's what the discussion was, it was way down into the weeds on colors. And it reminds me a little bit of the act of translation. I've been reading RF Kuang's Babel, which was a fantasy-type novel that was published a couple years ago. It's basically about translation and the act of translation from one language to another and what gets lost and how do you deal with the fact that, if I'm translating from German, there are words in German that there's no equivalent word in English and it's not even easy, necessarily in English, to express exactly what that word encapsulates, and so if you're going to translate poetry, for example, do you get it technically correct, even though that sounds maybe really weird, or do you try to make it true to the spirit of the original, even if you have to really change the phrasing that's used? And there's no right answer and this feels the same to me. There's a color that cannot be expressed in this user's environment. What is the most faithful, quote, unquote, 'Recreation' of what the author was trying to do? I think it basically came down to, 'We don't have a resolution yet.'
Brian Kardell: Yeah. And we have to move on, because we're only on the very first thing, but there were other aspects of this that had to do with... It's not just, 'Is this good or is this bad?' But it's in these different cases. So these spaces, like OKLAB, OKLCH, they're very good for interpolation, right? Because as you move through the space, it's perceptual uniform, but should you use it as, 'Straight-up display this color'?
Eric Meyer: Right.
Brian Kardell: And that's maybe... You could have different opinions on those two things, basically, right? Should you use it for interpolation or should you convert to it for interpolation?
Eric Meyer: Right.
Brian Kardell: Yeah.
Eric Meyer: That was definitely part of it. I shouldn't say there were no resolutions around color, there were a few, but they weren't about this stuff. So one of them was, for example, all HSL values have to clip to non-negative numbers for the saturation. Apparently, there are situations now where maybe you can get negative saturation numbers, which I think is fascinating.
Brian Kardell: Yeah.
Eric Meyer: Apparently, the cross fade and color mix functional values had different serialization orders, so those are going to be made consistent. And, I guess, in selection pseudo-elements, author colors weren't necessarily being respected, so there was a resolution to literally put in the spec, 'If the author has supplied colors, you need to respect them in selection pseudo-elements.' These are sometimes the things that the Working Group deals with, because when a specification is written, maybe there are bits that should have been stated explicitly, but weren't, and then when somebody goes to implement, actually do an implementation of the specification, they discover, 'I followed what the spec says and now I've encountered these situations,' which are admittedly rare, but there's still this possibility and, 'What does the Working Group think should happen here?' These are the kinds of issues that often get brought to the Working Group just for clarification, really. So those are the things that happen with colors. But yes, you're right, we need to move on, because we're already some ways into this.
Brian Kardell: View transitions dominate a lot of the stuff on Monday, and it's a really interesting idea that I am really looking forward to. And I have myself put on my website the simplest version of that, which is just like a meta tag that just says, 'Go ahead, you can do this,' default animation on my site, which is cross fade in between, but it only works in, basically, Canary, I think, with the flag on, so nobody's seeing it except me and six other people probably, but I have not been following it, because we've talked about this before. How close do you follow these things? The cost of doing it's like 900 times what people will pay in the end, because you're paying attention to all the very deep details and the gross churn, and everything. So I've not been following this super closely, to be honest. A little bit of an unofficial signal to me, at least, that I should probably pay more attention to it now.
Eric Meyer: Yeah.
Brian Kardell: So I thought it was really interesting and so many details in these things as they go.
Eric Meyer: Yeah, because I mean, basically, the way view transitions work... Just to clarify a little bit, a view transition is you have a bunch of, let's say, cards. You're on Amazon, let's say. With view transitions, what you would be able to do is click on one of those card or one of those little things in the catalog listing and then it will zoom out and fill your screen and then, suddenly, you'll have a full page. And so the way that that works is, basically, the browser takes a screenshot of the page before the view transition starts and a screenshot of the final page afterwards, and then somehow blends from one to the other. And there are different ways to do it. And so that gets in. I mean, it's kind of an animation, but it's an animation between one web view and another web view instead of animations now are... You can change the color of a thing or you can change the size of a thing, but you're not switching from one page to another.
Brian Kardell: Yeah, all animations are within the dom, right?
Eric Meyer: Right.
Brian Kardell: So you have some dom that has to be in the page and also has to be displayed somehow. It needs to create a block in the first place or else you can't animate it to hold another issue that had been dragged on for years and years and years.
Eric Meyer: And they did actually talk about things like, 'Okay, so I have display block and display none, and I want to animate from one to the other. Can that be done?' And there's actually been work in that direction. But anyway, view transitions got talked about a lot, because there is a hierarchy in CSS where animations can overrule other things. They can have a higher weight, or that sort of thing, and there are events that fire, so that you can listen for them in JavaScript, or that sort of thing, or you can fire them from JavaScript to start an animation. So figuring out how view transitions, where you're literally going from one dom to another dom possibly. How does all that fit together? What is the exact timing of where these events fire and those events fire? And if something change is... It's kind of the same between the two, but it's changed in these ways, how does that get dealt with? And so there was a lot of that, but that's actually... I think it's a good signal, like you said, because it means that, instead of the discussion being, 'How conceptually is this going to work?' It's now, 'All right, we've figured out how it's supposed to work, but now we're getting down into the weeds of nitty-gritty. How exactly does this interact with these other things?'
Brian Kardell: Yeah, I think it goes to that thing that I was saying in the beginning, where it was like... I have not been following this very closely, because like everyone else, I only have so many hours in the day.
Eric Meyer: Exactly.
Brian Kardell: And so when people from multiple organizations are suddenly getting way down into the weeds... We have nine different... Maybe nine or 10 different resolutions that were made on view transitions that are getting a lot of really deep thought that's about what happens when there's an iframe and this thing is off-screen, and then you call get computed style. There's all kinds of very... People have been thinking about this deeply now and that means that they're investing the time, so it's like a signal that people are willing to invest the time as opposed to just talking about the theory and all that stuff. So, yeah, I think it's really cool, but I don't think that we should go through the nine different... They're very in the weeds.
Eric Meyer: Yeah.
Brian Kardell: I think another... Maybe the most exciting thing that happened on Monday was we agreed to start an editor's draft for CSS mixins and CSS custom functions.
Eric Meyer: Yep, this had been proposed by Miriam Suzanne, Mia as she goes on the inter tubes and who was recently a guest here. She had proposed, basically, mixin, so sort of like macros in a sense, for those who are familiar with macros. Here's this bag of stuff and then, somewhere else in the style sheet, you could say... You can point at that bag and say, 'Those things, bring those here.'
Brian Kardell: Yep, exactly.
Eric Meyer: Pretend that I copied and pasted them right here.
Brian Kardell: Yeah.
Eric Meyer: Which have been features of pre-processors for a very long time.
Brian Kardell: And here's an interesting thing, I don't care about Mixins. I'm more excited about the custom functions part, because going all the way back to the Houdini and all that, this is, again, why I have got into and why I pressed on a bunch of the things. So we have had custom functions on the list for a really long time of things that we wanted to do, and this isn't the custom functions that we started with, but if you were to rewind all the way back to 2010, or something like that, we had some ideas like TAB had a spec that was getting into some of these things. It was very, very early draft sort of thing. And Mia has put forward a better proposal to get started that would allow you to say, 'Here's a way that you can define this thing as an at-rule,' that's like, 'Here's where some complicated math happens.' And you can just give that a name and then you can use that complicated math elsewhere in your style sheet by just saying here and here are the values that you plug into the formula. And, also, the way that it's designed really opens the door for us to create custom functions of the other two kinds that, I think, we have talked about in the past that would be like... Maybe this is a worklet that you register and it can do maybe more complicated things than you could do initially with the approach that we have here. So, yeah, I'm really excited, because I think this is a way that you can extend CSS, so you could make some custom functions that really complicated and then you can just share those, which is awesome for me, because what I want is people on a tutor who just blow my mind with the things that they do to be like, 'Here's the custom function that does this thing that everybody wants to do,' and then you can just grab it and you could use it and you could be like, 'I don't need to know how to do that super complicated thing, because I know smart people.'
Eric Meyer: Right. So a basic example of a custom function would be something like... You could write a custom function that would round decimal values to two places?
Brian Kardell: Sure.
Eric Meyer: I mean, you could maybe figure out how to do now, but would take nested calcs and stuff like that, and instead, you take all those nested calcs, you put them into one place, make it a custom function, and then, from then on, you can say, 'Round two,' or maybe you can even say, 'Round value comma number of decibel places,' and it will send you back what you're looking for, which maybe there are situations where that would be super useful, but I'm trying to use it as a basic example of, 'Here's a thing you could do.' And, like you say, it could be way more complicated. You could create a custom function where you supply it a color and it returns randomly procedurally-generated snowflake, whatever. The resolution was to start an editor's draft of this, so this is still at the early stages. This is the... We've conceptually agreed that this should be part of CSS, let's have Mia, in this case, write a draft specification that we could all then look at and say, 'Well, what about this? What about that?' I did see some people say, 'Well, I can already do this in a mixin, why do I care?'
Brian Kardell: Where you get a real benefit. This is the reason that we took so long to get even variables and we didn't get variables. What we got is CSS custom properties, and we very specifically called them CSS custom properties, because they're really not the same thing as variables in a pre-processor. And there was no appetite by the CSS Working Group to just give you the thing that CSS pre-processors can do, because very frequently, minus the couple of extra bytes across the wire, it is more efficient to do it in the pre-processor, because then the CSS doesn't have to try to do it live 60 frames per second, but the reason that we did get it is because TAB came up with these, basically, custom properties that... Hey, that's the thing that you can't do in a pre-processor, because it's live. It is actually... Opens up new powers for you, because it is live.
Eric Meyer: Yeah.
Brian Kardell: And I think it's the same, especially with the custom functions, because custom functions can take a var and pass in the actual var. Not already baked in value, but, 'Whatever the value is for this now, I want you to pass to this function and figure this thing out,' and so I think that's why it's really appealing. I think somebody, maybe Florian, actually, even asked specifically that question. Said, 'Hey, it's not always great for us to just do what pre-processor does, because sometimes pre-processor is more efficient,' so this is why we did it for custom properties, and does the same hold true here? And, yeah, it definitely does. Especially, I think, for custom functions.
Eric Meyer: Yeah. Another thing that I personally was super excited about is anchor positioning.
Brian Kardell: Yeah, there's so much on anchor positioning. I'm really, really excited about that.
Eric Meyer: Yeah, there was a lot, but again, a lot of it was weedy. Not all of it, so I wouldn't say anchor positioning is as far along as maybe view transitions.
Brian Kardell: It's complicated.
Eric Meyer: It's complicated, but it's getting there. And, again, this is a thing that you can try out in Chromium, I think in Canary. I think it's in Chrome, but you got to have the flag on. Anyway, there's been discussion around it and, actually, there's some new capabilities being added to it. With anchor positioning until now, the way the spec was written, you could say, 'I want the top of this element to be lined up with the bottom of its anchor,' or, 'I want the inline end of this element to be positioned, so that it's aligned with the inline end of its anchor,' but you couldn't really size it with respect to the anchor. Well, you sort of could. You could try to say things like, 'Have both inline ends line up with the inline ends of the anchor,' but if you wanted it to be aligned in certain ways with the anchor's element box, you would have to either do math or just guess, or whatever. And so this inset area is supposed to make that much easier, where you can just say, 'I'm an element, this is my anchor. I want to be placed in these boxes in relation to the anchor,' without having to say, 'This edge goes with this edge and this edge goes with that edge minus this amount,' or whatever, which is interesting. And I can see for things like popups that go with a hyperlink. Like on Wikipedia, there are a lot of links that, if you hover over them, there's a little popup box that shows you a preview of the Wikipedia page that that's pointing at. This inset area would make it very easy to just say, 'Okay, I want my middle, I want my horizontal center to align with a horizontal center of the anchor, and then the rest, just size yourself however.'
Brian Kardell: Yeah, and that is tricky, because sizers help however can depend on, well-
Eric Meyer: How much space is there?
Brian Kardell: It's bumped up against the very right edge.
Eric Meyer: Yeah.
Brian Kardell: What if the link actually breaks the line and is on two lines? Then where is your cursor? It's not just the element, it's about where your cursor is on the element. Yeah, so fascinating. This is one that, again, we should do a whole show on, and I would love to just do a show on the twists and turns of this, because this particular thing I think might have started in 2018, and if my recollection is correct, it was Microsoft, actually, that did all the initial really heavy legwork on this. And I think... I believe it was Melanie Richards who then was at Microsoft and then it transitioned in Open UI and UNA invested a bunch into it, and it's changed to shape several times along the way as we think about these things and get new eyeballs, and all that. But it would be a fascinating show, I think, to do on this and include some of the history of the shaping of this API.
Eric Meyer: Yeah. It's very interesting to me, the ways that this has expanded. Even in the last six months to a year where, as the implementation started to be an actual thing... As this proposed specification was implemented in an experimental way, the rest of the Working Group was able to look at it and say, 'We feel like there's a couple things missing. There's a couple of capabilities that need to be added here,' or, 'Wow, that is not what we thought was going to happen there and we need to clarify what we're talking about.' So yeah, there was a lot of discussion, and again, like I say, a lot of it was in the weeds, was doing the whole thing of, 'Okay, given this anchor in this context and then trying to position this other thing in relation to it, there are two possible answers here or more sometimes. What does the Working Group think should happen?' But, yeah, at the same time, there was also stuff like inset area, which is less, perhaps... It hasn't been implemented, so people haven't gotten quite as far into the weeds about it but I think that's coming. And it's not a huge massive extension of concept, it's more of a creating a convenience property and value for authors, so that authors can get more quickly to just do this thing, and the rest of the details are maybe less important to me. Part of it was fallbacks, which is what you were talking about, which was... I said the position underneath the anchor, but the anchor is practically at the bottom of the browser's viewport. Authors are able to define fallbacks like, 'Okay, I want you to be underneath, but if there isn't enough room, go on top, and then if there isn't enough room there for some reason, maybe go to the inline start, and then if that doesn't work, try the inline end and then, if that doesn't work, then go back to the original thing that I said, because nothing works,' right? 'There's not enough room for you anywhere, so just go where I originally said.' And there's been work... The way that fallbacks are expressed and the things that you can do in fallbacks got adjusted in this Working Group meeting.
Brian Kardell: Okay, so another thing then that I wanted to call out that happened there was detail styling stuff.
Eric Meyer: Yeah.
Brian Kardell: So I have been pressing on for a while that I feel like we have gotten some things a little bit wrong in the platform, where we have some things that are like scroll bars. There's no scroll pane element, we just say, 'This element can become a scroller.' We have a special element summary details, largely because that's what windowing toolkits do, but windowing toolkits also have a scroll pane. So the trouble is that the answer to, 'Do I want this to be summary details like?' For me, it's often like, 'It depends.' If I'm printing frequently, I'm like, 'No, I want that to always be open. I want to print that stuff.' I just want to let it be collapsed, because well, on mobile, it just takes up too much space. And, also, I'd like to say, 'It should be collapsed by default on mobile.' There's no way to do those things with summary details, it's like you only can do it programmatically in the DOM or through user interaction. And so I have wanted to think about this for a long time and I had some proposals on how to do it, and David Baron took it up and is carrying it across the finish line for details at least, where the idea is that you can style a new pseudo-element that is the details content area, and you can say, 'Display block and content visibility,' and it will be open.
Eric Meyer: Great.
Brian Kardell: That's awesome. I think that there's probably some interesting questions still there, because I don't know that it really becomes interactive or not, and if that is problematic, but I'm so, so pleased that this is moving forward, so I think that's really interesting.
Eric Meyer: Yeah, one of the things that David showed, that I think a lot of people would be very interested in, is with the details, you could not only make it visible, but you could give it a height and then animate that height when people click to open. So, by default, maybe you're showing the first three lines of the details' contents with maybe a fade-out to make it all look all pretty. And then, when you click on it to expand it, it just animates open, which I know people have wanted for a long time with just basic details. It's like, 'Why can't I animate this?' And they would literally show it, and, 'Here's how you would do that.'
Brian Kardell: I mean, we were doing that with jQuery before. There were even summary details. We were animating effectively disclosure widgets, and not only animating them, but also you could make them so like, 'When it's print, you do like this.' So, in a way... And I think this is not infrequent, actually. In a way, it's great that we got a standard, because for a lot of things, that's all you need, and it's fine, but frequently, when we get a standard is a step back in some cases, and then we have to work to catch up. That's not great, but it does seem to be true. And it was true of summary details, I think, so this is awesome, getting us back up to there. I wanted to note David Baron made this comment that I actually wrote down, because I just liked... I've never heard anybody say that before. So sometimes there's a little bit of hand waviness in some of these. It's like... I haven't done this yet, but you just have to squint at it and imagine. He said, 'I'm probably an integer number of days from solving this.'
Eric Meyer: And then, immediately, a bunch of people pointed out that integers can be very large.
Brian Kardell: Right. Yeah, yeah, but it just was funny because it's-
Eric Meyer: Yeah, it was. In fact, yes. Very cool. I mean, I know you were more excited, because you've been working on it for longer and been much more invested in it. But, yeah, just looking at what he was saying you could do and showing, 'Here are the three lines of CSS that would make this very simple,' was really, really cool.
Brian Kardell: And the other end of things that I was really interested in that people have picked up and been moving along, Rob Flack presented, and he and Mia and probably some others who I am forgetting, unfortunately. But Rob and Mia have been driving this stuff that is under this banner that they're calling 'Carousel,' but it's not really about carousel. It's like, if you wanted to make it possible to do a carousel, here are the pieces that you would need or some pieces that we propose that you might need that would be the building blocks for how you would make it possible to do this. And one of the things that is really, really super to me is the way that they broke it down doesn't only consider carousels, it takes into account a lot of the things that I talked about that are like, 'Okay, so we have a bunch of components that have a lot of similarities.' In our original panel set, we were like, 'Okay, a panel set is... It can be tabs, it can be accordion, it can be a carousel. All of these are very, very similar components. And carousels are not exactly tabs, most of them, but they can be almost like tabs, and so through the work that we did on spicy sections, there's things that came out of that, especially discussions I had with Mia at CSS Working Group Face-to-Face in New York City in 2021 maybe. I don't know. But that have to do with fragmentation overflow. And then, also to that, in 2019, we began talking to people about fragmentation and what the new generation of layout engines makes possible. So we were talking about like, 'Remember all those things that were so cool about regions? Now we could reconsider a lot of those. And remember all those things that are almost about multi-call? We can probably start solving some of those.' And so this proposal actually gets at so much cool stuff. I think that this is a new thing to get excited about. So, with this, you can overflow into things that you can scroll to. You can overflow to these different columns and create, basically, pagination and markers that then you can become the things that you click on that drive the navigation and everything, and do it all declaratively. I'm so floored by it. I'm really, really excited. So we're going to start by putting things into the overflow five draft and Elika, Florian, Rob are going to work on moving fragmentation stuff into it and work on paginate overflow and scroll markers. I'm just so excited about that one. I think it's going to be really cool.
Eric Meyer: Cool.
Brian Kardell: I think the other thing that was interesting to me was there was a lot of discussion about find in page or selection, and those are related to the sorts of problems that I was talking about. So if you create a carousel or tabs, and you have a paginated thing... This wasn't the nature of the conversation, but it is going to be related to those things. You don't think about that control F would want to find those, but it would, and maybe this approach helps solve that problem. So that was not the nature of the conversation, but I expect that we'll get lots more on that.
Eric Meyer: And we should probably... Well, at least I want to mention a few things that were unresolved. They were discussed, but not resolved. Or, in a couple of cases, the Working Group ran out of time to talk about them. One of them was what you were just talking about. There was a discussion about control, whether an element is findable or searchable. Like, in CSS, say, whether or not control F for command F we'll find an element, which is fascinating. Is that presentation interesting discussion?
Brian Kardell: Yeah, because to some extent, you can today, right? If something is display none, it will not be found.
Eric Meyer: So do you want more control over that? A bunch of scroll bar issues were on the agenda, but they didn't get to them. Scroll bar styling is just one of those areas that perpetually comes up again and again. And this time, it's just... It sounds like, 'They could have covered all this in a day.' No, these discussions get very in depth. We've very much been summarizing them. There was one about preserve 3D and back face visibility, and there just needs to be clarification about that. Not that many people use those. And then there was one... There's an animation and anchored positioning. There are questions around that, those did not get resolved. So that's another indication that anchored positioning is still being worked on, is not ready for primetime really yet, but it is getting into that... That's one of those things in the weeds where anchor positioning is cool, but what happens when we try to animate it? I'm sure there were other things as well. Again, we can't possibly do justice to three days of intense, very smart discussions in an hour, but we do our best.
Brian Kardell: Nor would they probably be very interesting.
Eric Meyer: I mean, there is that. To most people, most people be like, 'Okay.' Brian made a joke that it was boring, but I am actually bored. But there are people who find this anything but boring, and most of those people were in that room.
Brian Kardell: Yeah, no. And going back to a little bit to the very beginning, we can bookend this a little bit with the comment that I was making about... There are people who have dedicated decades worth of their lives gaining expertise and thinking around colors. The same is true around internationalization or about fragmentation or layout or paint performance. And so really, really, a lot of the discussion is the experts in the room talking amongst themselves, and they're very frequently not the whole group. Not that the whole group doesn't sometimes have opinions, but very frequently, it's like... This is very, very deep stuff that requires a lot of background knowledge, and so not everybody is commenting on.
Eric Meyer: Exactly. Because, in a lot of cases... I know this was true for me, and I'm sure it was true for you, there were discussions where it was like, 'I wish I understood enough of this to have an opinion.' Like what you say with the color. How should we clip this? I was like, 'Yeah, I don't know. Good question. I hope you guys figure out an answer.' In that case, they kind of didn't, but they're still working on it, so... Anyway, I think that'll do for this week. Yeah, of the big things, the things that excited us. Maybe we should make this a tradition, do another one after the June Face-to-Face.
Brian Kardell: Well, maybe we could do one live.
Eric Meyer: Okay.
Brian Kardell: That's an interesting idea. Live from the CSS Working Group Face-to-Face, but I'm sure we could get a lot more guests. Have people pop in and say 'Hi.' All right, good ideas to think about for the future. Let us know, if you're a listener, if that sounds at all interesting or compelling to you.
Eric Meyer
Brian Kardell