Show Notes

This episode is made possible thanks to my sponsors, help me continue to make contributions to the web by sponsoring my work.

Socials

You can follow keith on Bluesky: @keithamus.social or Mastodon: indieweb.social/@keithamus

You can follow Lola on Bluesky: lolaodelola.bsky .social and Mastodon: mastodon.social/@lolaodelola

Episode Links

• W3C Web DX Community Group
• W3C ARIA Working Group
• W3C Open UI Community Group
• W3C Community Groups
• TC39
• Web Platform Tests
• Bocoup
• WebKit
• Chromium
• Firefox
• Keith's Igalia Chats Episode

Transcript

[00:00:00] Lola: Hello, good people and welcome to What The Spec, a podcast where I, Lola, unpack browsers and web standards with the people who create them. I'm a former web developer and current independent standards technologist, a member of various open source and standards groups, and an appointee to the W3C technical architecture group.

[00:00:41] I care about bridging the gap between web developers and web standards, which is why I created this podcast. If you enjoyed the podcast, care about this work, or want to support me, you can sponsor me at give.lolaslab.co. Sponsoring independent technologists like myself [00:01:00] helps us to contribute to the web platform.

[00:01:03] Now, let's get into the episode. I'll be talking to Keith Circle about what it was like to go from JavaScript engineer to browser contributor. Enjoy the show.

[00:01:26] Okay, so I have Keith Circle here with me today, and we're gonna get into the nitty gritty of what it's like, contributing to browsers and web standards as a newbie and how he has developed over the last, almost two years now.

[00:01:44] Keith, how are you?

[00:01:45] Keith: I am fantastic. Thank you very much. How are you?

[00:01:48] Lola: I'm good, thanks.

[00:01:49] I'm a little bit tired this morning. I just came back from a run, and I'm not a runner, so my body's my body's not best pleased. So I kind of [00:02:00] wanted to talk to you after I read your blog post. Yes. and it was a blog post about making over a hundred commits to browsers in 18 months. Wow. Do you wanna give people just a little bit of background to that blog post?

[00:02:13] We won't rehash the whole thing, but just a little bit of back background.

[00:02:17] Keith: Yeah. I kind of, I. I guess I set myself a bit of a challenge to get more familiar with contributing to browsers. like I've been a web developer for a very long time, over 20 years, which is kind of horrible to say. I realized recently I'm like transitioning into, somewhat of the old guard, right?

[00:02:43] Like, I go to conferences, I see a lot of new faces and the, yeah, I feel like I'm very old now, but,

[00:02:50] Lola: yeah.

[00:02:52] Keith: But yeah, I thought, you know, I I, I've spent so much time on the web, I haven't really contributed much to browsers. What's it like? right. [00:03:00] How difficult could it be? and I found out, you know?

[00:03:03] Yeah. so yeah, I, I kind of started small and built my way up to the point where it's a very addictive process. yeah. I find, is very interesting. It's very satisfying. Before I knew it, you know, I had dozens of patches on the various browsers. Yeah. Slowly but surely gained the trust. And now I'm ready to, for my world domination tour of, now

[00:03:35] Lola: To become the king of browsers.

[00:03:37] Keith: Yeah. Infiltrate every browser and, uh. Yeah, but you know, it all kind of, there was part intentionality, but it all happened kind of accidentally as well.

[00:03:48] Lola: Yeah, that's really interesting. I've been in tech for about 11 years in July. So not as long as you, but I've not been a software engineer, web developer for that whole [00:04:00] time.

[00:04:00] . I'm very much a try new things, test things out, see things, see if I like things kind of person. So I've done technical support, web development, software engineering, a whole bunch of stuff. And the last role I was in was more like program management. Um . And web standards. So it's like a range of stuff.

[00:04:18] So it's interesting to hear someone who's been like a software engineer, web developer for a long time, and then it's at that mark that you're like, what else can I do? What else can I contribute to? Yeah. And browser seems to make sense. And so. Was the first contribution you made to the browser, was that the first time you were getting into the whole process of browser contributions or had you been involved in standards and other things prior to that?

[00:04:45] Keith: Yeah, so I guess it kind of all happened at the same time, roughly. I don't really recall the exact order, but, working at GitHub, we, I was working on the team called the web systems Team. [00:05:00]

[00:05:00] Lola: Yeah.

[00:05:00] Keith: And, they were very interested in keeping things, aligned to the web platform.

[00:05:07] Lola: Right.

[00:05:08] Keith: and so we regularly had calls with browser vendors, to talk to them about like, well, here are our problems.

[00:05:16] Here's where we would like the web platform to expand. so things like emojis, right? Yeah. We support emojis on GitHub, emojis, support across operating systems and certainly, and browses. Um. Has been a little spotty historically, and so we, yeah, spent a lot of time working with them to try and encourage them to add support, but it's a very complex and nuanced thing.

[00:05:40] so that wasn't so much standards as much as like just, talking with them. But then one day my manager said, we should be more into this. Do you want to go join TC 39? Right. and so I attended 2018, 2019. I was a delegate in, [00:06:00] TC 39 working on, the JavaScript standard, for, for those unaware.

[00:06:07] TC 39 is the, is the technical group, the 39th technical group of ECMA, ECMA being the standard body. They do a lot of different standards. but the ones that are relevant to the web are probably like JSON and right JavaScript. so TC 39 handles JSON and JavaScript predominantly. Um. Yeah, I was there just helping.

[00:06:33] so I, I think a big thing with standards groups that I certainly was woken up to the idea, when working at TC 39, that there is, probably a lack of what I would call web developer representation in cases.

[00:06:51] Lola: Absolutely. Yeah, yeah, yeah.

[00:06:52] The same is true for the W3C.

[00:06:54] Keith: Oh, yeah, yeah, absolutely. Yeah.

[00:06:56] Yeah. Like the TC 39 meetings. I remember one meeting I went [00:07:00] to, there was probably 150 people, and at least 60 of them were from Google.

[00:07:05] Lola: Yeah.

[00:07:05] Keith: and so it was huge. There was a lot of people, but there was also like, it was, you know, the majority were Googlers.

[00:07:16] Lola: Yeah. And the

[00:07:17] Keith: majority of those were developers on the browser.

[00:07:20] And

[00:07:20] Lola: yeah,

[00:07:22] Keith: I think there's a bit of a disconnect. or maybe disconnect is the wrong word, but there's like. Some, something that I didn't really appreciate beforehand was that, you know, engine implementers write C++ all day, right? Yeah. The, the, the people writing the JavaScript engines don't really write that much JavaScript.

[00:07:43] They write a lot of C++

[00:07:45] Lola: yeah.

[00:07:45] Keith: and they don't, they're, they're, what they're developing at, at scale for a lack of a better term, is a JavaScript engine written in C++

[00:07:56] Lola: yeah.

[00:07:56] Keith: They don't have the, they don't necessarily [00:08:00] have the kind of, or they don't necessarily face the problems, that developers who are writing JavaScript at scale do.

[00:08:08] Lola: Right.

[00:08:08] Exactly.

[00:08:09] Yeah.

[00:08:09] Keith: and so it was, I was really woken up to the idea that we need more web developers, in these standards bodies. we need more web developers talking to browser vendors

[00:08:24] Lola: Yeah.

[00:08:24] Keith: And showing them these are the problems we face and we, this is what we would like fixed.

[00:08:29] Lola: Yeah, I think that's a really, really great point.

[00:08:32] It's something I'm really passionate about. Yeah. I think there are many, chasms, shall we say, between standards and developers on multiple different levels. And I think when it comes to creating new web features and even, you know, improving on older web features as well, there's a disconnect.

[00:08:56] I, I think that is the right word. There is a, a bit of a disconnect between the [00:09:00] people who are making and creating and implementing in the browser versus the people who are using every day, be that on a small scale or, like enterprise level, you know, as a company like GitHub would be using. Yeah. and I think that's where groups like Web DX, which is a W3C community group, kind of can play a really big role.

[00:09:22] Also, organizations like Open Web Docs and MDN and things like that play a really big role in, in educating developers. but at the same time, I really think we need to see more developer, like people who do web development as their full-time jobs in these standards bodies. I think it can really, really help.

[00:09:48] Um. I guess carve the path, the direction some of these features can go in and, and, you know, stop them before they go too far in a direction that may be [00:10:00] contrary to what web developers need, you know?

[00:10:02] Keith: Absolutely. Yeah. Yeah. I a hundred percent agree. and so, yeah, like one of the things that's kind of been a follow on from the work at TC 39, like I kind of, for, for various reasons, I ended up, so my attendance dropped on TC 39.

[00:10:20] Lola: Yeah.

[00:10:20] Keith: but I picked up, I, I worked with a few other, standards groups. So most of my time now is spent in, the HTML working group and the ARIA working group. but also Open UI which is a community group. Right. And so the Open UI community group, anyone can join, anyone can, like participate, have opinions if, if you care about the web and you care about it's evolution. Yeah. Especially I think the open UI working group is especially interesting because there's a lot of effort on form controls.

[00:10:57] Lola: Yeah.

[00:10:58] Keith: and like interactivity, [00:11:00] which I think historically maybe HTML hasn't been the most interactive platform. Right? Yeah. I think that, that there's like a bit of a tide change there because of groups like Open UI.

[00:11:13] yeah. So I'm really positive about that. and that's where I'm putting a lot of energy in. but I think it all kind of intersects, right? If, if Open UI is concerns are making high quality, accessible, applications on the web.

[00:11:31] Lola: Yeah.

[00:11:31] Keith: using like rich form controls, a lot of that intersects with accessibility.

[00:11:37] A lot of that intersects with HTML.

[00:11:38] Lola: Exactly. Yeah. Yeah. Thank you for that. That is like a really in depth, journey of how you got here. How did the culture of your team, help with the confidence for you to contribute? It seems like the GitHub Web Systems team was already kind of primed for, you know, contributing to [00:12:00] the web in some way or another, whether that's discussions with browsers or attending TC 39, but in terms of making actual technical contributions to browsers, what, what about the culture of the team helped you do that?

[00:12:14] Keith: Yeah, so I think GitHub, it's, it's a big company, but, for a long time we've still had that kind of startup mentality,

[00:12:23] Lola: right?

[00:12:23] Keith: and so people were able to kind of, you know, there was no like fixed discipline, right? Right. Everyone can, write on, let me try again. There's no fixed discipline.

[00:12:38] Everyone can work on the backend, the front end, wherever you want, like all of the, private repositories that we have. with all of the source code, like everything is accessible to all employees. So if you want to go work on search or if you want to go work on the front end or if you wanna go work on the database stuff, like, they're all there and they're all in different languages as [00:13:00] well.

[00:13:00] Lola: Right.

[00:13:00] Keith: so on any given day, you know, I'm, I'm writing less and less JavaScript these days and a lot more like Ruby, Go

[00:13:11] Lola: Ruby's my favorite language. That, that was a language that introduced me to software engineering. I love Ruby.

[00:13:16] Keith: Ruby's an awesome language. Yeah. It's, it, it, it really is, underrated.

[00:13:23] it's super expressive, especially with Rails. Like Rails is a is a fantastic framework. Um. Yeah, we, we, you know, I've, when I joined GitHub, I was very much in this mindset that I am a JavaScript specialist. Like, before GitHub I was like a consultant for, I don't know, 10 years odd. Okay. And I was just going to different companies and consulting them on like their front end, right.

[00:13:49] you know, improving their tests. the big thing, back then was people didn't really write unit tests for frontend, right. I think it's gotten [00:14:00] a lot better now. but that was where I went to different companies and said, you know, here's how you would test your front end. Here's what you can do. towards the latter end of that, that was like writing a lot of react and writing a lot of tests around React.

[00:14:14] Lola: Yeah.

[00:14:14] Keith: so that was kind of my mindset going in was like, I'm, I'm, I am the person to do JavaScript. They, you know, I joined and they're like, well, we, we don't really do that. You just write whatever, you know, the language is a tool, it's a means to an end. yeah. And that was amazing because that really opened my eyes.

[00:14:32] I'd, I'd never written Ruby before, but they just . I'd never written C before.

[00:14:37] Lola: Yeah.

[00:14:37] Keith: My first contribution at GitHub, was, fixing our SemVer sorting and all of that is written in the C library.

[00:14:46] Lola: Oh, wow.

[00:14:47] Keith: I was like, I've never written C before. And they're like, you'll figure it out. Don't worry.

[00:14:51] I was given all the support and everything, but it was like, this is, you know, the language is not the important bit. The important bit is fixing behavior for [00:15:00] our customers. yeah. So that it,

[00:15:02] Lola: and it's like finding the right tool for that thing for them to do that.

[00:15:05] Keith: Yeah.

[00:15:05] Yeah. Absolutely. Yeah. And so one thing the Web Systems team does is, catalog cross browser bugs, and we document where we are applying a fix in our code. But we also track, where the browsers, that, that represent the, the browsers that have that bug. We track that as well. So we've got like a list of like, here are the bugs in the browsers that we've experienced. Here's where we fix them, or here's the related tests or whatever.

[00:15:37] And whenever we have free time, we, we just would go fix them. Right. And so all of my colleagues have had small contributions to browsers before as well. . and it was a pretty kind of, it, it was a, it was an easy on ramp for me because, my manager David, who had contributed, [00:16:00] some small patches to Firefox .

[00:16:02] pointed me to this like, focus issue on details elements I think it was, and said, can we go fix this? It's, it is only a bug in Firefox. We can just, we can just fix this.

[00:16:12] Lola: Right.

[00:16:13] Keith: So we did, um. I was like, wow, this is easier than I thought it would be. Yeah. Like, I thought that this would be this insurmountable challenge.

[00:16:22] Even getting contributions, like even contributing to a browser felt like this mountain to climb.

[00:16:29] Lola: Yeah.

[00:16:29] Keith: But it, it's kind of like anything, you know, it's, if, if you've contributed to an open source project before the, the browsers are more complex than that, than a lot of open source projects, but it's all kind of the same thing.

[00:16:42] Yeah. You know, you send a CL or like a PR or whatever you wanna call it, you send a patch.

[00:16:46] Lola: Yeah.

[00:16:47] Keith: they accept it. They merge it. That's it. there's, there's little fanfare. and so yeah, I, I've continued to try and espouse this idea [00:17:00] that like we can contribute to the web, and like manage to encourage many of my colleagues to do the same.

[00:17:08] Lola: Yeah.

[00:17:09] Keith: Um. So some of my colleagues, Lindsay, did a wonderful job, doing some patches to WebKit, right, including some accessibility fixes. Clay has been doing a wonderful job. More recently, we've been working on, a feature for headings, instructed documents. Nice. Mare, one of my colleagues, Mare has been doing like 90% of the implementation work for Observables in WebKit, which is awesome to see.

[00:17:39] Lola: Yeah.

[00:17:40] Keith: and for me, I think it's really rewarding and encouraging to see that given the right kind of mentorship,

[00:17:52]

[00:17:52] Keith: you can kind of just set people off on this path.

[00:17:56] Lola: I'm glad that you mentioned that. So selfishly, [00:18:00] the next phase of my career I think is going to be contributing to browsers. I think I have a good standards background and I can leverage that to make browser contributions as well, and also having the experience as a software engineer with developer as well.

[00:18:18] Yes. however, it's been very difficult for me to find that support, that mentorship, that one-on-one. And from what you've been saying, it seems like that has been key to not just only your development within GitHub, but also you collaborating with other colleagues and introducing other colleagues to, contributing to browsers in general.

[00:18:42] So what specifically has been most helpful for you in navigating these code contributions? Has it been like a mindset? Has it been the one-on-one mentoring, peer programming staff? How have you, tried to like, learn this new stuff and navigate these very complex systems?

[00:18:59] Keith: [00:19:00] Yeah. Yeah. I think it's important to acknowledge, I have a lot of privilege in this regard.

[00:19:06] Like I work at a big company, the, I work at a company who pays to participate in the W3, like yeah. GitHub's, parent company is Microsoft, right? Right. Microsoft and GitHub. Microsoft is a W3 member. so I can just turn up effectively. Yeah. Like I need sign off from the W3 reps at Microsoft, but I just ask and I get it and I go and turn up.

[00:19:34] So

[00:19:35] Lola: yeah,

[00:19:35] Keith: joining the ARIA working group, for example, like, you know, for me is, is is pretty straightforward. And, and there are people there who, just like any other working group, all, all working groups. Encourage kind of participation. Yeah. And so if you turn up and you say, I'm gonna work on this, you'll usually find someone who will be able to help you.

[00:19:58] [00:20:00] but I have also been very fortunate to have excellent mentors. Yeah. So my manager David, was an excellent mentor, really showed me that like, we can get in our heads and overcomplicate things

[00:20:15] Lola: Mm. and

[00:20:15] Keith: set up artificial barriers for ourself. Mm. And, things are probably, simpler than we, allow ourselves to think sometimes, you know, like I, again, I'll, I'll say, you know, I, I kind of pitted myself as this JavaScript expert, but.

[00:20:36] It doesn't need to be that way. Right. I don't need to say, I can't write C++ just write some C++. Yeah, there's challenges. It's not, it's not, you're not gonna be a zen master at C++ day one, but like, try it. Just write some, you know, it, it's, but also having, I've got some excellent, people that have mentored me through patches.

[00:20:56] so again, so that whole Microsoft [00:21:00] thing, right. that allowed me to go to TPAC, which is the W3 annual plenary.

[00:21:06] Lola: Yes.

[00:21:07] Keith: And there, I literally just stuck my laptop in front of Rasika, who is a, one of the, core DOM team developers at, WebKit at Apple.

[00:21:18] Lola: Yeah.

[00:21:18] Keith: And I just said, I can't build Safari, can, can you help me build safari?

[00:21:23] I'm trying to add this feature. I've added this new file, I can't figure it out. And I just literally stuck my laptop under his nose and he goes, yeah, here, here, you just need to do this.

[00:21:31] Lola: Yeah.

[00:21:32] Keith: and like having that access is really important. or has been really important for me. It's difficult. I don't know how exactly to replicate it for those who are like, yeah, not in the same kind of privileged position.

[00:21:44] but, you know, if, if anyone does want to contribute to browsers, I'm always, happy to have people reach out. I'm happy to guide people. you, you,

[00:21:53] Lola: you, you said that, and you're gonna have a thousand emails in your inbox after this episode drops.

[00:21:59] Keith: I, I mean, I [00:22:00] hope, I really do hope it's like, yeah. it would be wonderful to see more contributors.

[00:22:04] Lola: Yeah.

[00:22:05] Keith: but yeah, like Mason on the Chrome team as well. I, I, I can't not mention Mason, but he's been super helpful, guiding me through a lot of stuff. reviewing patches. He's reviewed most of my patches, on, on the Chrome side of things. And so, yeah, like. I'm not trying to name drop all of these people, but I think it's important to recognize that,

[00:22:30] Lola: absolutely. Yeah.

[00:22:31] Keith: That's how you can make these contributions is making sure that you find those support networks, making sure you find the people that are, that are able to mentor you and help you through these things. yeah,

[00:22:44] Lola: and I will say as well, most of the browsers have some kind of open forum that you can join to ask questions.

[00:22:52] So WebKit are on slack. lady Bird are on discord. chromium I think is a little bit more complicated. You have [00:23:00] to yeah, get to a certain level, but you, I think there is a mailing list or something that you can email for them as well. So, um. There are ways to, tap into the community, around these browsers and talk to other people who are building on them and developing on them who may, who may or may not necessarily work for X company, whether that's Google or Apple or whoever else.

[00:23:25] so yeah, I I think it's really important to also name the fact that yeah, you work for a subsidiary of Microsoft. Yeah. And Microsoft have the money and the resources to support you in doing this work. And then you also work on a team where you are not the first person to contribute to a browser, you know, and you have people around you who are supportive and encouraging and helpful.

[00:23:48] And you can go to these events where you meet the people who are actually doing the thing and just be like, I need to build Safari. I can't build Safari because I'll put my hands up. Right now, I have struggled to build Safari on my Mac. It's so [00:24:00] difficult. for me. I dunno what I'm doing wrong, but I'm doing something wrong.

[00:24:04] and so. Having access to these things and these people is definitely a privilege. But, not being in those circles doesn't mean you cannot contribute. There are other ways to gain access as well.

[00:24:16] Keith: Right. And, kind of on that point, so, so community groups are a really good way to enter into this.

[00:24:24] They don't require W3 membership. They don't require ECMA membership. You don't have to pay any money to anyone. Yeah. You can turn up, and people do. And, if you have opinions, they are welcomed. if you have the ability to contribute, there are various ways you can do that.

[00:24:43] Lola: Yeah.

[00:24:43] Keith: One thing that I have tried to espouse is, write tests.

[00:24:50] tests are probably simpler than you might imagine. Um. The Web Platform Test suite exists? Yeah. [00:25:00] WPT, it is basically a bunch of HTML files. So if you can write HTML if you can write a code pen demo that can represent a bug, cross browsers a bug, that you can port that into WPT. it is HTML and JavaScript that you, the only new things you all need to learn is like the testing framework that they use.

[00:25:21] Lola: Yeah.

[00:25:21] Keith: But other than that, if, if you can write a code pen demo, you can write A WPT. And so, I would encourage anyone, if you have a cross browser bug that you're aware of, that you're just, like you've raised an issue, you've got a code pen demo or something like that, and, and you're kind of sitting on it, A WPT will will be a good path forward. Yeah. Because that puts it in front of the browsers. they, they all import this web platform test suite. They all use it. It's their own kind of internal, test suites for all their CIs and stuff.

[00:25:55] Lola: Yeah.

[00:25:56] Keith: And so they will, you know, they strive [00:26:00] to keep good, web platform test scores.

[00:26:02] And the same for JavaScript. If you've got a JavaScript bug, the test suite is called Test 262 I think it's more, JavaScript oriented, less HTML oriented. but again, it should be an easier lift to write a WPT or a Test 262 test than it is to contribute to the browsers.

[00:26:23] Lola: Yeah. And I just wanna take a moment to big up my, uh. I guess past employer, but I still have a really good relationship with them. Bocoup, they both contributed heavily to creating Test 262 and WPT, and getting all of that set up obviously in collaboration with others as well. and on the WPT thing as well. I do wanna echo Keith's point that I do wanna echo your point there in that it is such a great way to get into it.

[00:26:53] Now, you may not have a bug that you want to recreate, but there are outstanding tests. There are things that still need to be [00:27:00] tested. For example, a bunch of accessibility stuff. Still needs test written for them. So you can, you can submit an issue, you can see what issues are, available, something that hasn't been taken, has not been worked on.

[00:27:14] and try and navigate, WPT. It's a really, accessible, I think for web developers, people who are familiar with HTML in particular, and JavaScript to get a bite, get a taste of what's happening in the browser. Cool. So I kind of wanted to switch gears a bit.

[00:27:35] Keith: Sure.

[00:27:35] Lola: And I wanted to know more about what you did to ramp up on the technical side when it came to contributing C++ code.

[00:27:45] Yes. You work on a team that's kind of like diverse in terms of programming languages, but there is a massive jump from JavaScript to C++, especially when you have to think about memory allocation and garbage [00:28:00] collection and all of this kind of stuff. And I think those are the things that scare people.

[00:28:04] So what did you, have to do? What did you feel like you had to do? And the follow-up question is, when did you feel like you were ready, with the learning C++, or navigating C++ to say, yes, I can actually contribute this C++ code? It's, it's legible. It's good enough.

[00:28:24] Keith: Oh yeah. I think it probably happened the other way round.

[00:28:28] Lola: Okay.

[00:28:29] Keith: like. I think the, the internet is interesting because if you're wrong on the internet, someone will correct you.

[00:28:37] Lola: Yeah.

[00:28:37] Keith: and I think that's kind of also true for code. So if you can get something functional, if you can, if you can, write a patch for a browser that does what it needs to do.

[00:28:50] Lola: Mm-hmm.

[00:28:51] Keith: I wouldn't worry about like, the purity of the code, the cleanliness of the code. because that's what reviews are for. right. And so, [00:29:00] you know, my first Substative patch, I guess, took like a month of reviews. Like the reviewers were very patient with me, but there was obviously a lot wrong with it.

[00:29:11] and I didn't know enough C++ to, really, I, I, I don't even know if I still know enough C++ like, I understand like, like, uh. I think the, the biggest change, between JavaScript and C++ is the kind of memory management side of things. And like conceptually, I understand pointers, but they still trip me up a lot of the time.

[00:29:38] Lola: Right.

[00:29:38] Keith: luckily the compiler, even though the errors that it outputs can sometimes be a little confusing, the compiler will tell you when it's wrong.

[00:29:48] Lola: Right.

[00:29:49] Keith: and yeah, writing tests helps a lot there. but, but submit a patch, you know, as long as it works, reviewers will [00:30:00] encourage you to write it in a particular style.

[00:30:03] but this is the thing is C++ is such an interesting language because, especially with the browsers, there are, they each have their different flavor. And so some browsers, like WebKit uses quite a lot of the standard library, C++ functions, whereas, the other browsers use a little less.

[00:30:25] so they have their own implementations for like vectors? yeah. Or like they, they each have their own implementations for smart pointers.

[00:30:34] Lola: Yeah.

[00:30:34] Keith: so there's, there's a lot there that's not so much learning C++ there's learning the idioms of a particular browser code base.

[00:30:45] Lola: Yeah.

[00:30:46] Keith: but because the code bases are so large, I think if you are someone who's worked on a large code base before, you'll probably find it more familiar because, [00:31:00] you're not really writing stuff from new.

[00:31:03] a lot of what you want to do is search for existing precedent. And this is where I think, knowledge of the word platform can become a bit of a superpower. Right. If you are a C++ developer versus someone who just knows the web platform but doesn't know C++ I actually think you'll be more successful if you're someone that knows the web platform because you can pattern match.

[00:31:26] So many times I have been looking at a piece of code and, like for a new feature I wanna implement, and I'm like, how do I want this to work? And I'll say to myself, well, I want it to work just like this feature. . Like, I've got a pseudo selector, and I want it to work just like the duh or the lang pseudo selector.

[00:31:46] So the easiest thing for me to do is pattern match and just look up the code for those, try and understand the code for those, and kind of copy and paste bits and kind of, you know, make this Frankenstein new version based on, the code [00:32:00] from, from the other pieces of, of, of the code base. And that's kind of encouraged because for any big code base, you don't want novel code.

[00:32:08] you want stuff that is, uh. Already in the code base. Like you want stuff that relies on existing precedent because it makes the code base more homogenous.

[00:32:18] Lola: Exactly. Yeah.

[00:32:19] Keith: And it's a good, healthy thing for a code base to be.

[00:32:22] Lola: Yeah.

[00:32:22] Keith: And, and that's something, something I definitely learned at at GitHub, because we have a gigantic code base.

[00:32:29] I think if there are any developers out there who think, you know, they're, they're working on a code base that's like on the order of millions of lines of code, browsers are obviously also on the order of millions of lines of code, if not tens or even hundreds of millions of lines of code.

[00:32:46] Lola: Yeah.

[00:32:47] Keith: so, so they are very big code bases.

[00:32:50] Probably what you are doing in some way or shape has been done before. So just look for that thing and, and apply it here. Right. And that's where that knowledge of the web [00:33:00] platform really can help because if you are, if you have a good enough knowledge of the web platform, you can pattern match these existing features to the new features or, you know, uh.

[00:33:11] Figure out, like if you can figure out the semantics, you can apply the semantics of what you know about how A works to the code base. Yeah. And you can say, well, I don't know, like a big thing is like styling validation. like you, you know that like when CSS, when a CSS selector changes, the style has to be invalidated somehow.

[00:33:34] Lola: Yeah.

[00:33:34] Keith: And if you can kind of figure out how in each of the browsers, then you can see how that works. You can kind of, figure out how the general pattern for style invalidation then you can figure out how to make any selector that you want. Right? Yeah. Because all of the browsers kind of do the same thing.

[00:33:51] They'll have a parsing phase for CSS and then they do, they build a tree and then they do style invalidation. And

[00:33:58] Lola: yeah.

[00:33:59] Keith: [00:34:00] if you can figure those like concepts out and you can apply them, then you can kind of move through the code bases and apply those patterns anywhere. Um. Hopefully that makes sense.

[00:34:11] Lola: Yeah, no, that does, and it's interesting because, I, I think I, I've been approaching things the other way around where I'm like, okay, I'm not a C++ developer. I need to learn C++ and so, like, I'm doing all of these tutorials and things, and it's like, I kind of feel like I'm wasting my time.

[00:34:29] Not in a, the information is useful definitely, but I'm following resources for people who maybe have never coded before or who are new to coding. And you know, as you said before, like a lot of these programming languages, a lot of the stuff is the same. And so it's like. I don't wanna skip ahead. 'cause I'm like, if I skip ahead and I miss something important, that's gonna burn me later on.

[00:34:54] But at the same time, I'm just kind of like trugging along through this stuff. It's like, yes, I know variables. Yes, I [00:35:00] know arrays, oh, C++ uses vectors instead. Yes, I understand. What a vector, you know, and it's just, it's kind of like slowly. So yeah, maybe I'll just try what you did and just be like, okay, let me just go into the code base.

[00:35:13] Which I, to be fair, I have done, but it's just, it can be intimidating, you know?

[00:35:17] Keith: Oh, yeah, yeah.

[00:35:19] Lola: Seeing millions of lines of code and trying to figure out what things are called and how to search for them and all of this kind of stuff. But yeah, no, maybe that's just what I need to do. and just jump into the deep end.

[00:35:32] Keith: Yeah. the, the, the thing I have found, I, I don't really enjoy a lot of the learning resources out there. I don't think I'm the right fit for those things.

[00:35:45] but something. Like when, when I, I mean, I'm kind of doing the same thing I've always done. right. When I was a kid, I was like, I wanna build a website.

[00:35:56] I have no idea how, but the thing that I want is the website. I [00:36:00] don't wanna learn HTML, I wanna build a website. The website. Right. And so I just built one and it was terrible. And I learned why it was terrible and made it better, but the motivation there was I'm building this website.

[00:36:11] Lola: Yeah.

[00:36:12] Keith: and I think if you go in with that motivation, at least for me, that's like a much easier way to learn because Yeah.

[00:36:19] I will struggle through trying to do what I want to do. Like my goal here is implement this feature.

[00:36:26] Lola: Yeah.

[00:36:26] Keith: And it will take me for times longer than if I were a proficient C++ developer. But in that time, I've left behind in my wake like a, a sea of mistakes. Yeah. but all, all of those accumulate to the knowledge that I now have.

[00:36:42] Right. And so it's like. For me at least, like the, the reductive way to say this is, I think like a good program is just really a collection of their past mistakes. Learning those, learning the hard way every single time.

[00:36:55] Lola: Yeah.

[00:36:56] Keith: but yeah, so, so the, the [00:37:00] theory of it is less important to me. I, I know some people really enjoy learning the theory of it.

[00:37:04] they really enjoy understanding the mechanics of the language.

[00:37:08] But again, i, I kind of fall back to that mentality of the language is the tool. It's the means to an end, that the product is important. And if it can do the thing that the customer wants it to do, that's the, that's the like metric for success.

[00:37:24] And when we, if we can get to that, everything else doesn't matter. yeah. And some people have different ideas and like, it's good for a good, like an, a big organization or, or a browser to have people who care about code quality and stuff. And I'm not, yeah. One that I don't. I don't not care about code quality, but I care more about the end product.

[00:37:45] Lola: Yeah. Yeah. Yeah. Thank you for that. I'm gonna ask you something which may be a bit controversial. Which browser did you find it both easiest and hardest to contribute to as somebody who was [00:38:00] completely new to contributing to browsers? And, you know, this may have changed over the last couple of years, but try and think back.

[00:38:07] Keith: Yeah. so each of the browsers has their own kind of different style. and I guess it depends on what kind of developer you are as to whicH1 you, you'll, gel with. Yeah, yeah. Well with, yeah. to me WebKit looks very like the style, the code style of WebKit looks a lot like JavaScript. They care a lot about the aesthetic of the code base and, um.

[00:38:39] A lot of the functions are very clear, they're very plain. it's a very pleasant code base to work with. But I do think that WebKit relies quite heavily on institutional knowledge, and I don't think that the documentation is on par with the others for external contributors

[00:38:57] Lola: plus one to that.

[00:38:58] Keith: Yeah. So, [00:39:00] like, I've seen a lot of people, and I've worked with a lot of people to try and get them, contributing, like a, a half dozen people at, GitHub and others outside. and the, the, the big barrier for WebKit and from what I see is just like getting it compiled, getting it working on their machine, and then adding files and doing the kind of things that you would expect to do fairly easily in like a standard project Yeah.

[00:39:25] Can become quite difficult. But once you are over that, it's, it's a very pleasant code base to work with.

[00:39:32] Uh. I think Firefox is the easiest to get running. but everything is very different. they rely a lot on macros in C++, which can be very strange coming from a language which doesn't have macros.

[00:39:50] Lola: Yeah.

[00:39:50] Keith: the, but the, the tool chain is really easy. I think anyone could, you can pretty much, you need to install mercurial probably, [00:40:00] which is different to Git. And so you're gonna have that barrier first. But if you can clone the code base down, you run one command and you, and it'll be built in 20 minutes, 30 minutes on a

[00:40:11] Lola: wow.

[00:40:13] Keith: but, but then navigating the code and writing the code can be a little daunting.

[00:40:17] Lola: Challenging.

[00:40:17] Keith: Yeah. 'cause it's so different from what you might look at a file in JavaScript and recognize the parts. Yeah. It doesn't look like that in, in Firefox. yeah. So, so Firefox is kind of. You know, the, the, the, the compilation process is really smooth.

[00:40:37] but the code base is a little more chaotic than the WebKit.

[00:40:41] Lola: Mm.

[00:40:43] Keith: Chrome. Oh, Chrome. It's,

[00:40:49] Lola: that was a deep and heavy sigh.

[00:40:50] Keith: Yeah. Yeah. the, the massive barrier for Chrome is that it takes about nine hours to do a full compile. Yeah. [00:41:00] that is what I have found dissuades a lot of people, just trying to get people to compile Chrome is like an effort in a bit self.

[00:41:09] Lola: Yeah.

[00:41:10] Keith: it's massive. and it has a lot of dependencies, which it compiles in as well, which I don't think the other browsers have. if you are lucky enough to. be a Google employee or be one of Google's partners that you can get access to the shared build system, which takes that nine hour compile down to about 20 minutes.

[00:41:33] Lola: Oh, wow.

[00:41:34] Keith: but they don't give that out. They, you have to be like a pretty prolific contributor to get access to that. Or, some other companies, some other big companies like Microsoft have their own thing for that as well.

[00:41:46] so yeah, Chrome is not for the faint of heart. it does take a very long time to compile.

[00:41:54] but that gives you a lot of time to read through your code and make sure it looks right.

[00:41:59] Lola: Yeah.

[00:41:59] Keith: So, [00:42:00] but yeah, it's, it's, Chrome is a very complex, browser. I, depending on who you are, I would steer you more towards either WebKit or Firefox, because they're just, uh. Firefox, it's easier to build, but the, but the code itself is a little chaotic.

[00:42:20] WebKit has very clean code, but the, the build steps are a little harder to get to. So depending on who you are and what kind of, persistence you have, what, what kind of,

[00:42:30] Lola: your, your patience level.

[00:42:32] Keith: Yeah. Yeah. The pains that you are willing to tolerate depends on what you'll end up doing. but they're all super fun to, to contribute and, you know, it can't be said enough, but people are really willing to work through helping folks to contribute.

[00:42:47] Lola: Yeah. And so what I'm hearing is, if you wanna run Chrome on your local machine, take a full working day to figure that out. Yeah,

[00:42:57] Keith: yeah, yeah. Before I got access [00:43:00] to the shared build thing, I would, every Sunday. Pull down and, compile the, like, main branch overnight. So like Sunday evening, I'm like, one of my chores for the week ahead is to compile and pull and then never rease in the week, never pull down anything in the week.

[00:43:20] Right. It was working enough of whatever was compiled on Sunday.

[00:43:23] Lola: Yeah.

[00:43:24] Keith: because, you know, while it's a nine hour fresh compile, it's like you can, like, if you're editing one file, it will probably take 10 minutes rather than nine hours.

[00:43:35] Lola: Yeah.

[00:43:36] Keith: but it depends on the files that you edit. If you edit like one of the header files for Element or something, it's gonna take like an hour to compile.

[00:43:43] It's very painful. But yeah, Firefox is, is definitely, one of the easier ones to compile.

[00:43:53] Lola: And then one of the more harder ones to navigate. It swings a roundabouts here, folks.

[00:43:58] Keith: Yeah. Yeah. So, [00:44:00] there are tools as well to help you navigate the code because they're such large projects, getting IDs, working with them can be a bit of a difficulty.

[00:44:09] yeah. Google has, I need to remind myself of the URL, Google has source.chromium.org. Okay. And that's like an interactive, code search and explorer. Yeah. if you can get used to that, you can kind of learn how to navigate the code base using your browser rather than your id, WebKit's on GitHub.

[00:44:32] And so WebKit is, you can use GitHub search, you can use GI as you would, any other git project. so that's pretty straightforward. Uh. Firefox uses Mercurial. They have their own system for contributions with fabricator, and there's a third party tool called Search Fox, which is search fox.org. and that's how you would use you.[00:45:00]

[00:45:00] That's the equivalent of Source dot chromium. so use Search Fox if you wanna search for parts of the code and you can use the Interactive Explorer and all that kind of stuff in there.

[00:45:09] Lola: Cool. Okay. We're gonna take a quick break and right after we will be back with a short game. This is just a quick break to say if you are enjoying this episode, don't forget to share with your friends and communities, or leave a review where you listen to podcasts.

[00:45:27] Thank you. Now back to the episode. Alright, we're back. Now we are going to play a short game. And this game is called Patch Notes from the future. The premise is you have to say one browser feature or web API that you'd bring back from the past one current feature that you wish never existed or that you'd change or an invented feature and it can be real or it can be absurd that you could create if you could. And I think this is gonna [00:46:00] be interesting because I think you've already been, especially for that third one, you've definitely been working on stuff and inventing things. but for the first two, one browser feature or web API that you bring back from the past and one current feature that you wish never existed or that you would change.

[00:46:19] Keith: Yeah. Yeah. These are awesome questions. so the, the feature I'd bring back from the past, which is something I'm actually trying to do, is, um. The, the, the Heading Structures, ages ago it was proposed that rather than like H1, H2 all the way to H6

[00:46:43] Lola: yeah.

[00:46:43] Keith: It would just be one element that was H for a header. And the browser would just figure it out. The browser would figure out all the heading levels for you. because you could combine it with like the section element, right? And so the section would say, here is a new, like, [00:47:00] a new part of the document that's gonna have a different heading structure.

[00:47:05] And all the Hs in that section would be shifted by one. Right? Right. So your, your top level H would be your H1, your, you put a section and anything inside that's gonna be an H2 a section inside that, any h is gonna be an H3 and so on.

[00:47:19] Lola: Yeah.

[00:47:20] Keith: The problem is that's really difficult for the browsers to figure out, because you have to like traverse the tree up and down and do all this kind of stuff.

[00:47:30] Lola: Yeah.

[00:47:32] Keith: so it kind of never went anywhere. The H element doesn't exist as we all know. H1 to H6 are the heading elements that exist today.

[00:47:41] Lola: Yeah.

[00:47:43] Keith: so I would bring that back. I, I want the H element. I don't want H6.

[00:47:49] Lola: You want the browser to figure it out. You don't wanna have to figure it out.

[00:47:52] Keith: Yes, exactly. and like as serendipity would have it, this is a problem that we [00:48:00] encounter at GitHub because we want accessible heading structures, but, we have a lot of user generated content. Right, right. Every comment, you can use markdown headings.

[00:48:12] Lola: Yeah.

[00:48:12] Keith: And, to have a proper flow for heading structure. You know, H1 will be the. The repository title, maybe H2 will be like the tab that you're on.

[00:48:23] Lola: Yeah.

[00:48:24] Keith: And so every comment should start at H3, but a lot of people will use the first level heading. and so we kind of want this feature, like we care about this, um Right.

[00:48:35] A lot. and so we've been trying to bring this back in a in a slightly different flavor, which is, rather than the section element you like specifically mark an element with a heading offset and you give it a number and then every H1 to H6 element will be offset by that amount.

[00:48:56] Lola: Right.

[00:48:56] Keith: If you've got a div with a heading offset of one every [00:49:00] H1 inside of that is gonna be an H2 and so on.

[00:49:02] Right?

[00:49:03] Lola: Right.

[00:49:04] Keith: so this is something that we're trying to work on is actually, in Chrome under experimental web platform features. So if you go to Chrome corner slash slash flags. Enable experimental web platform features, you can add a heading offset and you can see this work.

[00:49:19] Lola: Right.

[00:49:20] Keith: so we've got a prototype ready and my colleague, Clay on the accessibility team at GitHub has been working on this with me, and we, we've got a prototype ready and we're pretty, we're pretty happy with it so far.

[00:49:33] so yeah, like the feature that I want from the past is this, and I really think we might be, you know, onto something. I think we might be getting the H element back. We'll see. We'll see.

[00:49:44] Lola: We'll see. That's exciting.

[00:49:46] Keith: So I actually spoke about this heading stuff in more detail, on a, the Igalia Chats podcast. so if you're interested in that, I would recommend checking that out. And I guess there'll be like, show [00:50:00] notes. I'll drop a link or you can drop a link.

[00:50:02] Lola: Yeah, we'll, we'll drop a link in the, in the, description when I publish this. And the Igalia Chats is another really great technical podcast. Um. Eric and Brian from Igalia. great, great guys. Cool

[00:50:18] Keith: Legends. Yeah. Eric Meyer and Brian Cardell, at Igalia.

[00:50:22] Yeah, we, we, we spoke about this, the, the oldest feature, tackling the web's oldest problem, I think was the, the title of the podcast.

[00:50:32] Lola: Nice.

[00:50:34] Keith: what, what was the, the next question, sorry.

[00:50:36] Lola: One current feature that you would, that you wish never existed or that you would change?

[00:50:43] Keith: Yeah, so, I think, again, this is something that's in the works, not necessarily spearheaded by GitHub, but by Open UI which is form controls.[00:51:00]

[00:51:00] and the, the native appearance that form controls have, I think has been a very long standing problem to the web. Um. And I think maybe it made sense at the time, but I think design for the web was very new when the web started. Yeah. For obvious reasons. But like these days, most websites will def, will style their own form controls.

[00:51:30] Yeah. And because of the limitations around styling form controls, usually what that means is they end up reinventing them. And that's just hurtful for accessibility. That's hurtful for Yeah. Like bringing in JavaScript that you don't necessarily need, that the browsers all be doing. Yeah. So if I could rec on if web features, I think it would be just never having native widgets in the, in the browser.

[00:51:55] I think it would've been a nicer problem to try and style [00:52:00] these generic form controls to look like the native operating system. Yeah. Than trying to like undo that. Yeah. which is where we are today. but appearance base, this is gonna be, the new thing will do that. It will turn, if you add appearance base to a form control, it turns off all of the native styling and it just gives like divs and squares and stuff.

[00:52:25] But it still has all the accessibility, it still has all the functionality built in, so you're not gonna have to reinvent stuff. and

[00:52:32] Lola: this is something that's available behind any feature flags or anything at the moment in any browsers.

[00:52:37] Keith: Yeah. So Chrome's been experimenting with this. And again, if you go onto Chrome, Chrome slash slash flags and enable experimental web platform features, you can, it's not called base, I think it's called Base Select and it's just for select elements.

[00:52:53] Yeah, but you can try it out. I think there's a Chrome blog article, [00:53:00] which I can find about. Styling, like select elements, and they go into all the detail about it. but it's amazing, like you just add appearance based select, and then it's what you're expecting, right? You just get these, you get some default styles.

[00:53:17] So just adding that style, it doesn't zero everything out. It's not like a reset. you get like a black border around it. but you can do loads of stuff. You can do some really interesting stuff with it. Yeah. They've also extended the select element, so you can add images to options. you can like customize the selected content, all of this kind of stuff.

[00:53:38] It, it's really amazing. and the open UI work, working group, the CSS working group and the HTML working group meet every week and they're building upon this. So select is the first element because that's the one that everyone seems to customize.

[00:53:56] Lola: That's definitely the biggest bug bear. Yeah. Yeah.

[00:53:59] Keith: [00:54:00] but inputs, um.

[00:54:02] Like range, inputs, buttons, all of this kind of stuff. They're all gonna be added to this. Yeah. and they, you know, anyone who's worked with form controls knows that they're a pain. You, you can't target some pseudo elements in some browsers. Like they all have different pseudo elements. They all have different pseudo classes.

[00:54:21] All of that is gonna be standardized. It's a huge multi-year effort. But I think in a couple of years time, you know, I think that in the 2030s we'll have like, are you old enough, in the web to remember like cut cutting, like spreadsheets for border radius and stuff.

[00:54:40] Lola: I came into software engineering just as that was phasing out.

[00:54:44] Yeah. So when I did my bootcamp, we learned how to do that. Wow. But by the time I got my first job, I never have needed to do that.

[00:54:52] Keith: Yeah, yeah, yeah. So it was such a, sure. It never worked. It never worked properly. Like it would, it would fall apart really easily. [00:55:00]

[00:55:00] Lola: Yeah.

[00:55:00] Keith: And then, yeah, one day the css, CSS two, I guess it was came out or CSS three with border radius.

[00:55:07] Lola: Yeah.

[00:55:07] Keith: Everyone just was breathed the sigh of relief. Collective sigh of relief has to develop a world. I think the same's gonna be true. Like for, for phone controls, right? I think this is the new border radius. This is everyone, who's currently struggled with it and knows how much of a chore it is. we're gonna ha have another collective sire of relief.

[00:55:28] Yes. In the 2030s, like form controls are gonna be style bowl and it's gonna be magic. I can't wait.

[00:55:35] Lola: Then the newbies that come in are not going to even understand why it's so magical, why everyone's so, so excited about it.

[00:55:42] Keith: We won't understand the pain that we went through. Yeah.

[00:55:44] Lola: And that's good. That's good.

[00:55:46] That's what we want. Yeah. That's it. okay. Finally, an invented feature, real or absurd, you'd create if you could, and I'm excited about this and I don't wanna answer for you.

[00:55:59] Keith: Yeah. [00:56:00]

[00:56:00] Lola: But if you wanted to talk about Invoker commands, I would love to hear it. If it was something else, that's fine. Yeah. But if you wanted to tell us a bit about Invoker commands and the work you're doing on that, I would love to hear it.

[00:56:11] Keith: Absolutely. Yeah. yeah. So Invoker commands, is a feature that I kind of proposed. it all started like 2018. I was, I was working on dialogue elements, at GitHub, right. And the, you could close a dialogue in, in a bit of a weird way, you could put a form inside a dialogue. You set the method to dialogue.

[00:56:35] And then when you submit the form, it'll close the dialogue. But there was no way to open them, it without JavaScript.

[00:56:41] Lola: Yeah.

[00:56:42] Keith: So I just raised an issue on the, on the tracker and it sat around for a while. And then eventually this feature called Popovers Landed and popovers are kind of like dialogues, but they're not, they're subtly different in various ways, but they had this thing called popover target, and you put [00:57:00] that on a button and it makes the button open the popover.

[00:57:03] Lola: Yeah.

[00:57:03] Keith: and I saw that and I was like, we, we should just make that generic. We should have a way to make a button do a thing, where the browser does most of the work. Because if you've tried to do this, you know, there's various subtle things that can go wrong. Um. Like, even if you're using a framework, you know, you might be mapping it to a state change or something.

[00:57:31] Lola: Yeah.

[00:57:31] Keith: And there's all these different ways that that state can change from under you, and so you have to synchronize all of those. And so there can be a lot of bugs just in mapping those state changes, but also the accessibility's kind of difficult to get right.

[00:57:43] Lola: Yeah.

[00:57:43] Keith: it's, it's not, it's difficult to understand the nuance of accessibility if you're adding ARIA, like the complexity can go way up when you start adding ARIA properties.

[00:57:54] Yeah. because it, it can be very difficult to understand exactly what ARIA properties you should add. [00:58:00] And also they then contribute to this whole thing of like what state needs synchronizing in the ht Yeah. So the thing for us is like, well, what if we just had a attribute on a button that just did all of this for you?

[00:58:14] Lola: Yeah.

[00:58:14] Keith: So I drafted up this proposal for the open UI working group. Where instead of Popover target, we would have, at the time it was called Invoke Target. Now it's called Command for. And so you have button command for and then, an ID of the element that you want the button to control. And then you give it a command.

[00:58:33] And there's a list of like well-known commands and you can add custom commands. And the point of this is the well-known commands will just try and do as much for you as they can. And so if you wanna open,

[00:58:44] Lola: and this is without javaScript,

[00:58:45] Keith: entirely without JavaScripts, you can add JavaScript. Of course, it dispatches events in ways that you can hook into.

[00:58:52] But the idea is that you, you can take a snippet of HTML that just says button command [00:59:00] for the dialogue, and then command, show modal.

[00:59:05] Lola: Right?

[00:59:05] Keith: And when you click that button without any additional JavaScript, it'll open the dialogue. And that's it. I mean, like the, the simplicity is the feature, right?

[00:59:14] Yeah.

[00:59:14] Lola: Yeah.

[00:59:15] Keith: Um. But the thing I really like about it is that you can take like a slide, you know, from a presentation that just has this sort of HTML and you're not like a lighting all these details, you know, nothing is hidden. It's just, yeah. It's just the HTML You can take this and you can move it all the way to production.

[00:59:34] And if, if anyone has worked on, taking like snippets of code and trying to productionize them, trying to add all of the extra stuff before you know it, you know, like we've got these buttons that open these dialogues, in our code base and there are hundreds of lines of code because they deal with all these subtleties and they,

[00:59:53] Lola: yeah.

[00:59:53] Keith: You add one more feature and one more feature and before you know it, you've got this hundreds of lines of code. and [01:00:00] maybe the browser can just do that instead.

[01:00:01] Lola: Yeah.

[01:00:02] Keith: but yeah, we're excited because this was the start. Like we are calling this in Invokers V1 yeah. it's just show popover and show modal.

[01:00:13] And a couple of other commands that are, similar, but it's like, what can we do with this next? Like this is kind of an architecture for the interactive web.

[01:00:23] Lola: Yeah.

[01:00:23] Keith: so we are thinking like one of the latest things is, what about a button that copies stuff? Like if you've ever looked at a code snippet on a blog, there's usually like a copy button, right?

[01:00:37] Yeah. That just copies the code snippet and that requires JavaScript. Someone needs to wire it all up, and usually they're not that accessible because, it's often difficult to think about screen reader interactions about how would you announce that the copy button has done the thing

[01:00:53] Lola: has, has copied yeah.

[01:00:55] Keith: to a screen reader. You know, most of the time they'll just change, like developers will change the [01:01:00] icon to a tick or something. You also need to announce that it's copied. So we, so we are thinking, well, maybe this is another step that the browser can do. If the browser can give you a copy button and it does all the security and it does all of the accessibility for you.

[01:01:14] You just write command for the thing. I wanna copy command, copy, text, voila. Everything just works. And we kind of back to this world where HTML is the primary mechanism for driving UI rather than JavaScript.

[01:01:29] Lola: Yeah. And I'm glad you raised a point about the accessibility of these things and also the security of these things as well.

[01:01:36] I think something that, people outside of standards don't consider is even in creating the standard, we still have to think about how security is, how accessibility is, how interoperable it's going to be, just so that it works, you know? Yeah. And a lot of the time, that's what takes up. The time, you [01:02:00] know, when we say things take so long to get from like draft to recommended to like, yes, it is a standard.

[01:02:06] a lot of the time it's just making sure that people aren't further harmed or aren't disadvantaged because, you know, as you say, we wanna copy some text, you know?

[01:02:16] Keith: Yeah, yeah, yeah. These things need to, there, there's so much that goes into it. there's, there's obviously the, the, the technical architecture group that needs to think about the web as a whole, like holistically what the API looks like.

[01:02:33] Lola: Yeah.

[01:02:34] Keith: and so it needs to be consistent and there's, so there's that whole team that reviews it. There's, like you say, there's security, there's the whole accessibility, the ARIA working group work on. so yeah, there's a lot, there's a lot that goes into it and there's a lot of conversations, that end up happening.

[01:02:53] I would say, you know, 50% of the work, maybe even more is, is just kind of. Getting [01:03:00] buy in, collaborating across all of the different browser vendors, making sure we're all in agreement. Yeah. it's very different to, kind of internal design work, I guess, because if you're designing an API for, like, if you're a platform, if you're on a platform team designing an API for your colleagues

[01:03:19] Lola: Yeah.

[01:03:20] Keith: Generally you are just fairly insular, right? You're, you are working on the platform team, you're discussing with colleagues, but the web is kind of strange because there's so many stakeholders, right? Yeah. There's the browsers, there's developers, there's people who are concerned about security.

[01:03:34] Lola: Yeah.

[01:03:34] Keith: That when we were talking through, a lot of these, specifications, we think about like, well, what does it look like to look at a webpage on a, on a PlayStation or in a car?

[01:03:47] Mm. Yeah. Or like, on Apple Vision products or like, you know, how does eye tracking interact with this feature? How does a mouse, how does a keyboard, how does a game controller. How does a, what does it look like for a 10 foot interface, [01:04:00] like a tv?

[01:04:01] Lola: Yeah.

[01:04:01] Keith: So there's all these little considerations and everyone who has like, stakeholdership in that wants to make sure that it works well for them.

[01:04:10] Yeah. And so you're kind of having to work in this like consensus model where, you, you can go to each of those people and say, well, how do you want it to work? How can we make this work for you? And then like, the feature evolves over time because of that.

[01:04:24] Lola: Yeah. Yeah. And I'm on the technical architecture group for the next two years, so I am looking forward to seeing Invoker commands, be submitted as a design review if it hasn't already.

[01:04:36] and yeah. Yeah, it's exciting stuff. It's exciting stuff. Yeah. Cool. Well, thank you so much for joining me today, Keith. It's been lovely to speak to you. Before you go, I just wanna throw one more question at you. Okay. How do you feel almost two years later now that you've made. Over a hundred contributions to browsers, and I [01:05:00] think even inventing new things.

[01:05:01] How do you feel?

[01:05:03] Keith: I'm pumped. I'm super excited for the future. I, there's gonna be a lot more from me, with, working with the open UI working group, or community group. We are doing great stuff on the phone controls. I think I'm gonna be ramping up my involvement there. Yeah. I'm excited about new features.

[01:05:25] I'm, I've got a long list of things that I want to, add to the web and I just feel more empowered to do it. so yeah, I'm pretty sure there'll be another a hundred contributions soon.

[01:05:39] Lola: Nice. And where can people find you online?

[01:05:42] Keith: Oh, yeah, I'm around. I, I usually go by Keith Theus on all of the socials.

[01:05:48] K-E-I-T-H-A-M-U-S. Cool.

[01:05:52] Lola: that'll be linked in the description as well.

[01:05:54] Keith: Yeah. Awesome. Thank you. Yeah.

[01:05:56] Lola: Nice. And thank you for joining me today, Keith. Have a lovely [01:06:00] day.

[01:06:00] Keith: Thank you. The pleasures all mine.