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 Kilian on BlueSky or Mastodon

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

Episode Links

• Polypane

[00:00:11] Lola: Hi folks, it's Lola here and this is What the Spec. Now I know in the last episode I said that was going to be the episode before the penultimate episode. I think this was supposed to be the penultimate episode, but unfortunately I'm gonna have to wrap season one here with Kilian. This is another great episode, but after this, I won't be back for a while, now there might be a season two in 2026 if I have capacity and time, as some of you know, I run lola's lab by myself, so doing this and the other stuff I have going on can be a bit much. But I would like to do a season two, so if there's capacity, I will definitely prioritise [00:01:00] doing another season of What the Spec.

[00:01:02] I've really, really enjoyed this podcast and I just wanna say thank you to all the guests who've come on and spoken to me about all the amazing things they're doing in standards. I wanna thank the listeners and supporters for liking and sharing and contacting me on social media and LinkedIn in various places, thank you so much for your support. Okay, now just because I'm not doing What the Spec, I am still working on a bunch of stuff. I am still the co-chair of the technical architecture group at the W3C and I'm also the co-chair of the documentation group at the W3C.

[00:01:41] In addition to that, I am leading a project called Accessibility Compact Data, which will, there'll be a link for that in the show notes, and you can learn more about that. But it's basically about bringing accessibility interoperability data to developers where they are in places such as [00:02:00] MDN.

[00:02:00] And at the beginning of next year, I will be running a course for policy students and professionals who are interested in getting involved in standards. I think that's a big gap that we have in the W3C and web standards. We don't have enough policy representation and input, and this is something that the UK government has funded me to do, and it's also something that is on the priority list for the W3C.

[00:02:30] So I'm working on a bunch of stuff. Um, but it's all exciting and I am really happy to be able to work on this stuff. It has been made possible through various funds and grants, but also financial support from smaller organizations like Polypane and individuals who see the work I'm doing and recognize it's important.

[00:02:53] So thank you everybody. Thank you for being on this journey with me with What the Spec and [00:03:00] get ready for the last episode. I'll be talking with Kilian from Polypane and it's a good one.

[00:03:08] Lola: Welcome to What the Spec. Today I am joined with Kilian Valkhoff, who is the founder, creator extraordinaire behind Polypane Browser. Before we get like stuck into the nitty gritty of this conversation, it would be lovely to hear just a bit about you, your background, and your motivations behind

[00:03:30] starting Polypane.

[00:03:32] Kilian: Yeah, sure. So, I am Kilian, as you said. I'm from the Netherlands. I recently became 37 year years old two days ago.

[00:03:42] Lola: Happy birthday.

[00:03:43] Kilian: Thank you. Nothing has randomly started hurting yet, so it's going pretty well. I've been building websites for a very, very long time. I started a web agency when I was 16, grew that into 14 people [00:04:00] organization over the course of well over a decade. So I built a lot of websites like over 200 last I counted them over that time. And I have always been building like little tools to help me improve my workflow or just. Deal with some kind of annoyance. First that started as like small JQuery plugins or CSS frameworks.

[00:04:33] And then later on I upgraded to desktop applications to help me with random stuff. So one of the first I built. Is called trimmage, and it's still available on most Linux systems, and it's a GUI to minify images because there's a few command line tools for that, but they all require slightly different, equally arcane command line [00:05:00] arguments. So I, I built a GUI that you can just drag folders for images into, and it'll just minify all of them. And I've been using that at least once a week for the past, like 15 years since I built it. So that's that is still useful. And then eventually I also built like a really crappy app to to prevent me having to resize my browser all the time as I'm building for responsive design,

[00:05:33] Lola: right.

[00:05:35] Kilian: Because that was super annoying. And for a while you could get away with having a webpage with a bunch of iframes on it. But browsers change and browsers realized that it's probably a bad idea if you can just randomly embed any other websites into your own websites.

[00:05:55] Lola: Privacy and security concerns.

[00:05:58] Kilian: So there, there's a bit of an issue there. [00:06:00] So, that stopped working for a while. And then I came across Electron which lets you use web technologies to build desktop applications. So I tried it out and made a really crappy demo that was essentially like three iframes, side by side with the security turned off. And that worked really, really well. So I kept developing it and of course, nowadays everything's properly sandboxed and has been for years. Everything's isolated. Each website runs in its own process, complete, separate from all the others. So it's, it's no longer like a crappy demo, but it's a full, proper browser with all the bits you would expect from a modern browser.

[00:06:44] Lola: Lovely. I really love the journey you went on there. Just like prototyping things and being forced to in a way, when you realize that yeah, using iframes or like, inserting one website into another website, it's probably not the [00:07:00] best way to go about things. For those who are unfamiliar with Polypane, give us like a brief overview about what the browser does and who it's for.

[00:07:08] Kilian: Sure. Yeah. So, Polypane is essentially what if you built a browser, but it was only for web developers. If you're building a website, what are all the tools you could possibly need, including tools you don't realize yet that you need, and what if all of those are fully integrated into the browser.

[00:07:35] And that's what Polypane is. So it started out as a way to do responsive design in a more convenient way. But now you can do all sorts of emulation side by side. So in Polypane, you can see your webpage at multiple different view ports at the same time, those can be different sizes to emulate different devices. So one can be like a, a small mobile phone with touch emulation disabled [00:08:00] enabled. And then the other can be like a 4K screen, but it's in forced color mode.

[00:08:05] Lola: Yeah.

[00:08:06] Kilian: So it expanded from like responsive design to accessibility testing, to performance testing, to giving you insights into all the parts for your websites that aren't just the visual. 'Cause, that's what other browsers do, show you what your website looks like. But of course, that's not the only way that people consume your website or machines consume your website. And it's really hard to gain insight into those parts. So I really try to surface that as well with things like having layout outlines recently added way to inspect your forms, so you get a full, like, visual overview of all the properties of your form, all the elements in your forms. If you're doing anything wrong there I give you tips and hints on how to improve, like if a label's missing or if you have a typo in your [00:09:00] autocomplete attribute where it's, you didn't type postal codes, but post codes or whatever.

[00:09:07] And then of course, browsers don't recognize that so that's broken and you wanna fix that but it's also really easy to miss if you're just looking at like a wall of DOM code.

[00:09:18] Lola: Yeah.

[00:09:19] Kilian: So it's essentially everything that I can imagine and everything all my users can imagine that you would want in a browser or like a builder,

[00:09:29] Lola: Yeah.

[00:09:30] Kilian: While you are building your own websites regardless of the technologies you end up using.

[00:09:37] Lola: That's really cool. I came across Polypane on social media actually, because I'm quite connected to the accessibility space and the work that's happening in there, and I can't remember who now. So whoever I'm supposed to credit for this, I'm sorry. But somebody re shared your app specifically in the context of accessibility though. initially I didn't even know [00:10:00] you could do all this other stuff in terms of like, resizing the windows and, and having things side by side and all of that until I messed the app myself. But from the accessibility perspective, it was quite, I guess radical what you're presenting, where, it's not just in the dev tools, inspector things you have to switch on to see, it's there. Can you talk a bit more about why you decided to have this as a standalone thing instead of like a dev tools inspection? 'Cause I imagine you could do similar things with extensions.

[00:10:37] Kilian: Well, so they only go so far. Like the whole part of, or a significant goal of dev tools in other browsers is to make sure that they're pretty hard to get to.

[00:10:50] Browsers do a pretty good job of making sure that people don't accidentally end up in the dev tools. But that also means that in [00:11:00] other browsers, dev tools is boxed away. It's not allowed to be part of the rest of the browser,

[00:11:09] But you and I, as we're developing, we're using the entire browser.

[00:11:13] We want to look at our webpage from multiple different angles in multiple different ways, and we don't want that, or I don't want that weird separation between, there's the dev side on one part and the visual side on the other part.

[00:11:30] You're, working with both. So what if you could integrate that better? And that's because of the way other browsers are built. That's just not really a thing you can do. You can't drag the dev tools out into the broader browser because browsers don't give you the APIs for that.

[00:11:49] Lola: Yeah.

[00:11:50] Kilian: And then also there are things that regular browsers will just not allow you to do as easily as I can do in my own product. [00:12:00] So in Polypane, there's just a checkbox to turn on and off web security.

[00:12:04] Lola: Yeah.

[00:12:05] Kilian: Whereas if you wanna do that in Chrome, you have to close out Chrome and start Chrome with command line arguments, which is the right choice for Chrome,

[00:12:14] Lola: Yeah.

[00:12:15] Kilian: Because you definitely don't want to do that accidentally.

[00:12:19] Lola: Yeah.

[00:12:20] Kilian: But that does make it annoying for developers. So by building your my own browser, I can make those, make different choices and make different trade-offs between like non devs, which aren't my target audience versus devs.

[00:12:40] Lola: Yeah, that makes total sense. I think like. Through these conversations I've been having with other guests and just like in standards in general, the idea is that the expected use of a web browser is the average person. So much of our lives now are on the [00:13:00] web. Whether that's jobs, whether that's finding housing, whatever.

[00:13:03] So much of that happens on the web and we, we want to make sure that we are building one web, we're not building like silos. At the same time though, you raise a really good point, the people who build on the web and create for the web are in some cases limited because we are, when we build a browser, we are building for the most vulnerable person, right?

[00:13:28] The person who knows the least, whoever that is. But for the people who are a bit more adept, who can build on the web, who understand how browsers work, who understand how the web works, that can be limiting. And I guess then for you, has the target audience always been web developers because of your experience as a web developer?

[00:13:49] Or was it that you saw that you were tinkering and you realized that like this would be something good for web developers?

[00:13:57] Kilian: So the way I look at Polypane is that [00:14:00] it's a useful tool for everyone that needs to have an opinion on a given website.

[00:14:06] So primarily that's of course web developers. But it's also the QA people, because QA people have the same issues. Like they need to inspect the webpage. They need to interrogate a webpage from multiple different angles to determine if it's up to the quality standards that they have or that their organization has.

[00:14:29] Lola: Yeah.

[00:14:29] Kilian: And the other, it, it also extends the other direction. So, web designers are, for better or worse, usually tasked with checking if designs are implemented well. If, if the developer followed the spec that they created and again, that's not easy to do in a regular browser. And it is in Polypane.

[00:14:51] So in that sense, like there's a lot of tasks that are primarily tasks for web developers, [00:15:00] but that all these personas in the same team with the same goal of creating good websites also share for just like a very random example, but Polypane has really extensive screenshotting and screenshots editing functionality built in.

[00:15:18] So you can screenshot your webpage in like four different ways. You can create a video but you can then also within the app, instantly annotate that screenshot or annotate that video. So you can, if you have a screenshot with a bug, but it also has sensitive data, you can very quickly redact that screenshot.

[00:15:40] You can add a bunch of arrows and red lines. Write in the app, press copy to clipboards, paste it into slack, paste it into Jira and share that feedback out. And that's of course something that, product managers do all day.

[00:15:57] So they are, they also benefit [00:16:00] from from this functionality.

[00:16:01] Whereas a web dev would maybe use it to share screenshot with the designer, like, I implemented it this way for this reason. Are you okay with that? And then, everyone, QA would use the same functionality to report bugs to be picked up later.

[00:16:17] Lola: Yeah.

[00:16:17] Kilian: So it's, if I try to take more of a task based approach to what are the tasks you need to do to build quality or high quality websites,

[00:16:29] And provide the tools to do that as efficiently and as effectively as possible.

[00:16:37] Lola: yeah. Polypane is really, feature rich. There are so many features you can do. And I think definitely thinking of it from a task perspective of like, what do I need to do if I'm a QA engineer or if I'm an accessibility auditor or engineer, if I'm a web developer or engineer, like, think about that means that it ends up having a lot of features.

[00:16:59] And I was [00:17:00] wondering, and earlier you spoke about building using Electron. I was wondering if you could talk more about the tech stack. Typically browsers as we think of them have specific browser engines, whether that's WebKit, Chromium, Gecko, whatever. And, they fork that and build on top of that to make their own thing.

[00:17:21] But from my understanding, you haven't done that. You've gone a different route. So yeah. Can you talk more about the tech stack and your decision to go that different route as well

[00:17:29] Kilian: Yeah, sure. So the decision is really simple. I do know HTML, CSS and JavaScript really well, I don't know, C++ at all.

[00:17:40] Lola: Yeah.

[00:17:41] Kilian: So Electron lets me use the skillset I already have to to build this tool.

[00:17:48] Lola: Yeah.

[00:17:48] Kilian: At the same time, like, Electron is built on Chromium, so that means previous, so similar solutions like Node Web Kit [00:18:00] or Adobe Air, if we wanna, go back a very long time. They used like weird versions of rendering engines where you would still have to do a bunch of QA, where you would still need to check across different operating systems because the underlying rendering engine would be slightly different in annoying ways. Whereas with Electron, I just know that the Polypane running on everyone's device right now is Chromium 180. 38. So that's the current version, and that works the same everywhere because it's Chromium. So that's, that's very valuable I think, to developers. And it's also why I try to keep Polypane essentially up to date with the current version.

[00:18:49] Lola: Yeah.

[00:18:50] Kilian: So usually I either release a version of Polypane with on the same day that Chrome release is a new full version update [00:19:00] or in the week after it. So I try to keep up to date with that. So that's the, like why Electron and and what that brings me. It brings me like the most popular rendering engine that the most people use, that most developers use.

[00:19:15] And then that leaves the entire UI. 'cause Electron just gives you like a window running Chromium. It's white. You can add an H1 to it and say hello world. And the rest is up to you. So the entire UI in Polypane is built on React.

[00:19:37] Lola: Okay.

[00:19:37] Kilian: And it is, was initially built on React 0.13 because I've been working on Polypane for over a decade now. And I've just been, keeping that up to date with current versions of, of React. So it's it's a lot of different components which is of course like a major benefit of [00:20:00] react that you get very specific components doing very specific stuff in a very predictable ways which is for me it's ideal for a browser because so much of the UI is directive, like you set properties on on web pages that you show which are called Panes in Polypane, hence the name. So that makes it for a, makes for a very nice browser model. And of course other browsers have been secretly using React as well. So, validation for my tech choices from a decade ago.

[00:20:38] Lola: Yeah I think react and JavaScript frameworks in general are controversial to say the least. I think they, they have a purpose, they have a use case, right?

[00:20:48] Kilian: Yeah. And you, you also need to know like, when do you sidestep, sidestep a framework, nowadays a lot of that sidestepping happens with CSS

[00:20:59] '

[00:20:59] [00:21:00] Cause you can do so much more conditional logic in CSS though every now and then you run into issues,

[00:21:07] Lola: Yeah.

[00:21:08] Kilian: With CSS. So, like anecdotally recently, I had a sudden like three second slowdown in certain actions in my app.

[00:21:18] And I traced that down to one commit that only had CSS changes. It was like, no, no I, I checked this wrong. I need to do a another, git bisect and get the right commit because I, I obviously went left, where I should have went right somewhere in, in this process. This can't be right. And then I did it again and I ended up at the same commit and the same commit was just a single CSS line, but it was one with a has selector in it. And I comment out that has selector and the performance issue was gone, and I commented it back out and it came back. I was like, okay guess we have issues in [00:22:00] CSS now. So I, I had to solve that in a different way where first I was, I thought I was being super clever using like the fast has selector in CSS, that so much better than JavaScript. But, it's, it's always straight off and you need to measure and there's no rules that always apply, on the web.

[00:22:20] Lola: I don't think there's like a universal "this is how you do this thing", that there are multiple ways to do one thing, and it's about, as you said, weighing up the trade-offs and deciding what's appropriate for the situation. I, something that you mentioned here that I found really interesting about Polypane though, especially as somebody who is, moving more into browser engineering, contributing to servo and I don't know Rust.

[00:22:49] But I'm wading through it. But something I find interesting as someone in that position is that you are essentially relying on Chromium that comes packaged in the [00:23:00] Electron to handle the, what we traditionally think of as the browser, right? But you are focusing hyper focusing on the UI, which means you can use the languages and the technologies you are familiar with. Right a lot of the UI is HTML, CSS and JavaScript. But then I guess I, I have a question then for you when it comes to things like manipulating the UI and what I would expect to be interactions with the DOM or the CSS objects model or accessibility tree, are you mainly using JavaScript for those interactions? Or do you have to get a bit more low level and tinker with things that you may not be totally familiar with, like how do you manage that stuff?

[00:23:51] Kilian: It's a bit of both. So a lot of it is JavaScript, introspection and we, we can talk about that more later. But I [00:24:00] also use, so Electron comes with a lot of hooks. So the way to think about Electron is essentially it's Node and Chromium tied together.

[00:24:09] Lola: Okay.

[00:24:09] Kilian: And the glue between those is the Electron API but that also means that the Electron API provides a whole bunch of hooks into Chromium and, and into Node to get the information that you would want. So a large part of Electron is called IPC, Inter Process Communication that essentially lets you send messages from Node to Chromium or from one Chromium instance to another Chromium instance.

[00:24:39] So I use that extensively and that comes with its own like performance characteristics and trade offs, et cetera.

[00:24:45] Then I also make a lot of use of the Chrome DevTools Protocol, which is like. What I just explained as Electron being, but that's the glue between like dev tools and webpage instance.

[00:24:59] And [00:25:00] that's also what things like Playwright are using to provide functionality that they have. So those are the Chromium Devtools Protocol is a collection of APIs to do inspection of web contents.

[00:25:16] Lola: Yeah. Well, let's dive a bit deeper. You said we can talk about this later if we want to, but I think we should talk about it now. How, how, how deep do you have to go then, as somebody, who is mainly concerned about the UI?

[00:25:30] Are you relying on the Electron hooks alone? Because sometimes when I'm coding, I'm all of a sudden in a part of the code that i'm just like, how did I get here? How did I end up here? Everything feels like the wild west and unfamiliar and you are hacking through and you can't really see where you're going, and that's a lot easier to do when you're in a space where you at least understand the language or you at least know the direction.

[00:25:57] And it sounds like the Electron hooks or [00:26:00] using Electron hooks and, and these APIs the sitting in the glue basically allows you to do that in a way that's not so overwhelming, but I imagine that there are times when you may need to read some of this unfamiliar stuff, even

[00:26:14] if you're not going to contribute to it.

[00:26:16] Kilian: No. So I am very often reading through the implementation details of the Chromium DevTools protocol to figure out what's going on. So I am not editing that code. I am not editing the Electron source.

[00:26:30] Lola: Yeah.

[00:26:30] Kilian: But I do need to understand it and read it to, make sure that the things I want to do are possible in what ways they are possible.

[00:26:39] So if you look at the Chromium Dev Tools protocol there are a lot of things that make sense in the context of that protocol that feel very weird as a web developer.

[00:26:52] So, for example, if you have a reference to a DOM node in JavaScript, that's just a variable, [00:27:00] right, assign it to a variable. That's not how it works in the protocol, in the protocol you have to go from you can resolve that variable by calling some JavaScript through the Chrome Dev Tools protocol, then that returns on objects id, then you can get that object's ID and you can transform it. You can parse it to get to the backend node ID, which is like the the internal reference of a DOM node. And then that you need to resolve to a proper node ID, which is a different thing. And only when you have that you can do things like, gosh, does this element have any attributes that I care about? If you come from, through equals query select or div,

[00:27:47] Lola: yeah.

[00:27:48] Kilian: and you need to move to that five stage rockets that I just described, that it, that takes some getting used to.

[00:27:56] Lola: Yeah.

[00:27:57] Kilian: But then, eventually it does become [00:28:00] like just the way you do things.

[00:28:02] Lola: Yeah.

[00:28:02] Kilian: Then there again, there's, there's a whole bunch of trade-offs there in terms of, sometimes one way might be more performant, sometimes the other way might be more performant, but the less performant way gives you more of the data that you need. So I'm constantly juggling the ways to get information out of a webpage.

[00:28:24] Lola: You've been working on this for a decade plus at this point, so I imagine, the things that you may have found difficult in the early days are not the things you may find difficult now. But as you're talking, this really just like reminds me of translating a specification to a web feature, right? Like when you use the web feature, it's very easy, it's very straightforward. But where you are reading the spec and then writing that spec in the code, for every one [00:29:00] step there's like 15 steps, to do the thing. So even though you're not necessarily editing Chromium or Electron you're still navigating those spaces and having to adapt how you are thinking in those spaces versus when you are working solely with HTML, CSS, JavaScript. Which I think different skillset in and of itself.

[00:29:20] So I wanna switch gears a bit because you work primarily with allowing developers to test their websites, right? And as a web developer, there are things that you need to keep in mind when you are testing, for example, accessibility, for example, is this new CSS available everywhere? And if it's not, how do I polyfill or whatever.

[00:29:42] Do you feel like you have to keep up with evolving specifications and features and things like that? Or do you, because Electron is so linked with Chromium and you release based on the Chromium release cycle, do you rely on Chromium to handle that stuff and then whatever features you get are [00:30:00] the features you get?

[00:30:01] Kilian: A bit of both. So with Chromium implementing so much relatively early, I get the benefit of, getting implementations sometimes in tandem with the specification.

[00:30:18] And that also means that, for the stuff I built into Polypane, I don't need to have the spec in mind as much as the implementation. So anything in terms of the specifications I follow, but I don't dive deep into it until there is some implementation.

[00:30:38] Lola: Right.

[00:30:39] Kilian: it's at that point that I need to do something with it. Case in point two years ago CSS nesting landed since then it landed, it has landed like three more times in the same browsers with slightly different semantics,

[00:30:54] Lola: Yeah.

[00:30:54] Kilian: Is fine, but for every time I need to update [00:31:00] my implementation of the dev tools that I've built. So in Polypane, I have my own elements panel because that then allows you to inspect and edit it across multiple web contents at the same time, which is great because then you get instant feedback on how your styling affects all sizes, but it's also a lot of work to build. 'Cause like it's just me building what an entire team at Chrome has been building for the past two decades. And that means that things like, as soon as CSS nesting lands, I need to make sure that if you have nested CSS, did I show that properly in the overview of CSS styles being applied to your page. If @layer lands and landing in my context means that it becomes available in Chromium, whether or not that's enabled is the second question but it's like it's in the code base

[00:31:59] Lola: It's something [00:32:00] you can do

[00:32:00] Kilian: and it's, and that means that I can then enable it and start implementing support for it.

[00:32:06] And that essentially means like having to completely understand the specification in order to make sure that I display things in a way that's correct. That if you have CSS nesting that I resolve the right specificity for each CSS property. And that's also where quite often, like, one thing that the specs never really take into account is the introspection use case, the use case of I am a developer and I need to get information on, for example, this CSS rule. CSS rule is an interface that exists, but it's not built for introspection.

[00:32:50] And that means, for example, if you have a given CSS rule. That CSS rule on its own doesn't tell you if it applies to an elements. That CSS rule on [00:33:00] its own doesn't tell you if it only applies in a certain media condition because that happens elsewhere in your style sheet.

[00:33:08] So what I have to do is I have to build my own resolver to figure out like, what are all the different conditions for any given CSS rule on your website.

[00:33:21] Lola: Yeah.

[00:33:21] Kilian: And then when, like a new concept lands, like nesting or like layer or like scope I need to reverse engineer that entire logic as it's specced to make that I follow those steps to the letter to make sure that that I display the styles and I apply the styles in the way as that it's intended.

[00:33:46] Lola: What I expected to a certain extent. I guess like you're also having to keep up with things like WCAG, the accessibility, I forget what WCAG actually stands for,

[00:33:59] Kilian: Web [00:34:00] Content Accessibility Guidelines.

[00:34:02] Lola: Yes, the  Web Content Accessibility Guidelines and changes to that to be fair changes to that are much rarer.

[00:34:08] Kilian: I think it's changed significantly once in the past decade. The most pertinent change there was, okay, we don't really care if your HTML validates anymore. So that was a very easy change for me.

[00:34:23] Lola: Yeah. And I think like they're working on a another iteration now, but that's been, I think, a couple years in the making already. So, that's got a slower cycle, definitely.

[00:34:35] Kilian: In terms of that, so while WCAG itself doesn't change a lot. Underlying logic does, so for example accessible name generation, which in WCAG is just taken as a given, like the thing should have an accessible name. Well, what's an accessible name? Well, here's our 12 step resolve for HTML that determines the accessible name of an element. [00:35:00]

[00:35:01] Lola: Yeah.

[00:35:01] Kilian: That does, it doesn't change often, but it's also, it's very dependent on structure, on references, on, on pretty complex logic. Like, for example the accessible name generation takes circular logic into account

[00:35:19] Lola: Yeah.

[00:35:19] Kilian: and then it can, resolve differently.

[00:35:23] Lola: Yeah.

[00:35:25] Kilian: So I've had to rebuild that as well to make sure that if I generate accessible names to show a developer that they're the same as what a screen reader would generate.

[00:35:39] Lola: Yeah I think accessible name is such a good example. I have been writing web platform tests around accessible name and there's just things you may not consider as a web developer or like you may assume as a web developer when it comes to accessible name and being unaware of the instances where [00:36:00] ARIA labeled-by is overridden by something else or ignored completely, by something else, or vice versa, I actually think that's a really good example of where WCAG says the general thing of like, yeah, it should have an accessible name, but actually determining what that accessible name is and should be presented to the user is something else.

[00:36:23] Kilian: Yeah. Yeah. So what I try to do in Polypane is I do try to be like a little opinionated about stuff

[00:36:31] Starting from things like WCAG will tell you like, an image should have an alt attribute if it's content. But that's not actually what it says because an image or if it's if it's a presentational image, it should have an empty alt attribute. But you can also just leave the alt attribute out of it and give a role of presentational. You can also add inert to it. You can also do an aria hidden. And all of those are [00:37:00] like valid code,

[00:37:02] Lola: Yeah.

[00:37:04] Kilian: It's the alt attributes that you really want to set because that's the explicit action where you as the developer of this webpage say, this is a content image, or this is a presentational image. So what a lot of accessibility tooling does is it gives you that list of options, like, you should either add an alt attribute or a role of presentational or this or that. And if you are a starting web developer, you look at that list and you go, what?

[00:37:37] Lola: Yeah.

[00:37:39] Kilian: and then you ask a person and then the answer is, just add an empty out attribute if it's presentational. Like, and then why not just say that? So whenever there's something like that I ask a bunch of people like what should it just say? Like, what's the action, the ideal action to take? What's the, the right solution rather than the [00:38:00] possible solutions and I, I've tried to present that in, in the interface to make sure that you know what happens, or what I've seen happen in my career is that people get confronted with, you need to pick one of five options as a web developer. And then they go, I'm not gonna pick any I'm just gonna go and do something else right now because, my project manager isn't going to come back with a ticket that I haven't made this choice.

[00:38:31] Lola: Right,

[00:38:31] Kilian: it, it doesn't affect me and it affects the quality of real webpage. And if the tool just sat at an alt attribute, do they can go, yeah, sure, similarly move on, but now they've moved on done the right thing. So I, I try to make sure that doing the right thing is as easy as possible, and if that sometimes means like being opinionated or not giving you like the universe of possibilities, [00:39:00] like if you wanna know that, you can go search for it but most developers they don't for better or worse. And we still want them to make really good websites as well, because that benefits all of us because as you said at the start, we all need to find housing, we all need to interact with government websites, we all need to use the web. So the easier that gets to, to build, the better it is for all of us.

[00:39:27] Lola: Yeah, I definitely agree with that. You mentioned there about asking people what the best flow should be in this particular case. As an independent person working on this, do you have a kind of like group that you speak to or like a few people that you speak to? Or do you allow the subscribers for the tool to help make these kinds of decisions?

[00:39:54] Kilian: A bit of both. Again like there are some people that you know, that I know [00:40:00] I can ask. So I , gladly make use of their knowledge in this area.

[00:40:05] Lola: Yeah.

[00:40:05] Kilian: But then one of the benefits of building tooling for developers is that developers are pretty good at writing or thinking in terms of requirements. So they're also pretty good at telling me what they need. And I don't have a set framework of receiving feedback, 'cause I think that should be my problem and not like my subscribers or my user's problem. So whether they sent me a DM or they post in the Polypane Slack or they send me an email or doesn't really matter how it comes to me, but if they have feedback, they can just send it any way they wish.

[00:40:49] And then I'll collate that on my side and that means that I also have like a pretty good overview of where, of like the patterns that emerge and [00:41:00] what people need in that regard. I try to take feedback from everywhere.

[00:41:07] Lola: Historically speaking browsers are very difficult to fund and I think both of us have touched on the fact that you have subscribers, how are you funding your work on Polypane? Or has that changed over the years? Or has it been quite consistent?

[00:41:24] Kilian: No. So I launched Polypane as a product in 2019. And then right from the start I launched it as a subscription.

[00:41:33] So you pay a monthly or a yearly fee to use Polypane. And that's how I fund continued development on Polypane. It being a subscription for me is a direct result of it being a browser, and having a subscription aligns my and the subscriber's needs in that regard, because if I don't keep up to date with Chromium, that's bad for users.[00:42:00]

[00:42:00] Lola: Yeah.

[00:42:00] Kilian: If I need to spend a lot of time figuring out for each feature, for example, like am I going to put that in this version or am I gonna push it out so that people upgrade or whatever? That's not a choice I want to be making. I just wanna, as soon as something is done, I want everyone to use it. And then as soon as there's a Chromium update and updating, that does cost me a lot of work, as we've touched on, I do need to implement CSS nesting, I do need to implement scoping, I will need to implement the inline if clause relatively soon. So there's continued upkeep required to make sure that this remains useful for everyone and this aligns that very well, I think.

[00:42:49] Lola: And have you found it difficult to find paying subscribers?

[00:42:56] Kilian: So you can ask anyone selling to developers and they'll tell [00:43:00] you that it's like running a business on hard mode. The classic example is Dropbox, when Dropbox launched like the top comments on Hacker News was, why would anyone pay for this? You can just boot up to Linux machines and run this sync command line arguments, and that also works. I'm like, yeah, like you and three other people do that.

[00:43:28] Lola: Yeah.

[00:43:28] Kilian: So, for Polypane that the argument usually is like, I can just resize my browser. Like, yeah, you can, but that's really dumb work, do you really to jiggle your browser around for a living or, do you want to build quality stuff? But then, you also have to accept that as a business there's just certain people that are never going to be a customer, and those are the people that say, but I can just open three browser windows. Like, yeah, you can, and if that's how you wish to spend your time, I'm not gonna be able to convince you otherwise.

[00:43:59] [00:44:00] There's other people that are ideologically opposed to Chromium, like, yeah, then I'm not the product for you. Like, we can be friends, this isn't gonna work. So, yeah, that's just something you need to accept. And it's just like in, in any other business, there's just people that you think would be better off with your product because, honestly, that's why I'm building it, I think, if everyone used it, the word would be better. But yeah, you can't reach everyone and you have to accept that. I reach enough people that I can do this full time and serve them really well, I think.

[00:44:38] Lola: Cool. And we'll just end this section on this question. I was wondering, has there been any user feedback that has or use cases that have surprised you

[00:44:51] Kilian: That's a good question. Like certainly in the beginning, feedback I [00:45:00] really, I got quite often was like, oh, so Polypane does a lot of accessibility, why? What's wrong with you? And like nothing. Like, to me that's, it's, and it, it took me a while to realize what they were actually asking, which is why do you care?

[00:45:22] Lola: Like what what disability do you have that makes you care

[00:45:26] Kilian: Yeah.

[00:45:27] And the answer is I just think that, I want to build the best websites possible.

[00:45:35] Lola: Yeah.

[00:45:36] Kilian: You can't do that if you don't take your site structure into account, if you don't take your user into account. You can't build a good website that no one can use, by definition, that's not a good website.

[00:45:49] Lola: yeah. Yeah.

[00:45:49] Kilian: So all of that, it to me like very naturally flows from, I just want to do a good job.

[00:45:57] Doing a good job means doing all these things [00:46:00] and all these things happens to include accessibility as well.

[00:46:03] Lola: Yeah.

[00:46:04] Kilian: Just like, writing well means you also need to do spelling. Like, yeah, why do you care about spelling?

[00:46:13] Do you have dyslexia? No, I, I just wanna write. Well, and it's the same with with websites. So that was really surprising. But I think like slowly over the years, that has come around a lot where, that's more a given. You can see it like across the industry where, accessibility is becoming more of a, a sales point. Including like the bad side with accessibility overlays, et cetera. That is also a sign that people are starting to recognize, like, doing accessibility well means better outcomes for my business,

[00:46:56] Lola: Yeah.

[00:46:56] Kilian: Which is, the goal of anyone using an accessibility [00:47:00] overlay. Them not realizing that, the tool they use doesn't support the outcome is a second but it does mean that, people are starting to recognize this and I think that's by and large, like a better argument than you'll be sued by

[00:47:17] Lola: Yeah.

[00:47:18] Kilian: the EU or the ADA or whatever. And then, parts of that argument is, this is your job you want to do the best job you can, I think

[00:47:33] Lola: Yeah.

[00:47:33] Kilian: It's your, it's the thing you do all day so, you might as well do a good job.

[00:47:39] Lola: Yeah, exactly.

[00:47:41] Kilian: So that, yeah, so I, I think that's been like the most surprising thing, but that's, that's turns around over the years and I'm very happy about that.

[00:47:51] Lola: Me too. Thank you so much, Kilian. We are gonna take a short break and we will be back after this break with Patch [00:48:00] Notes from the Future. Okay.

[00:48:03] I hope you've been enjoying this episode so far. Just to let you know, you can leave a review for this episode on your favorite podcasting platform, and please don't forget to share and like across social networks and tell people. Tell a friend to tell a friend. Now back to the episode.

[00:48:23] Okay, welcome back from the break. Now we're gonna go into the game Patch Notes from the Future. So Kilian, how this game works is I am going to ask you three questions and you can give me your answers. They can be real absurd, passionate, indifferent, it is totally up to you how this goes. So the first question is, what is one browser feature or web API that you would bring back from the past if you could?

[00:48:58] Kilian: Right, so it's [00:49:00] more of a set of features that I would like to bring back. Like back in the early 2000s, we all didn't really care about privacy or user data, et cetera, that much. And because of that tons of websites offered all these embedding features. Like nowadays, people still embed YouTube videos into other websites, but back then, like every, like social sites had their own embeds, like famously the like button.

[00:49:37] But all those things have much more access, so it was also really easy to like, get functionality from various different places, like even guest books and things like that without having to do a whole bunch of like either implementation or setting up [00:50:00] various like HTTP headers to make sure that, embeds are accepted but they're still secure and they're only limited to these domains, et cetera, et cetera. And while what we have now is better for users like, just that, we all didn't really care about privacy, didn't mean that it wasn't important. It was, we, we just didn't know better and the web was still experimenting with a ton of stuff, but I do feel we also lost something there.

[00:50:29] Lola: I can definitely see that. I think that there is a kind of like modular nature to the early web or earlier web. I would say maybe not the earliest but there's like a modularity to it, right? You could pick bits and pieces from different places and clobber it all together and create a new thing

[00:50:47] Kilian: Like the of the Web 2.0 era.

[00:50:50] Lola: Yeah. Yeah. And there's a whimsy to that. There's a kind of like, a bit of an artsy kind of vibe to that. But there's also functionality, [00:51:00] right? Like, yeah, I don't want to have to write a guest book

[00:51:04] Kilian: Exactly.

[00:51:05] Lola: if I don't need to have to write a guest book if someone else has done it and I can use their thing.

[00:51:10] Unfortunately, people do nefarious things. You give people, a centimeter, they take a So, I definitely understand why we have the privacy and security things that we have now, but I do I see why you miss that. I do. Cool. So the second question is, what is one current feature that you wish never existed or that you would change?

[00:51:33] Kilian: Popups. So the, there's two reasons for this. One, there's never really a good reason to do a pop-up, I think, especially nowadays where anything you might be going, "I could use a pop-up for this", you would be better off using a dialogue. So there, there's no use for it anymore. And at the same time, like a, as a browser or as a browser implementer, popups [00:52:00] are terrible because you need to suddenly manage another window. But that popup also has a whole bunch of like secret browser things wired into it,

[00:52:12] Lola: Interesting.

[00:52:12] Kilian: some of which is user exposed. So if you open a popup, then the window dot opener property is a reference to the page that open the popup and the browser needs to manage that.

[00:52:28] Lola: Yeah.

[00:52:28] Kilian: And make sure that, if you set no opener, then that doesn't happen.

[00:52:33] But if it does happen there, you as a browser need to set up all this communication because you can actually, from the popup, do stuff to the webpage, which at a certain time probably was useful, barring the fact that popups were never really a good thing. And you can see from like the evolution of popups that they used to be like frameless windows and then they got a little frame so you could at [00:53:00] least close them.

[00:53:01] And then they were like, okay, but now you have a popup with web in it, but you don't actually know where those web contents are related, and they could be on the nefarious-website.com, that's bad. So, let's also cram an address bar into that. So it's just, it got worse and worse in terms of user experience, it never was good. Let's just get rid of it.

[00:53:23] Lola: Yeah, that makes total sense to me. I can see that there's work happening in standards around like popovers and dialogue. A lot of stuff happening in Open UI that I think is related, but I can understand why the added complexity of this stuff is becoming burdensome, shall we say? All right, so the third question is, what's an invented feature, real or absurd, that you would create if you could?

[00:53:49] Kilian: Yeah, so I really need more introspection features in the CSS Object Model. The specific thing that would really help me out is [00:54:00] something that will let me match a given CSS rule as a type of object in the browser to a given element. So browsers have a CSS Object Model, which is essentially all your CSS rules with their properties, like their selector, their CSS properties the layer, media, text, et cetera.

[00:54:25] Lola: Yeah.

[00:54:26] Kilian: And it used to be like a long time ago that you could just do elements dot matches, and then add the selector text there and it would tell you if this selector matched this elements. And then if a CSS rule had the same selector, that CSS rule is applied to the elements. So far, so good. Now we have media queries, we have container queries, we have scoping, we have layer, we have nesting. And all of that means that just the selector isn't [00:55:00] enough to match given element. So what I need to do is I need to go over the entire CSS tree, like collecting things along the way, like media text and container queries and scoping. And then I need to not only check the elements because the element is just the element, but the element might be in a container. So I need to find containers to check container text against. And then it might be scoped so I need to go back to the DOM to find if this element is in scope, but a scope might also be anonymous, so then I need to go into the DOM and see if it's in a style element and then go to the parent's element of that style element and then back to the elements that might be inside the, you can see where that's going, right? Whereas if you look at what a browser does, it already has this information.

[00:55:54] It knows for every CSS rule that it has in in [00:56:00] memory, it knows whether or not it applies to an element. So we already have like element dot matches, we have match media. We should be getting match container, 'cause someone went, we have match media, why don't we have match container? And standards people went, yeah, that makes sense. We don't have match CSS rule and a reason for that is that like introspection or developer focused features aren't consideration for most of the specification work. Which, I feel strongly about and I think that's a real shame. Because it makes a lot of things much harder including things that we all haven't come up with yet, because the functionality just isn't there to come up with new, more interesting ideas.

[00:56:50] Lola: Yeah, I think like there's an argument to be had about if we are making it easier for developers to do [00:57:00] certain things, if that would be like a net benefit on the user.

[00:57:04] If it's, what is the net benefit on the user if you are able to find match elements for certain rule sets, like does it mean that you'll be able to better serve your users? Does it mean that the potential website could be faster or not require as much bandwidth? I don't know. But I think these are things that are considered but also standards, every group is different.

[00:57:32] And I know the CSS working group is very is one of the bigger working groups and because it's CSS, what they produce is, more visible and like more out there in the world compared to something like Web RTC or like Web AppSec or, one of the other groups.

[00:57:51] But yeah that's a cool idea, being able to match elements based on their rule set. 'cause initially I was thinking like, what about, get by ID or get by class? [00:58:00] But that's not the same thing because then, as you said, you've got like the container you've got layers, you've got media queries, like scopes.

[00:58:09] Things only happening in certain context that you set. Cool. Well thank you so much for being on the show Kilian. It was lovely to speak to you. It was lovely to have you. And thank you for giving me your time. That has been this episode of What The Spec.

[00:58:25] Thank you for listening. Bye.