Igalia Chats: The Struggle to Keep Up with Web Tech
Eric Meyer and Brian Kardell talk about the experience of discovering a web feature that’s been around for a while but nobody told you about it, the challenge of keeping up with new web platform features when there’s so much happening, and their tips for ways to stay as up to date as you can.
Brian Kardell: Hi, I am Brian Kardell. I am a developer advocate at Igalia.
Eric Meyer: I'm Eric Meyer, also a developer advocate at Igalia.
Brian Kardell: One of the interesting things about having a podcast is that sometimes a little thing makes one of us reach out to other and say, 'Hey, is that something I have this idea? Is that a show? Maybe we could make a show out of that.' A little while back, you tweeted about discovering, I think it was the .closest() method.
Eric Meyer: Yeah. Well, it's a JavaScript thing where you can say there's a closest function for nodes in the DOM. You can say, if you have a DOM node or an element or whatever you say, element.closest('section'), and it will select the closest section element that is either an ancestor or the element itself. If you say, element.closest('section') and element is a section, that will select that element, but if your element is a span and you say, element.closest('section') for that span, it will select the closest ancestor section. Even if there are nested sections, it will pick the one that's closest to that element in the DOM tree.
Brian Kardell: You can think about it as going with .querySelector(), but going the other way, right? .querySelector() walks down into the tree, .closest().querySelector(), .querySelectorAll(), .match(), as close as they come from this era, and they've been mostly everywhere since 2015, and they're also really highly polyfillable, so we had polyfills even before that. They've been universally implemented since 2017, when it became Edgium, when Edge became Chromium.
Eric Meyer: Right. That's when closest, for example, became-
Brian Kardell: Yeah. Universally implemented without polyfill support, but it's been around for a while. This thing that sparked my interest is, A, I'm closely attached to some of these, but also, you and I talk about this all the time, we talk about how do you keep up with all the things that are going on, and also the other end of that, the sort of really burned in, widespread knowledge that everyone has that it becomes just a thing like a reaction almost. You just know it. You just know it rote. It takes a really long time to learn for you to go, 'Oh yeah, there's a thing, closest, reach for that. I know exactly how to use that without even looking.'
Eric Meyer: Yeah. Whereas I only learned about it like a month ago.
Brian Kardell: Yeah, but for that to permeate so that everybody knows about it, where it's just core knowledge that everybody has, it takes a really, really long time. It's surprising. It's surprising, right?
Eric Meyer: Yeah, sometimes. For me, that doesn't seem surprising that I didn't know about closest, because I don't do a lot of JavaScript compared to a lot of people. I do some, but I don't do a ton, and so it hadn't really been a thing that I was steeped in, if you want to put it that way. Whereas with CSS, I am constantly surprised that people say, 'Wait, there's an isolation property?' I think to myself, yeah, there has been for a while, or HTML, for that matter. It's been more than a couple years ago now, but somebody posted about base href, and the replies were just a never-ending parade of, 'What? That's a thing you can do? When did that get added?' Me thinking, base href was added, I think when Tim Berners-Lee first wrote HTML. It was added at the beginning.
Brian Kardell: It was in the dark ages, wasn't it? I think about that stuff all the time, and I'm constantly surprised when I learn new things all the time. That's still amazing to me. I am constantly still learning things all the time.
Eric Meyer: Right. And you think, how long have we been able to do that? How long have I been working around that, around my lack of knowledge of that thing?
Brian Kardell: I thought it would maybe be interesting to kind of whip through a bunch of interesting things that happened in a few different eras that maybe people might have missed, and then we'll talk about the larger problem, I guess, of trying to keep up and everything, so that's what this show will be. As I said, there was this movement of people from JavaScript land to helping work on standards, and lots of the things from jQuery, I think, helped shape, so lots of the DOM APIs have been improved. Do you know there's .appendChild() and things in the DOM APIs?
Eric Meyer: Yeah, I did just recently learn that.
Brian Kardell: There's some DOM APIs that have been around for literally forever, but they were missing some that you would think naturally this one implies the existence of that one that jQuery just added, and so it came back and added them to the DOM. .prepend() is one, .replaceWith(), .replaceChildren(), I think those are all really interesting.
Eric Meyer: Oh, I just realized I misspoke. Actually, I knew about .appendChild() for a really long time. It's the next that I wasn't aware of until very recently. Is it called next?
Brian Kardell: I don't know.
Eric Meyer: The thing where you basically say, element.next(otherElement), and it appends the argument element, so if you have span.next(span), it'll stick that second span in right after the first one. Except I don't know if it's called actually next, but there's a method, or a function or whatever it's called, that does that. There's a previous().
Brian Kardell: Like an .insertAdjacentElement(), I assume?
Eric Meyer: Yeah. It's like that, except it's called something else. I can look it up, but anyway-
Brian Kardell: The event listeners, they have an argument where you can make them do once, so they only are relevant once, and then they just cease to exist. That's a super handy thing that was first introduced in 2016, and got very, very quickly to universal implementation in 2017. That one's really handy. I think <template> is probably one of the hugest things, and that also came from that same era. It started in 20-
Eric Meyer: You mean like template literals, that kind of thing?
Brian Kardell: No, that also came from a similar era, but I mean the template element.
Eric Meyer: Ah.
Brian Kardell: People have been doing client-side templating using something like Mustache or Handlebars, or there's lots of them, for a really long time. When you want to do Ajax and update the DOM, you need to do the same thing you do on the server, which is fetch some data and then stamp out some HTML. There have been client-side template libraries for a long time, and the way that we would embed them was a kind of clever hack that was to put a script element in your page with a type that was an unrecognized type, so like text/mustache-template, and then it won't execute that and it will use the script parser. Basically, it will just skip the stuff in the script, more or less, and then you can pick it up and stamp it out. That is an almost elegant solution. The reason that it's not elegant is because the parser will still find things like an empty image element in there, like an image element that doesn't have a source yet or has a source that's dollar sign, curly braces, something, and it will actually try to request that. If you tried to put some nested script in there, that gets weird. You want something that when you register this element, it executes the script, and you just put a script tag in there. Feels natural in a way, but it just doesn't really work. <template> solved all those things. It created a way for us to say, 'There is some DOM, the stuff in here is real DOM, but it's inert.' You just parse it as DOM, and then you can grab a document fragment from that, but it doesn't go and load its contents and do all that stuff, so you can do all that with <template>. <template> is really cool, and it is now the basis for Declarative Shadow DOM, too.
Eric Meyer: Yeah, there we go.
Brian Kardell: It's a real good one to look into if you haven't.
Eric Meyer: Yeah, that makes sense. I was aware of the element, but not the... I haven't looked a lot at Declarative Shadow DOM. I've sort of skimmed over it and I didn't realize they were using template there, but that totally makes sense. The thing I was thinking about before is actually called after, not next. You can say something like, 'Input.after button,' and then it'll stick a button in after your input, that sort of thing. I believe there's also a before. I'm pretty sure there's a before, as well.
Brian Kardell: Does it also take a NodeList, like you can pass it in Node-
Eric Meyer: I don't know, actually, I've never used it that way. I've only ever used it basically once. It wouldn't surprise me if you could pass it like a NodeList or a subtree, effectively, but I can't say for sure. Anyway, these are the things that we've just recently learned. For a long time, if I needed to add an element into an existing structure, I was doing the whole appendChild thing. Sometimes it's like, well, I don't want it at the end, I want it somewhere in the middle, so I'm actually going to have to build this whole thing from scratch. Basically, I'm going to have to use JavaScript to either tear apart the DOM that's there and then reconstitute it the way I want it, or I'm just going to have to build it from the JavaScript and not have any markup in my document in that place. Now that I know about after I don't have to do any of that stuff. I can just pick the element that I want to put something right after and be like, 'Put something after that.' Boom. Done. Woot. I don't know when that got added. I could look it up on MDN or Can I Use or whatever, but that probably has been there for quite some time, and I only just learned about it within the last month or so.
Brian Kardell: MatchMedia, I think, is another one that a lot of people are still learning about. It surprises me, but I guess you learn about a trick and then you live with it for a long time, and other people didn't learn about that because they didn't have the need, so there's no excuse for them to learn it. But it is a JavaScript API that lets you basically respond to events for media queries, so this media query suddenly matches or doesn't match.
Eric Meyer: It's sort of like a JavaScript version of @media in CSS, where the browser just sort of listens for changes to the media environment, and then you can essentially do a, 'If a matchMedia below 640 pixels, then do this JavaScript.'
Brian Kardell: Yeah, right.
Eric Meyer: That's pretty much what that is, except if you're only doing CSS, of course, you'd just want to use @media in CSS, but I can see where you would use this to, I'll wash my mouth out with soap afterwards for saying this, but you use it to construct a hamburger menu when you get to mobile sizes?
Brian Kardell: You could. Sure, yeah.
Eric Meyer: I said hamburger menu, I'm sorry. But anyway, so there's that API, which I don't know that I knew about.
Brian Kardell: It's been around for a long time, 2010, '11, '12, somewhere around there, but it was supported in IE 10. It's been around a long time. The CSS that supports API, I think some people still learn about that. It had choppy support until about 2017, but that also first appeared in Opera in 2012. It's been everywhere since 2015. That's really, really handy.
Eric Meyer: Yeah, @supports for feature queries, which most listeners will probably know about, but for those who don't, you basically can say, '@supports color,' and then give it an oklch value, and then if it returns true, then anything you put inside the @supports block will be run by the browser, and if it returns false, then it won't, so you could do all of your oklch-centric styling inside there. A lot of people use it for things like @supports display grid, and then if the browser supports grid, then you do all of your grid layout in there, or at least they did. I don't know if people are really doing that anymore, given how long grid has been supported now, but that was very popular for a while.
Brian Kardell: Yeah, that's exactly the use case. You have some powerful, new, great thing like grid and you're like, oh my God, I can do such great things with this, but what if, for the first few years, you don't have grid? Grid was not so much like that because everybody worked on it at the same time. We got it released very quickly. But even if everybody releases at the same time, like grid, you will have a percentage, the trailing percentage of that does not hit anything like 100% as quickly as you would imagine. We never really can get to 100%, but to get as high as we're probably going to get, it can like take three years, which is amazing to think about. We need to do a show about that once that's all done. I don't know, there's lots of console methods. The reason I put this in here is that Paul Irish was also involved in a whole lot of these things, and for a brief time, he and I were going to start a console standard, and we actually even started the work on that. Then, eventually, Terrin Stock picked it up and I don't know what happened with it, but this was a big deal because, I know we've talked about this on the show before, but back in the day, there wasn't even a console, period.
Eric Meyer: True, yeah.
Brian Kardell: And then when Microsoft came along, Microsoft added their console and you had it, but only as long as the debugger was open.
Eric Meyer: Yeah, right.
Brian Kardell: No sense at all. Just no sense at all, but there you have it. And then there were all these differences between Chrome's and Firefox's, and there was no standard around them, not in any kind of way. These console ones, time and time in, were kind of the first ways that we could measure how long a thing took. That was pretty cool. It still-
Eric Meyer: Oh, is that what they do?
Brian Kardell: Yeah. It's still kind of useful. It's for instrumenting time on your things, but that first appeared in Safari in 2009. It also was supporting IE 11. This is a long time that it's been there, and I bet most people don't know about it.
Eric Meyer: You put in your JavaScript console .time, and that will output the current milliseconds or whatever since the Unix Epic out to the console, that's what happens?
Brian Kardell: It's like a way that you mark the beginning and end of a thing, and then it can log the elapsed time in there.
Eric Meyer: So, instead of having to do the whole let time equal new date and then later doing the math yourself, getting another time point and subtracting from the first time point and then console.log, whatever the result of that is, you just put in console.time and console.timeEnd where you would put those two bits, and it will do all that for you?
Brian Kardell: Yeah. If you just do it in a single function, it's just used as sort of a global thing, but you can also pass labels. If you're dealing with things that are asynchronous, it will label them and track the timers independently.
Eric Meyer: Oh, nice. Very cool.
Brian Kardell: It is really nice.
Eric Meyer: I know that there are other console methods, I don't know the names of them, but you can style your console output to a limited degree, make things bigger or bold or change color or whatever. What else have we got?
Brian Kardell: In console?
Eric Meyer: Yeah.
Brian Kardell: Quite a lot, actually. Maybe too many. There's ways of grouping. We just normally use console.log(), but there's also console.warn() and .console.trace(), console.info(), console.error(). These are all so that when you look in your dev tools, there's filters, and they're progressing higher and higher. This is the way that a lot of loggers work in a lot of languages, so I don't know how much everybody's just familiar with that already, but there's counters, there's things that you can call that will automatically count the number of times the thing has happened. I don't know, it's worth looking at, just console in MDN.
Eric Meyer: Yeah. Search MDN console, and your first result will probably be the Console API page, which will list all the instance methods and stuff like that.
Brian Kardell: Or just go to MDN and type Console API, and it should-
Eric Meyer: Console.table, you can display tabular data as a table. That's pretty cool.
Brian Kardell: Yeah. I don't know. We can just kind of whip through. I had a bunch of other notes about other things from this same sort of era, I guess. The .insertAdjacentHTML(), which is the one I thought you were talking about. It is a, honestly, powerful, but weird API that dates back to 2009. It even had partial support in old versions of IE, maybe. Here's one that I think a lot of people don't know, but it's really powerful. Do you know that addEventListener has the third argument that sometimes people don't even pass, but usually people just put false? Do you know what that is for?
Eric Meyer: I do not.
Brian Kardell: Way back, if you recall, there was not a standard event model or a DOM or anything, and so Microsoft had one set of ideas and Netscape had a different set of ideas. Microsoft's idea was that things should bubble up to the route. You do something and then everybody gets a chance to handle that event, and then you can say, 'I handled it. Nobody needs to worry about it,' or you can handle it and let the event keep bubbling to the route, and people can catch it and do more things with it up higher. Netscape was exactly the opposite. Netscape had what they called the capture model, where you started the route and you walked down to where the thing happened. The compromise in the end was that the default thing would be bubbling, but you could pass a true for that argument and it would capture, and that is really interesting and I do use it, sometimes, usually for things that are like polyfill-y kind of things because you want to say, 'No, I am getting it first, before anybody else.' It's handy. It's worth knowing. There's a current script that probably you should never use, and-
Eric Meyer: So, moving on.
Brian Kardell: Yeah, let's not talk about that one. There's URL. Do you think everybody knows about URL as a API?
Eric Meyer: I could easily say yes because I know about it, but that's the problem that we have, so let's just mention it briefly.
Brian Kardell: I think Automate and Kestra was really instrumental here. You would think that URL, Tim Berners-Lee literally said it is the most important thing of all of the HTP, HTML, and URLs, URLs are the thing. That's the idea, right?
Eric Meyer: Yeah.
Brian Kardell: You would think that there would be an API for that, but there was not an API for that. It turns out that this whole idea of rough interoperability and running code is how it really has worked for all of these years, and there was not actually something we could say, 'This is the standard,' in a truthful way in the web platform specifically, so there had to be a lot of reverse engineering and bug opening and figuring out what we could make compatible and everything. That was all precursor work to a lot of the stuff that's in the web platform and to the fetch work that he was doing. It's really great, too. It's good API, if you ever needed to do anything with URLs. I can't imagine that we... I can imagine, because I lived with it for a long time without having it, and having to write and figure that stuff out myself was-
Eric Meyer: Somehow grab the whole URL and then implement your own parsing of it, you mean?
Brian Kardell: Yeah. It's one of those things that I think if you haven't experienced the pain of doing it, you're like, I don't know. It doesn't seem that hard. It's deceptively simple. You think, it should not be that hard, but it is actually really hard. I think a really good example of this is, do you remember, in the DOM we introduced this concept called a DOM token list? That is the thing that is only, I don't think it should be, but it is only, unless this has changed recently, the CSS API for classes, right, classList.add, remove?
Eric Meyer: Yeah, which we should say, by the way, there's a .classList thing where you can .add(), .remove() or .toggle() class names through a JavaScript API.
Brian Kardell: That's exactly one of those that's deceptively simple, right? You think, well, do we even need an API for that? The answer is yes, very much.
Eric Meyer: Yes.
Brian Kardell: Very much. It is so complicated to not have it.
Eric Meyer: Yep. Having had to code around the lack of that, yes, we need it. Absolutely, 100%.
Brian Kardell: Yeah. There's some other ones that we could talk about. I think .postMessage(), MessageChannel, .outerHTML, I don't know if you know that's a thing. Everybody knows about .innerHTML, but .outerHTML is interoperable, implemented in browsers now, which is huge, too. It's also a little bit weird, .outerHTML, because it's similar to .replaceWith() in that the operation that you're doing is sort of destroying the thing you're operating on, like it's just taking it out of the tree, but it's really handy. What else?
Eric Meyer: Actually, the thing I liked from your list was the print events.
Brian Kardell: Oh yeah?
Eric Meyer: Yeah, because there are a lot more events fired by browsers than I think a lot of people realize. An example that's closer to what I'm used to is the animation events, so if you're animating in CSS and the animation starts and runs and ends, but throughout that life cycle, there are events being fired on the JavaScript side that you can have things listened to. You can listen for the end of an animation so that you wait to do something until an animation has completed, and there are print events, there are print start and print end, or whatever they're called, but there are events that are fired when printing starts and when printing ends, and probably other events, as well. I don't know how often people will need those, but when you need them, it's real crucial that they be there, kind of like with the animation events and so many other events. I feel like browsers are just firing these events all the time for all of this stuff that's happening, and most of us just, A, don't realize, and B, I think maybe don't grasp how much there is there to act upon. Do you know, is there a way to get browsers to just log all of the events that they are firing, because that seems like that would be super useful to just listen for? Somebody could certainly write a thing, and maybe somebody already has. I haven't gone to look, but it just sort of occurred to me. It would be interesting to see what's happening as I-
Brian Kardell: I think it would be impossible to do an unfiltered list, because even mouse move is an event.
Eric Meyer: Yeah, that's true.
Brian Kardell: Scroll is an event, and it would just get really, really out of control. But it would be interesting, I don't know if anybody has put together one of those giant wall charts or something of all the events. There are so many events.
Eric Meyer: Now, I have to go looking for a wall chart and see, has somebody done it in a visually pleasing way so you can print it out at Kinko's or whatever, and frame it and put on your wall so that you have this nice piece of art, so people come in and they're like, 'Oh, that's a really interesting piece of geometric art,' and then when you look closer, it's like, 'Oh, these are all the events.'
Brian Kardell: Yes, it would make a nice oil painting. I have one more that I want to add because I think it's an interesting and important one that I bet most people don't know, Subresource Integrity. Do you know that one?
Eric Meyer: Say that again.
Brian Kardell: Subresource Integrity.
Eric Meyer: You lost me, coach.
Brian Kardell: Tell me if you have ever, like you've used maybe jQuery?
Eric Meyer: For the sake of argument, sure.
Brian Kardell: Sure. Like a lot of people, maybe you loaded it off of a CDN, right? You're like, 'Well, there's CDN that has jQuery, and I will post it from there,' because in prior days, we used to say that you would then share the cache, which is no longer true, but at least today we say, 'Well, you get it from the edge that way.' They have edge servers, so they'll get it faster, be more reliable, but they do go down. They do get compromised. You're not in control of them. Maybe whatever happens, it would break. What do you do if you want the benefits of a CDN, whatever you perceive those to be, but yet you need to have some control over knowing what you're actually including? You have to say, 'No, but I need that control to know that the code that I'm including in my page is not compromised. I am okay including this specific script, but only literally exactly this specific script.' I don't know if you ever remember the days of Tucows and all those, when we would go and download things, or download SourceForge or whatever, and they would always have a, 'Here is a verification, if you hash to the same hash, then it's the same thing.'
Eric Meyer: Here's the MD5 fingerprint or whatever.
Brian Kardell: That's what SRI is. Subresource Integrity is an attribute that you put on your scripts or style sheets or whatever and it includes a hash, and it says that you don't execute this if that hash is not true, so if that hash doesn't happen, then well, you can't be trusted. It's kind of interesting. I feel like it's a little incomplete still, and I followed its development with great interest because well, maybe this is a good place to pivot to the perils of trying to keep up. It's hard, right?
Eric Meyer: Yeah, it's real hard trying to keep up, particularly, you were talking about, and I thought made a great observation, that it's particularly hard if you're trying to stay up-to-date with the absolute latest that's being discussed.
Brian Kardell: Yeah. It's nearly impossible to do that in a not narrow way, in my experience. There's just no way that you could keep up with the whole web platform as it's developing all the time. We just talked about, I don't know, 100 different APIs.
Eric Meyer: It was a whole bunch, yeah.
Brian Kardell: But you could take one of those, like template, just the template one. It was like a few years of discussions on that, and if you were trying to follow along at the time, I don't know how many tens or dozens of hours of my life I have dedicated to that one specific thing, and you have to mentally keep track of all the changes and the problems that arise and the objections that came up.
Eric Meyer: Right. I've been having this even at a distance with the Temporal API in JavaScript, which is all about fixing date, basically.
Brian Kardell: Great example. Great example.
Eric Meyer: Where when I first came on Igalia a couple of years ago, actually almost three years ago, one of the first projects was the Temporal team was working on implementation, but part of the stated goals was to get Temporal documentation onto MDN. I took all the Temporal documentation and I basically worked it into the MDN format so that there would be this whole structure of the way that MDN works, where there's a overall page for the API, and then for each part of that API, there's a sub page that then links out to all of the methods and instances and blah, blah, blah. Anyway, there have been changes since, and so it's never shipped on MDN because there hasn't been enough deployment of actual implementations. It's sitting in a branch that's now quite old, and whatever changes have happened will at some point have to be reflected, or we'll just have to start over. I'm not sure which, but had I basically been stuck in to the details the whole time and updating as I go, that would be a part-time job, probably.
Brian Kardell: Also worth noting that for you, keeping up is easier still than the people who are actively working on it, right?
Eric Meyer: Yeah.
Brian Kardell: Because you can follow from a distance and you can get the two-page summary from them and then ask them some questions, and compress your learning into much smaller sessions than them who are working on this all the time, and then they go do a little implementation, then they have to wait for so-and-so to come and talk, and then together they make some more changes, and they have to loop in more people. It takes a lot. The closer you are to the solution, the harder it is to follow that stuff.
Eric Meyer: Yeah. The CSS Working Group members deal with this all the time.
Brian Kardell: Yeah, exactly. We just talked about template was an example that I used, and I'm just saying, I gave you the, I'm guessing a minute, 30 seconds, I don't know. It was not long, but it's just like it is an element template, and here's what you do with it. You can go look at it on MDN and it will be a really, really small page, and that's it. You can learn about it in an hour, easily.
Eric Meyer: Yeah. In fact, I'm looking at the MDN template page now. It's not tiny, but it's not huge either. I could read this page in 10 minutes tops, and that's with stopping to ponder the various examples.
Brian Kardell: You could then go do some experiments and then probably, you'll mostly know about that now, and you can turn to it whenever you want, but if you were during the development of that, it was a long time. There was a lot of details, a lot of discussions.
Eric Meyer: Was it called the template element at first or was it called something else, and what was allowed in the template element? I'm sure that changed during that whole discussion, and then how could it be accessed and what was allowed from the JavaScript side, I'm sure that went through a whole lot of iteration. Like you say, it was probably a few years of discussion and changing and, 'Oh yeah, we're absolutely going to do this,' and then 18 months down the road, somebody points out, 'Oh, that thing that you're absolutely going to do will absolutely leak personally identifying information,' and so you can't do that. You've got to do it either differently or do something else, and then, 'Oh, crap, we've got to tear all of that out and start over.'
Brian Kardell: It's a bit of a contradiction, because we need more people to follow developing things more closely in order to get more wide feedback earlier, right?
Eric Meyer: Yeah. Get somebody to say, 'Oh, excuse me, but isn't that thing that was proposed a problem in this way?' And then either everyone looks at it and either says, 'Oh no, it's not a problem for these reasons,' or 'Aw, crap. Yeah, you're right.'
Brian Kardell: Yeah, absolutely. Absolutely. I think this happens a lot, where you get a small group of people working on something and then we get an implementation of it, and then as people start to use it, they have observations that you're like, 'Wow. Sure would have been nice to have that earlier.'
Eric Meyer: If only we had known.
Brian Kardell: Right. That's kind of a problem. I don't know. We have a particularly gnarly kind of job because we do try to follow a wide number of things, so to different extents. I don't think that you're probably following TC39 as much.
Eric Meyer: No.
Brian Kardell: Maybe you're following CSS more than I am, and so it's not like we're literally trying to cover everything, but we have everything to cover, sort of, and we talk about it a lot. It's hard to keep up, and even if you are only trying to follow passively, it feels hard to keep up. I'm not actively following a whole bunch of things, and still it is like, wow, where did that come from? It feels like that came from out of left field. When did that happen? I completely missed it.
Eric Meyer: It's not possible to follow everything. You said that earlier, and I 100% agree. There are not enough hours to be able to follow everything that's happening across the entire web platform. There's too much. It would be useful if there were some way to know when things have been decided, more or less, you know what I mean? The CSS Working Group meeting minutes are, I think, a good example of this, because if you're someone who's just sort of interested in what's happening in CSS, like what's being discussed, but you're not somebody who wants to get stuck into the actual nitty-gritty, wandering through the weeds trying to cut a path discussion, if you just follow the minutes of the weekly meetings of the Working Group calls, there will just be a list of these are the things that were resolved in this call.
Brian Kardell: And if you want to see some of the discussion, you can go check it out.
Eric Meyer: Right, yeah.
Brian Kardell: It's pretty good, to the point. It's not literal translation of every word that was said, but it does a really good job of getting all the important parts.
Eric Meyer: Right, yeah. This person made, this person made this point, back and forth, there was this question, this answer, this question, this, we don't know, we'll open a new whatever. Yes, there is a link to the minutes from that summary, but the summary will just tell you, it's like, 'The CSS Working Group resolved that in this scenario, this property is interpreted in this way,' and I wouldn't say a majority, but a notable slice of CSS Working Group discussions about resolutions these days are, 'We decided a thing seven years ago, or even seven months ago, and now there's this other thing that intersects with that in a way that was not foreseen. What do we do?' Scrolling to animations now touch on things like which elements browsers are expected to sort of know what they look like even if they're not on screen? Because the CSS Working Group is actually concerned with that these days. You can't just say, 'Well, only draw the stuff that's on screen,' because something could be just off screen and it's likely to come in, either due to animation or scrolling or whatever, and if you haven't pre-calculated what that's supposed to look like, then the scrolling would be slow, so browsers have to think about that stuff. That's actually part of the discussions is given an animation or given view transitions, how do we deal with the way the view transitions affects these other things? A view transition is effectively an animation. How does it actually intersect with the animation API that we already have, and in what ways are they different? If you have an animation and you're doing a view transition, which one wins, which has the priority? Is just one of many questions that have been discussed about these sorts of things. A notable percentage of the discussion is just, 'Now that we're doing this cool thing, this way cool thing that nobody probably thought about or even could have foreseen 5 years ago, 10 years ago, whatever, how are those going to work together?' Being able to see the resolution, just a list of resolutions, is a relatively low impact way of keeping up with, oh, I see that the Working Group has discussed this and they resolved in this way. You might see that and think, wait, but when I was doing a thing the other week, I really wish that it would default to be the other thing, maybe I should go to contribute that as a use case for reconsideration, or just say, 'Oh, that's cool. I'm glad that they've resolved that, and I see that they're working on things like the intersection of DOM animation and view transitions, and it's nice to see that there is progress there.'
Brian Kardell: I'm glad that you mentioned the minutes because I think about this a lot, because I sort of was doing developer advocacy before I came to work for Igalia. The thing that I was very interested in, because I was burning a lot of my personal time, even my personal vacation time, to go to CSS Working Group and stuff like that, and the way that for a long time I kept up with that is that. You're right, that is actually a really efficient way of keeping up with things that are happening pretty much on the edge, because anything ultimately needs a Working Group resolution and it will wind up going through that channel, and you can once a week spend, I don't know what it would take me, 15 minutes or not more than half an hour to really look at it and consume it and even go out to linked issues and stuff like that. But you're right, that was a pretty efficient way to keep up with what was on the edge of things. I'm glad you mentioned that, because I hadn't thought about it because today, I have to use GitHub for a lot of this. Do you use the GitHub inbox and stuff like that?
Eric Meyer: Not really.
Brian Kardell: Let's see if I can... I cleared this out about 24 hours ago, and I have almost 700 things in my inbox for GitHub.
Eric Meyer: This is why I don't use that inbox.
Brian Kardell: Yeah. But today, if you really wanted to follow everything, it would be GitHub, and for CSS Working Group, that means CSS Working Group Drafts under W3C. The thing with both of those is, though, you sort of are agreeing to take part in speculation, because it's very possible that things that you're talking about, even resolutions that are made, will get unresolved. It's more like a bill passing in Congress than it is a change to the Constitution until it's shipped, right? Then when it's shipped, it's like that is really, really hard to change at that point. There is lots of stuff that is still speculative, experimental, and people aren't objecting, but they're also maybe not actively participating as much yet. Things will change. You are burning time that is not guaranteed to pan out at all, much less in the relatively near future, exactly this way. Today, if you wanted to consume just the CSS Working Group Drafts, it's a lot. To give you some idea, there are currently almost 3,000 open issues in that repo. There are not quite 5,000 issues ever closed, so there's a lot, right? There's a lot to do. There's a lot to track. There's a lot of discussions. It's almost impossible to follow that stuff, and that's just CSS. It's not MathML, it's not HTML, it's not JavaScript, it's not DOM, it's not the URL standard. It's not SVG, not that there's a lot going on in SVG, but there's so many standards, and apologies if I missed your repo from the many. There's Web Platform Tests, which all by itself is a huge thing. It's enormous.
Eric Meyer: There are literally millions of tests at this point.
Brian Kardell: Yeah. I don't know. What would your recommendation... I think a nice way to think about this is in degrees of how much you want to follow near the edge, and then to think about what that means. GitHub is the biggest, that's the shotgun approach. There's just a million things, and some of them, you're going to be like try to grab it as it whizzes past. You're going to miss a lot, but you're going to see a lot. You can waste a lot of time. I don't want to say waste. You can-
Eric Meyer: You will invest.
Brian Kardell: You will invest a lot of time, or you could invest a lot of time. You could also get really the wrong idea about a lot of things, too.
Eric Meyer: True.
Brian Kardell: You have to spend some time understanding where those things are.
Eric Meyer: For each community, you have to take some time to get a feel for what the norms are so that you don't get the wrong impression. Maybe in one community, there's just a cultural norm of everybody just throws out whatever wacky idea they have as an issue, and then people debate it in detail, and then either it gets closed or it continues. But if you're not used to that, if you come from a community where filing an issue means it's already fairly well considered and filing an issue it means that there's a real intent to move forward, you'll get a very different idea, and vice versa, for that matter. If you come from a culture where any idea, you just file as an issue and see what happens, and then you go to a community where we only open issues after it's been discussed and nobody has raised objections, you're going to feel like, wow, they don't do very much over here, do they? If you're going to do that fire hose approach where you're trying to catch stuff in buckets, you also have to understand what temperature is the water of each of these fire hoses?
Brian Kardell: I don't know what's a good, the scatter shot approach, that is just everything, the big, follow it super closely. You're absolutely right, it had skipped my mind that the mailing list, at least for CSS, is a really good one. There is a similar one for TC39, minutes are also posted. I used to use that in the same way. Now, there is What Up, What Up is the one. You know what I'm talking about, right? It's the What weekly or bi-weekly meetings, I don't know how often they are. I can't remember, but they also have minutes now. You could look at those, I suppose. I think they're public. You're right, that's a really good way, but beyond that, I think you could follow people, read their blogs, subscribe to stuff.
Eric Meyer: Yeah. That's a way to do it if people have blogs. Like you say, there is the fire hose approach, which is to just subscribe for notifications on GitHub to all of the various repositories, and then you'll get hundreds or thousands of messages a day. I think the next level back, well, sort of the way that I do things, is RSS, actually. The CSS Working Group blog, which has an RSS feed, they publish the minutes of their telecoms, like minutes telecom. The most recent is 2023-11-22. It has, again, all the resolutions, and then there there's a link to the full meeting minutes, and because of the way that the W3C has stuff set up, if you click through to an issue, all of the detailed minutes are automatically posted to those issues. I subscribe to that RSS feed. I don't know if TC39 has something similar. If they just send summaries to an email list, then I would subscribe to that email list or maybe even try to figure out a way to have that email list ported to an RSS feed. I also subscribe to the RSS feed for the MDN browser compat data releases, so every time a new release is made for BCD, which is the basis for the support tables on MDN, and I know it's at least one of the data sources for Kit I use, but currently a release will show you all of the things that were removed and all of the things that were added to BCD in the current release, and then it'll show you some statistics, which interesting, I guess, but not something I would track. The most recent release three days ago has some JavaScript built-ins that were removed and some WebAssembly stuff that was removed from BCD, and then JavaScript APIs and some CSS properties that were added in. That's a way to get on a high level what's changing at BCD, which it's sort of the next step down from all of the resolutions and discussions and resolutions that happen in Working Groups. Then as browsers actually do things, BCD changes, so it's kind of the next step in the pipeline for me. And then I would think if there are blogs you want to follow, the way you would find those people is by, when there's a resolution that interests you in TC39 or CSS Working Group or whatever and you go and you look at the various discussions and you see, oh, this person talks a lot about this. I'll pick Adam Argyle, because he's in a number of discussions and he also puts stuff out. But anyway, you see someone like Adam Argyle and you say, 'I'm going to track down where Adam is online and follow him there, because I figure that when he talks about CSS stuff or JavaScript or whatever, it's going to be something of interest to me.' That's sort of how I would try to find people, is that way. And then if you just follow sort of the general chatter, you'll see people boosting or retweeting or wherever you are, people that you decide you want to follow. That's what I would do. How about you?
Brian Kardell: I think I follow a lot of people that is also... I like to follow the whole people, so it's not a complaint what I'm saying, but it is full of noise if you're also using those channels on social media to try to keep up with interesting things like this. You will find them, but they are almost like not quite the needle in a haystack, but it is very much the scatter shot. You have to grab things that you notice as they whip past your head, and you're sort of lucky to find them, more or less. But I think I follow a lot of people, also RSS. A good one that I wanted to mention is web.dev. Rachel Andrew started doing a thing a year or two ago called New to the Web Platform in something, so every month she does one of these, and she covers stuff that would be handy for you to keep track of, not just in Chrome, but in all of the things. I think that is kind of good. It does get very mixed up in some details that are a little googly maybe sometimes, but I think that's a really good way to keep up with sort of general things because they're short, they're not particularly long, and they give you just enough information. I also like listening to some podcasts.
Eric Meyer: ShopTalk show is a good one.
Brian Kardell: Yeah, I like ShopTalk. ShopTalk is a good one. I used to like The Web Platform Podcast. I don't think that they're actively producing those. Jake and Surma, and before that, Jake and Paul used to do HTTP 203. That was a great one. I don't know. I'm not just going to plug a bunch of podcasts, but there are a lot of web development-related podcasts, and they are sometimes a nice way to just go for a walk and listen or go for a drive and listen or just have it on in the background and maybe learn something through osmosis. Usually, they're kind of a friendly chat, and that's maybe not incredibly condensed way to learn about things efficiently, but it's more enjoyable to just be part of a conversation sometimes. I think I wanted to sort of plug a thing that... I wrote an article after you and I had already been talking about this for a year I think, and the article I wrote was last year. I'm looking at it is, it is almost exactly a year ago. The article is called The Cool Thing You Didn't Know Existed, and it was, if you recall, I had this idea that you want to think about these things progressively like that. Everybody should not try to follow the CSS Working Group standards repo. It's too much for most people. Everybody should definitely not do that with every single standard's organization repo. It's way too much. You will pick certain things that you want to be more involved in, whether that means following the repo or the mailing list or following people and deep discussions, like maybe you follow Miriam and look on her social media and she posts all sorts of things, you dig into those. Again, everybody shouldn't have to do that, but what I think would be really useful for everybody is to have some way to say, 'This is how I keep up with a basic literacy of what is out there,' so you don't need to know all the details about all those APIs that we've talked about, but it's kind of helpful for somebody to be like, 'Hey, do you know that exists?' And then if you have that in the back of your mind, you go, oh, didn't Brian and Eric mention something about this? And then you can go look. You need something. You need just enough to know that there are things out there that you can turn to. You don't need to know it rote or anything. I've long felt that the things that actually land in the platform are considerably more rare, so that's what Rachel's thing focuses on every month. The MDN BCD data, the browser compatibility data, we worked on, and probably should get back to, because we sort of dropped it because it looked for a minute like maybe somebody else was going to take it up. If other people want to take it up, I'm all for somebody else doing the work.,But maybe we should take that back up, because I still think that an RSS feed that gives you a really nice, something very equivalent to the sort of CSS Working Group minutes, it's just like you can think about it like these are the things that landed this week, right?
Eric Meyer: Yeah. There's a proposal into the Open Web Docs crew to add more information to the BCD release notes that would maybe help a lot with that. But the idea that we worked on a bit was to try to provide more context for additions and removals from the browser combat data release notes, so that instead of just saying, 'This has been added,' or, 'This has been removed,' it would also say, 'This changed, and now it shows support in two of three engines or three of three engines,' or whatever. There is a proposal into Open Web Docs, who manage the BCD release notes, and BCD, for that matter, to add more information like that to the release notes themselves. It might happen, but in the meantime, that would improve BCD and the information there, but that still wouldn't pull in all the other stuff that we've talked about. I still think one of the things that we should consider doing is having an RSS feed that doesn't just provide more context for BCD, but also pulls in this CSS Working Group resolutions for the week and TC39, and whatever else information there is.
Brian Kardell: Oh, you mean like a single high-level-
Eric Meyer: Yeah, kind of. That could say, 'The CSS Working Group had seven resolutions this week,' and then it maybe tells you what the resolutions were, or maybe it says, 'Click here to see what they were.' You don't say, 'Click here,' but you know what I mean. Then you can keep drilling down further. We had talked about this at one point. It was after making BCD information more sort of human-readable and useful is maybe start pulling in other things so that there would almost be like, 'This is the week that was in the web.'
Brian Kardell: Yeah. I don't know if you, so little Dan, Dan Arenberg, who used to work here and then went to work at Bloomberg, he started all these groups, like these JavaScript groups, that were to meet with and discuss things among different sorts of stakeholders. One of them was educators, and there was a lot of like, 'What are we going to do exactly? Do we want to write MDN documentation? What are we going to do?' In that, I proposed that what we lack is this sort of the evening news for the web, the equivalent of that. Something that you can sit down for a fixed amount of time every week and just keep up. It doesn't have to be super detailed. I don't have to teach you how to use this API, but I can make you aware that it exists and, I don't know, how serious it is. This is done, it's shipped in all the browsers or it's shipped in the second one. I think that's doable. It just needs somebody to invest, because it's a lot. To put it all together, you need all the data, right? It's very difficult, but I would still like to see it. The closest thing that I have seen to it is the web.dev thing that Rachel is doing. I believe maybe that might be partially inspired by the work that we did on TC39 things that reached stage, I don't know if it was 3 or 4, but we called it 2 Minute Standards. It had to be 500 words or less or two-minute video, or it was a couple of things you could do, but the idea was a single Twitter account that you could follow, and it will never post more than one tweet a day. That tweet promises that if you read that article, it will take less than two minutes of your time. You could have a feed that's daily, although you will never get daily out of that, or you could do something that's longer. I don't know how long it would be to include all the web stuff. But anyway, I think these are really cool, interesting ideas. I would like to hear what our listeners think. How do you keep up and what do you think that we need or we should do or should have in order to help you keep up? That would be great feedback to hear, so let us know on the social medias.
Eric Meyer: Yeah. I would like to hear both what would help you keep up-to-date in a dream world, and also what's a cool thing that you just learned about recently that you were like, 'How long has this been here?' That would also be interesting to hear, because I guarantee that if someone goes into the replies or comments or whatever and sees, 'I just learned about this thing,' someone else is going to read that and say, 'I didn't know that thing existed, and now I do, and that's awesome. Why did I not know about that?' Maybe that's a thing, is just sometimes I think that's stack overflow. People just asking, 'Hey, how do I do this?' Somebody eventually replies with, 'Oh, that's built in already, you can do that.' But it would be kind of interesting to have a scheduled just group hangout where people share the coolest thing that they learned recently.
Brian Kardell: Oh, that's interesting.
Eric Meyer: Other people could just say, 'Thank you. I didn't know that that was a thing.'
Brian Kardell: That's interesting.
Eric Meyer: And then probably someone else says, 'Oh yeah, that's been around since blah, blah, blah, and here some other things you can do that are similar,' because they already know about it, but organizing that and getting people to show up, that's also work.
Brian Kardell: Sure. That's another thing that might be really cool to just have, I don't know how many people you could get on that, but I imagine you would need more than two to do maybe a Twitch Stream or something. I don't know. That sounds interesting. I think this was an interesting talk. We kind of rambled all over the place, but I think it's a thing that I think about all the time. I constantly want us to do better, to manage better, and I feel like there's not a single answer that works for everybody, but it's these sort of gradiated things where you choose what do you choose to invest your time in and why. I'm really curious what people have to say. Let's wrap it up there, this good chat.
Brian Kardell
Eric Meyer