Brian Kardell: Okay. So I am Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer. I'm also a developer advocate at Igalia.
Brian Kardell: On today's show we're going to talk about the CSS Working Group face-to-face that happened last week. So we have broken this down into six, I think. Is it six?
Eric Meyer: So the Working Group, somewhat sensibly, tends to group things together for the discussion. So all of the element sizing stuff is on the afternoon of day one. So when you go through the minutes of the meeting, or the GitHub board, it has morning day one and then there's all this stuff that's related. So we have six topic areas because there were six half days in the three day meeting.
Brian Kardell: I think a thing that a lot of people probably don't understand is that the CSS Working Group, like any software project, is full of people with specializations. If you're talking about, for example, internationalization, or typography, or fonts, or SVG, not everybody is equally versed in all of those topics. And so you need to make sure that if you have remote participants, they can sign on for the piece where they're really, really critical to the discussion.
Eric Meyer: Yep. And speaking as a remote participant, which I was, it was helpful, although I sat in on everything because I'm not actually a specialist in any of these things. So it was interesting to be able to just follow the conversation around various things. I mean there was a lot of the Working Group meeting where I was like, 'Wow, there are two or three people who know exactly what they're talking about having a discussion about this. I have nothing to add.'
Brian Kardell: It's true of many, many CSS Working Group meetings. That there are a few people who are the specialists, and our cross review gives opportunity for other people to ask questions. But largely the discussion is driven by a generally, small group of people who are doing the work.
Eric Meyer: Right. But a different small group of people for each topic.
Brian Kardell: Yes, though there are a few people who are common people on many topics. Those are a really, really small group of people who are the primary CSS engineer for an engine. So you have Emilio Cobos from Mozilla, previously David Barron from Mozilla. Or somebody who is a professional spec writer like Tab Atkins.
Eric Meyer: [inaudible 00:02:55]
Brian Kardell: Who, by nature, has to be able to explain it. And yeah, Elica as well, is in that same group. So you'll see them, if you read through minutes, quite a lot.
Eric Meyer: Yeah. Well, let's dive in. The morning of the first day was, I mean, they didn't say, 'These are the typography things,' That's sort of how I summarized them [inaudible 00:03:23]. Typography issue 5002, which is all about, what do you do with underlines when the box, the element, that you're decorating is higher or for that matter lower than the baseline position? And you might think that, that's really trivial, and yet it's really complicated.
Brian Kardell: Yeah. This is actually, I'm going to take a brief non sequitur here. I don't know if you managed to, anybody listening to the show, look up Florian's talk from a couple of years ago on white space and line breaking. And honestly, it is not everything, but it will be an hour long talk on white space and line breaking. And it is amazingly complicated. It is amazingly complicated. And maybe just before the pandemic, I know you know this Eric, but Brad Frost lives here in Pittsburgh. And I went over to Brad's house to talk to him about something.And this came up and he said, 'Man, I just like... [inaudible 00:04:37] makes it so magical.' You just sort of take the complexity for granted. And then you see a presentation like that and you realize, wow, this is a lot of work. There's so much in here. We've made text seem simple, but it's just about the most complicated thing you can do. And the reason that I bring that up is because if we dig into this, you'll see all kinds of nuances and questions where it's really, really hard. So we have two issues here that are both about effectively underlining.
Eric Meyer: Yeah. Underlining, and in general text decoration. So actually we could take the second one first. So there's a CSS text decoration issue open, on how to use decoration skipping. Can you use decoration skipping to turn off underlines? So as an example, decoration skipping is where people have noticed if you have used underlines recently, when you have a descender like a lowercase Y, the part of it that sticks down below the baseline is the descender. And it used to be that underlines would just draw right through that.And now there's what's known as ink skipping. And I'm doing air quotes here because it's not ink, it's pixels on a screen. But the idea is that the underlying comes along and then where it reaches a place where it would overwrite part of a glyph. What we would think of as ink, what we can think of as ink here, there's a break in the underline or the decoration. This ink skipping typically happens with underlining. It's not supposed to happen with line throughs, I believe, although maybe it does right now.
Brian Kardell: Break through, you mean?
Eric Meyer: Yeah, sorry, strike through.
Brian Kardell: Yeah. It's not I think.
Eric Meyer: Right. And maybe with over write, again, this gets complicated. So there was a question of, 'Hey, can we use decoration skipping to just turn off underlines?' And the resolution there was actually to add a new property called text decoration skip self, right? Which will be...
Brian Kardell: Could we clarify a little bit?
Eric Meyer: Well, it'll be related to text decoration skip, for skipping ancestor decorations.
Brian Kardell: So what this is about is if you have a sentence, or a paragraph, or some text run that is supposed to be underlined, and there's just some part of it that shouldn't be underlined, right? You need a way to say, ink skip on this. Part of the thing that came up in here is about subscripts and superscripts, and where you draw the underline.
Eric Meyer: Yes.
Brian Kardell: And how is that related, is it related to ink skipping?
Eric Meyer: Yeah, which is what that first issue that we mentioned was about. What's the underlying position when you're decorating a box that's higher or lower than the regular position? So if you have, we'll just go with H2O. And the 2 is supposed to be a subscript because that's how atomic configurations are written. And then you have underlined H20 because you really want to draw attention to it. Does the underlying in effect break... It goes under the H and then it breaks, and goes under the 2, and then breaks again and comes back up and goes under the O. Or should it look like there's a single underline, and the 2 just interrupts it? That's not a resolved question.
Brian Kardell: Or should the underline be under even the two?
Eric Meyer: Right.
Brian Kardell: I mean, when you look at the issue, there's a number of different ways that this is done today, and they're all subtly different. And some of them look really good, and some of them look not so good. And I think actually people agree on which one they think looks good and bad too, so somewhat subjective. But it is just interesting because it's phenomenally, I can't think of anything that seems easier in my head at first than just to underline the thing, just underline it. Didn't we figure that out in 1996 or something, right?
Eric Meyer: Except, just underline it sometimes, well that can be interpreted various ways. And then there's the question of what happens if you have a superscript instead of a subscript? Again, should the underline sort of go up to follow it? And there are a lot of different ways you can approach this. And the answers that seem obvious for things like a subscript 2, or a superscript asterisk for a footnote kind of a thing, lead to possibly unwanted results.Like superscript citation needed, as you can see in Wikipedia, that's a superscript in quite a few places, is citation needed. And you might not get the results you want there, given certain answers for the more common cases. Anyway, no, there actually isn't a resolution on this. There was a discussion, there were various alternatives considered. And I believe the next steps are to actually do a developer survey for some alternatives to be presented. And have the community vote, which I'm kind of looking forward to.
Brian Kardell: So I might have mixed them up, so I guess we can just treat them as one unit under typography. But there was a resolution on one issue, which was about the text decorations skip. Giving you a way to say this little run of... This element, even if it would inherit an underline, should not ink. And the other one has to do with where you draw the underlines.
Eric Meyer: Yeah. It'll be interesting to see what the community thinks.
Brian Kardell: Yeah.
Eric Meyer: Then we had element sizing, which was one of those things where, when it started out, I thought, oh, this is pretty cool. And then it very quickly descended into weeds and I was just like, I don't even know. I don't even know what I should think here.
Brian Kardell: Element sizing obviously is important in so many contexts. And so this is kind of a mash up of two broad sub issues. One was about if you have a text area and you just want the text area to be as big as it needs to be according to its contents, which is a common thing.
Eric Meyer: Yeah. How do you do that?
Brian Kardell: And do you do that right?
Eric Meyer: Well, and we should be clear. How does it continue to be the size of its contents as its contents change? As a person types into the text area, and they start going to multiple lines of text, how do you allow the text area to be sized by its contents? And in CSS at the moment, you can't.
Brian Kardell: Yeah. And you at least get the sense of this from some editors, right? Some editors do something like this with the content edible or something, and try to make it do this sort of thing. But it's currently hard. And there is a proposal that we add a new keyword value called max content, but we actually not able to come to any resolution.
Eric Meyer: Right. Max content for height. I think it is not exactly a new keyword. I mean, you can do max content now, but...
Brian Kardell: Support for it, right?
Eric Meyer: Yeah. Because it's not clear, I guess, from the current specification, that's a thing that should update.
Brian Kardell: Right.
Eric Meyer: Dynamically as the user inputs things. Because that's the thing, CSS has stuff that's meant to respond to user action. But sort of by default, that's not really how it works. Sort of the base of CSS doesn't really, it wasn't designed that way, let's say that. And so a lot of the stuff that responds to user interaction has been layered on after sort of the foundation was laid.
Brian Kardell: Yeah. It's not super easy. And why this has to do with the user interaction maybe, is because it's the form field. It's not just content. Obviously if you use JavaScript and added a letter every second, we would know the height of that and everything. It would be a different thing, because actually a IDOM itself changed and everything. But text areas have always been different and special. And a lot of them have a little grippy that you can, I don't know if that's standard anymore, if it's implemented everywhere, but at least some browsers used to add the grippy so the user could resize it. And yeah, that's always been an interesting challenge. But we got no resolution on that one. The other group was around containment issues.
Eric Meyer: Which is very interesting. I don't know how many listeners would actually know about this whole thing that CSS is doing now where it actually has a property called contain. And the idea is to contain certain aspects of layout calculation to an element in its descendants. Basically it's CSS used for page optimization, sorry, page layout optimization. It's telling the browser, Hey, here's a way you can optimize your calculations here. So you can say 'contain paint,' which as far as I can tell, is functionally equivalent to overflow hidden, in terms of what the user experiences. But it's a way of flagging to browsers, hey, you don't have to calculate painting outside the bounds of this element, even if some of its descendant elements, might stick outside of it or be outside of it.But there's size containment, where you can effectively tell the browser, 'Don't recalculate the size. Don't go through the size calculations unless you're explicitly forced to, in a sense.' So there's that contain property. And then that brings along with it, this concept of last remembered sizing. Which is not a property, it's not something that authors can explicitly address necessarily. But there were literally three different issues around this last remembered size. And it was like, is the last remembered size actually remembered if the size containment is only on a single axis? Because you can contain the width calculations but not the height calculations, or vice versa. Or the block calculations versus the inline calculations. And so there was a question of, Hey, if there's size containment only on the block access, but not on the inline access, should the last remembered size be recorded? Should the browser remember that last remembered size? And the resolution was, it's tracked independently for the two axes?
Brian Kardell: I think one of the things that is, if you're on the outside of things, looking in, it's easy to see something like containment and say, gee, how important is that? It seems like I've been hearing about this in, somebody's been bringing it up for a couple of years now. And I can't imagine ever using it because it's just about performance. But a lot of things, again, like any software project, there are bits inside it that are common and used. There are the foundations that you build on. And sometimes you hit a point where you want something that you can't get there from here. Your internals don't have the necessary sort of prerequisites and building blocks. And so you have to take some time to build those things, which are themselves maybe moderately useful. Or useful in very particular cases. But their real value has to do a lot with providing you the building blocks you need for other things.So for example, containment is very useful for performance, potentially. And there are definitely use cases where that really, really matters. You're doing things that are very intense and need to update a lot, where doing all the work every time would be too much. And if you have the information to say upfront, this isn't that, then you can really give a hint to the browser and make it a lot more performant. But in many ways, the real value of containment isn't that. And we want to specify things for container queries. And how do you know when this thing has been resized?So we had Resize Observer. And all of these things then share concepts throughout the specs that are the fundamentals. And so all of these questions really have to do with different parts of the system. Two of them were talking about how Resize Observers work. And what happens in this particular case, because it's not clear in the spec and you could interpret it a few ways, right? Yeah. I think another thing that is worth mentioning there, I guess, is that Greg Whitworth, when he was at Microsoft, was I think one of the primary editors of Resize Observer did a lot of great work to get that going. And then he left for Salesforce, and so he's not currently able to do that, I think. And so we added two more editors to the Resize Observer spec, which are Emilio Cobos from Mozilla and Oriol Brufau from Igalia.
Eric Meyer: Which is super good, because the two of them, they have to worry about this stuff a lot. It was interesting to me that I recorded three, and I think there were a couple more that I just didn't include in our show notes, issues that were just about, is last remembered size a thing in this context? Okay. What about this context? Okay, in this set of circumstances, what should we do about last remembered size? It's not actually a thing that authors will ever particularly need to worry about, directly, right? This concept of last remembered size. The only thing that authors, and for that matter users, really need to care about is, have all of these issues, have all these questions around this last remembered size concept, been resolved in a way that the contain property really does give performance benefits and not be sort of a waste?
Brian Kardell: Well, and importantly too, does it work consistently across all browsers and all places where the same underlying fundamentals are used? So you don't want something else like container queries and Resize Observers should be working with the same kinds of concepts. And what you don't want is, the web is full of very creative people. And someone, somewhere, will do something, probably something very cool. And it won't work in one browser, or it will work differently in all three browsers, because you bump up against these kinds of things. And so when you see these kinds of groups of issues, it's because somebody is working on something related to that, and they're providing another set of eyeballs, and often a slightly different context.So if you're working on Resize Observer a few years ago, there weren't container queries. Now we have other things, we have other contexts, we go back, we look at it with fresh eyes. Maybe we've looked at other implementations now. And we said, 'Oh yeah, our implementation is not asking these questions that seem to be asked in the other...' Or I implemented this, and then I went to test it, and it works subtly differently in my implementation than it does in this other browser. So you tend to see a group of issues like this when something like that happens. And also when we're working on the year long interop projects. Because we say there is a slew of interop issues that we identified, get them.
Eric Meyer: Yep.
Brian Kardell: Okay. So then Scroll-Linked Animations.
Eric Meyer: Yeah. So I mean Scroll-Linked Animations, another way to think of these is Scroll-Triggered Animations. So it's the idea that as the user is scrolling to the page and elements become visible, there should be a way to trigger an animation as a thing becomes visible. Right? Because right now, if you want to do that, you have to use JavaScript in some way. You have to, I don't know, flip a class or something. To basically say, 'Oh, this thing is visible, and now we want the butterfly to fly away across the screen, because now it's visible.' And so this is a concept that's being hashed out. And hopefully we'll be coming to browsers relatively soon where you can just, in CSS say, 'Hey, when this thing is visible, then do this transition or play this animation.'And so there were lots of questions. How does CSS even express that? Right? And how do you address things like the beginning or the end of that transition process? Can name a timeline? And if so, what's the scope of that? Is there, or should there, be a way to name these sort of containers as it were for these animations? So the way that it's being talked about now, as I understand it, is that you sort of define a container for a given animation. Maybe sort of in the contained sense. Anyway, basically you say this animation is dependent on this quote unquote container, this thing that we've wrapped around this animation. And then when that container enters the view, then you can trigger things. And when it exits the view, you can trigger things.
Brian Kardell: Maybe it's like this Scrollport, more or less?
Eric Meyer: Kind of, yeah. You sort of define a Scrollport. Or another way, I guess, to think of it, would be to define the thing that triggers this animation. It contains a trigger in a sense. Right. And that trigger is, when this trigger becomes visible, then we enter into this transition. And when it becomes not visible, we can exit out of it. And yeah, trying to work that out, leads to, as with anything, led to a lot of different things like entry, exit transitions for view timeline effects, and name timelines, and container name references. Which there are, at the moment, the scroll function, which is how some of these things will be expressed, will not have container names in it at this point.And that points to what I think is an important guiding principle of the CSS Working Group. They really do their utmost in all circumstances to do the minimum. And not the minimum in the sense of we're being lazy. But the minimum in the sense of, we're not actually sure if this thing is necessary, so we're not going to do it at first. So maybe it will turn out that the scroll function needs container name references. Which to anyone listening, if you don't understand that, that's fine. I'm not sure I totally understand it myself. But the point being that maybe the scroll function doesn't need this. So the Working Group tends to have this principle of, okay, if we're not sure that it's needed, we're not going to put it in. We're not going to just add this thing in case it's needed someday.
Brian Kardell: Two things I would add to that. So one, just any other software project, you set out with goals, right? You have goals. And along the way, people have ideas that get added on. But at some point you have to ship a project, right? You have to ship something and say, 'That's done.' And when you're going through W3C Process, we have levels. And eventually at some point we need to say, 'Okay, this is the spec that we're aiming to get everybody interoperably implemented and in rec. And so sometimes when it looks like there's a bunch of ideas here, and there's a bunch of things that are even maybe potentially clearly useful needs, but we don't really know how to do them. And pairing down the scope of what we're doing, allows us to get it done, and ship it, and get interoperable [inaudible 00:28:19].And I think an important part is that then you get some use from real developers. And you see which questions are asked and where they're prioritizing things. You had a great talk on this, there's just not enough people to do all the things. And so we are constantly having to prioritize work. And so having a shipped thing that is interoperable. And then taking a beat and seeing where people are asking questions or complaining, the things they're asking for, is useful input as to when we should tackle that. So we try to do a good job of delivering the fundamental value. And occasionally it means paring down some of these things that we don't know the answer to that, we're not sure, and we don't know how useful or necessary it is. So let's see.
Eric Meyer: Yeah. And I think that's worth calling out, because the Working Group did not always operate on that principle. If you go back far enough, and this is a fair ways back, but if you go back far enough, there was definitely sort of an attitude of, well, this is interesting. And we can imagine that these other things that might be a good part of that, so we'll just put them in there, even if they weren't hard to implement. And some of them, the Working Group was right. And some of them were things that just kind of withered because nobody ever really used them. Or they actually ended up making, doing, useful things more difficult because they sort of got in the way.And so there's really been an institutional, I guess, lesson learned there. Which is to sort of ship that minimum viable product so that it's useful and interoperable, ideally, but doesn't go too far overboard at first. With the, well this might be useful so we'll include it. That will make people happy. And we'll include this other thing, and this other thing, and this other thing. All these things that we think will make some people happy. And it's like, you might be right, but you might also have just stuck something in there that nobody's ever going to bother to use, because it's not actually what authors will want.
Brian Kardell: Yeah. It's definitely an optimization problem. There's the real minimum, maxima there, as to how you approach that. And I think the thing that even just the software industry at large has learned, I mean, this comes down to, we used to do everything was waterfall. And you would take a really lot of time thinking through all the things and trying to deliver one big push. And if you get the big push and it's good, that's awesome. And it can be really efficient. But in practice a lot of times, most of the time, you are stuck with zero value until the end. And then in the real world, you can't predict what is actually useful very well.So I think breaking things down so that users get some value more quickly, even if it's not the total value. And then laying the foundations so that you can use that to build bigger and more complex things, and get more information about what should be prioritized is generally a good practice, I think. But the CSS Working Group is also very careful about raising those questions as soon as we have them. So that at least we're thinking about them and not creating evolutionary dead ends where we can't get to that solution ever. I think another thing that is a common theme in a lot of issues, that will actually come back in the next section, I think. There are a lot of things about names and scopes. Because the web began as really a single document. And then we got the ability to embed some documents like images. And we also then got the ability to embed frames. And you can embed SVG documents. And you can embed SVG documents as images. And you can embed SVG documents in Iframes.And then now also we have Shadow DOM, which is also its own embedded fragment document. CSS was a little bit unprepared for some of that, because its premise was pretty simple. It's just like, you give it a global name, and then you can use it, and just be careful. And even in a lot of real world scenarios, even in a single document, that can get very tricky as you work many teams in the same website potentially. Or shared things like design systems and shared components that go across many projects, it can get tricky already.But now none of those names are visible from there. And sometimes, maybe you need information to travel between these two boundaries. Now that we have container queries, there's this idea of scopes in the same document. So the one that I think you mentioned, well, there are actually two in here, I think, that have to do with this. So one is, okay, so you make a component, a custom element that you share, and it has a shadow boundary. Can it participate in those? How? So there's whole new concepts in here that we have to think about that we didn't have to think about before.
Eric Meyer: One of the things that I think is a little more concrete for some people, is there a way to pass colors and stuff into SVG images? If the SVG image is literally embedded in the document, if the SVG markup is part of the HTML, that's fairly simple. From the document style sheet, you can say, 'The fill of this thing should be blah.' And, 'The stroke color of this other thing should be blah,' in order to fix with the theme. But if you're using IMG, SRC equals something, something, something, dot SVG, CSS has no way to talk to the internals of that SVG file. Which I mean, I've run into many times where I've...
Brian Kardell: Absolutely. Yeah. I also have.
Eric Meyer: Yeah, eventually you're like, I'm going to have to embed it. I'm going to have to use includes in my template system to pull this thing in here. Just so I can change the color of the icon in this SVG file when the user switches from dark mud to light mode. Which sometimes that's a good idea for performance reasons. Sometimes you do want to inline the SVG, but it's not always. So how do you pass that information? And so there's been a proposal, Tab Atkins in fact, had a proposal for what is called an SVG parameters specification. And the Working Group resolved to adopt that as an editor's draft. So basically moved it onto the first rung of the specification track, right? Because Tab's specification wasn't on any sort of a track. It's like if I just wrote a specification for my cool CSS property, I can make it look like a W3C specification. But until the Working Group accepts it's not really on the track.Well, the Working Group has accepted this. And I don't think we should get too deep into the weeds on this because it could completely change. But making it an editor's draft means that now it's being seriously considered as, how do we pass information from the HTML document, or from JavaScript, or from whatever into an external SVG? And then I think probably part of that discussion will end up being okay, but can we adopt these same principles for other situations that are not SVG? But you were talking about it's an Iframe or it's a shattered on component or whatever. I used the example of dark and light mode on purpose because two of the other things that were talked about was, if you have a color scheme in media queries, prefers color scheme, whatever. Can that be propagated into SVG images? Can it be propagated into Iframes? Is there a context dependence? And those were resolved by the Working Group with the Iframes.The resolution was that the context dependent color scheme, so the light mode versus dark mode propagation, does work for Iframes, including cross origin eye frames, unless it's in some way specifically restricted by the author. So basically the Working Group said browsers should propagate the prefers color scheme value into Iframes, even if you're pulling the source of the Iframe from a completely different origin. There had to be a lot of discussion about that around security, and cross-site scripting, and have we thought this all the way through? And is there anything that we're not considering? But I mean that's a big step. It doesn't sound like a big step probably, but it is, it's a big step.
Brian Kardell: So we already have started on the next group, which is values and units. So we made that transition. So there's a bunch of issues in here that are related to values and units. And this one is something that was started by Tab. And just to clarify a little thing on the W3C specs, at some point you go from vague idea to more concrete details. And the process for this is sort of whatever works really. So it's recommended that you start as an explainer, which doesn't do that. And that it goes through a process and maybe it's incubated. But very frequently when there are editors who are on a Working Group, particularly to CSS Working Group, who has had for a long time, its own concept of incubating ideas. The editors will just go and make something that looks pretty spec-ish and then say, 'This is the thing that I'm thinking. And it lays out the use cases and the scenarios and everything. And I would like the CSS Working Group to take it up and start an editor's draft, maybe with this as the first thing.'And the editor's draft is, as you say, it could completely change. All the editor's draft means is that the CSS Working Group has formally taken up the use cases and the vague idea, it could radically change. It could be maybe not even using URL at all. There was some proposals in there about how we do a sort of an import export idea with custom properties that you could pass down, for example. So that will be super interesting. And I also wanted to point again to the complexity of things and say, I don't know what it came up in, but Ian Kilpatrick from Google had one of my favorite quotes from the whole thing. Which was, seems simple, but is full of terrors.And it's true. There's so many things that it seems very, very simple. How hard can it be? I just want you to respect the background color that I give you, right? But there are cases where, what if the thing you pass down is a URL? And then that means I have an opportunity to embed in image that I'm going to serve from my server, even though it's your SVG image or something. And there are lots of things you have to think about there about privacy, and security, and it gets really tricky. Almost nothing is simple.
Eric Meyer: Certainly not at this point. And actually, since you mentioned values and units, one of my favorite things, even though it seems wacky, is the introduction of chaos that will come from the random and random item functions.
Brian Kardell: Yeah. So this is another proposal from Tab. I think about this even all the time. So Tab Atkins is also on ECMA TC39. Again, we have things in the platform that explain magic. And we want to not have different answers for those questions. An example of this that is totally unrelated is in MathML. There was this co-evolution, and in MathML, the first spec arrived before CSS. And so there are, just like there were in HTML at the time, effectively presentational attributes that you could set. So there's a math color that is effectively the color attribute in HTML. Again, what is a color? Anybody would expect that you should be able to put red in there and it should be probably red.But should MathML define every possible serialization of a color? What colors? What set of color names? You don't want to do that. You want to say, 'CSS knows how to do colors. Anything that's a valid CSS color is valid here.' And then you want to also say, 'And by the way, this is a presentational hint and you probably shouldn't even use it.' But yeah, we don't want multiple things, having to rethink, and have different answers on the edges. And so I think Tab is focused on some of the bits that we need for random things. Even, JavaScript doesn't have a big standard library. So people use Lodash or Underscore, which allows you to say, 'Here's a list of six things, just give me one at random.' And you have to program that today. And there are lots of ways to get it subtly wrong or different than other things, where it's not true random, or it's not what you wanted.Or to be able to say, just give me an integer between one and 100. That is surprisingly easy to get wrong because it's basically a one or two line function, but it involves math. And.you have to protect against cases, what if you say 'From 0 to 10,' then all the multiplication just is zero. So it's just subtle, silly little things, that everybody has to do again. So I think it would be nice if we had some good standard library stuff around random personally, I want those things all the time for little pet projects that I do. And I find myself not wanting to import something and just rewriting the same functions over and over.So yeah, these would be random and random items. So those would be basically the two that I talked about, which is this should be an integer between 1 and 500. Or, here are three possible background values, just give me one at random. I want you to just alternate. There's no rhyme or reason, just give me one. And it should be different every time. And both of these, I think, have also a flag in their proposal that's like, should it generate different for every element? Or just one for the document? So yeah, I think those will be really interesting. And we'll have to wait and see, because I think it's pending Tab's work in ECMA.
Eric Meyer: Oh yeah.
Brian Kardell: But I agree. Those are really interesting. And I can't wait to see what people do, because it will be fun, people will do fun things. And all of them won't be wacky. I mean, I don't think people are just going to randomly throw random everywhere. But there are some interesting ideas like backgrounds, if you have several backgrounds and you just want to say, 'I don't know, I just want it to change sometimes, just for the sake of being interesting.'
Eric Meyer: And where random might come in super handy is inside calc, where you can say, 'I want these things to be placed based on this calculation, but this calculation has some randomness thrown in.' So that you can scatter cards a little bit. So they're not in this very perfect grid. They have a little bit of organic-ness to them. Where you could randomly offset them by a few pixels from where they would start, and maybe somewhere something between zero and one and a half percent rotation. Right. So they end up looking, like I say, much more organic rather than very sort of sterile, grid, kind of thing. Yeah, so that'd be super interesting. But there was one that I know we wanted to talk about before we ran out of time, and we're almost out of time. Which was the question about box shadows, and border radius, and spread, and shadow spread. I agree with you, but you flagged this as something that you thought was super interesting.
Brian Kardell: I flagged this because it was really, really interesting to me. Because I encourage people to go look at the issues, I think it is issue number 7103 in CSS Working Group drafts. And it's very clear that there is not a right answer to this question. Right? There's not an objectively correct answer to how we're going to do this, there's trade offs. And the reason that I think it's very interesting is, it's one of the many examples that we already mentioned Oriol earlier. Oriol is the [inaudible 00:48:01] who works here with us and he's in the CSS Working Group. He is one of the editors of CSS Grid. And all of the issues that we talked about previously are on element sizing, he opened all those. And he did a bunch of work here, he's very big on maps. And he did a bunch of work in here, created a bunch of demos, and suggested we could do it like this, and we could do it like this, and we could do it like this. And illustrated them well.And I wanted to put it on here because A, I think people should look at it and they should weigh in. But also just because I wanted to say, every time I'm in the CSS Working Group and I see that Oriol has issues on there and he gets to speak, I feel like I'm very proud to be in the same company. And he is just amazingly smart. And I feel a little bit like the Goodwill Hunting scene, where he knocks on the window and his whole comment that he can add to the conversation is just, my boy is wicked smart. That is how I feel when Oriol is speaking. He's just very, very smart. And I love the work that he does on CSS Working Group. We're really lucky that he's in Igalia.
Eric Meyer: Yeah, absolutely. And yeah, it's kind of the first thing we were talking about with the underlining, and the decoration, and the superscript and the subscript. Like you said, this is another situation where there's no obviously right answer. There are various answers that you would probably get everyone to agree... I was like, this answer is the right answer in this context. But then when you change the context, suddenly it's the wrong answer.
Brian Kardell: And there are cases where you could get everybody to agree. No, not that one. We can all agree that's the wrong answer. But yeah, there is again, it is subjective and there's not a right answer here and we have to pick something. And it feels like people will sort of agree. And we got to try to find where we get it 80% agreement.
Eric Meyer: I mean, part of the conversation was, well, should we have what's effectively a discontinuous algorithm here? Should we say in these contexts, we do this thing. But in these other contexts, we do a different thing, to try to get closer to something that everyone can agree on. But nobody really likes that idea. Nobody likes the idea of, well above this threshold, in this value, but below this threshold, this value, then we do this algorithm. But then in this other range of values, we do another algorithm. Nobody really wants to do that. I mean, I think the Working Group will, if they decide it is important enough, I think they would be willing to specify something like that. But nobody really wants to do it that way. Would rather find a solution where there's one algorithm, one thing that is used across all cases. And we have to accept that it sort of visually breaks down in certain places.That's one of the core challenges of the CSS Working Group is that we, and they, and browsers are working with visual presentation for the most part. I mean, that's what CSS is really about. And you run into situations, like the one in this particular issues, where if you have an element that you've turned into a circle with border radius, then you want the box shadow to be a circle. But the way that you can define that most easily, then means that if it's not a full circle, if the element is an ellipse, or if the element just has mostly straight sides, but really deep border radius surrounding. Then the results of that algorithm that was defined to make a circle look like it has a circle shadow, suddenly the shadow doesn't look right.But then if you do an algorithm that makes it look right when it's not a circle or an ellipse, then you could probably make it work for a circle. But then it breaks down for ellipse. These are the trade offs, so that's what they're trying to work through. And like I say, there's no resolution yet. All these alternatives have been presented. Oriol, like you said, came up with new algorithms for calculating box shadow with spread.
Brian Kardell: And made demos.
Eric Meyer: And made demos. And has proposed them. And has also pointed out, yeah, this works for the thing that we first brought up, but now causes breakdown in this other place. And are we okay with that? And the Working Group hasn't decided. And sometimes that's how it goes. There was no explicit resolution to put this one in front of the developer community for a vote. Cause I don't think the Working Group is there yet. The hope is always that they can come up with a solution for something and not have to bug people for their time to vote on stuff.
Brian Kardell: It's very difficult with things like this because you will inevitably wind up with two problems. So we'll come up with maybe two or three answers that we can't choose from. And we'll say A, B or C. And first there will be a whole bunch of people that respond with D. And that's actively, usually not helpful, because we have considered D, and E, and F, they're kind of non options. We don't want to add more possible choices probably. It's very hard to filter through all of them. Not that a good idea or a solution couldn't come that way. It's just, when we run a poll, we can't choose A or B for example.And one of the things, anytime there's anything that is remotely subjective, we put it to a poll. It is almost always 50/50. And it's not just CSS. I mean, it's everything in the web platform. I can point to a few that just come to mind immediately. Dominic Denicola, when they were taking up new HML elements, he said, 'We follow this practice about how we specify them and whether they match the OS, or whether they're browser consistent.' So if you use it in Chrome, does it look like the same thing in Chrome, no matter the operating system? Or does it match the operating system?So things like inputs, and buttons, and things. We kind never really totally agreed on that. And it's caused a bunch of problems. And Dominic said, 'Hey, we don't have to do that. We could specify exactly how it should work. And so I'm curious, should it work like this? Or should it work like this?, right? And I thought, well, there's really only one right answer there, right? I mean, it seemed very clearly A to me. And I was excited about that. Cause I thought maybe we can get past this set of problems that we have. So I kept checking on it, and yeah, it was exactly 50/50 in the end. It got a really lot of votes and it was exactly 50/50. And it's not at all uncommon.
Eric Meyer: I think of that as Cardell's first love of holes. Is that given any subjective choice, the results will be statistically 50/50.
Brian Kardell: Yeah, definitely. I can't believe we managed to fill this much time. I thought actually this would be a relatively quick one. But I think we've covered pretty much everything. I think the only thing that we didn't cover is that ch units and font downloads. And let's not get into it because we spent a lot of time.
Eric Meyer: And also because it hasn't been resolved yet.
Brian Kardell: But also it is just really, really interesting. You would think, I mean, it's just a new unit. What's the big deal? It's a big deal because it refers to a font, and you can't measure the font if you don't have the font basically. So if you use one, it can cause a font to download. Okay. Thanks.
Eric Meyer: Thank you.
Brian Kardell: Yeah. And we'll see everybody next time.
Brian Kardell
Eric Meyer