Brian Kardell: All right. So I'm Brian Kardell, developer advocate at Igalia. Eric Meyer, who's usually here also, is on vacation, hope he's enjoying that. But today we'll be talking about two features that are suddenly shipping in stable browsers that, well, I'm very excited about, :focus-visible and inert. And I have not one, but two guests that I'm really excited about. So I had a fortunate inside track on both of these because I contributed to them with two of my friends who I think did most of the work, who were at Google at the time, Alice Boxhall and Rob Dodson. Do you want to quickly introduce yourselves?
Rob Dodson: Sure. Hey, I'm Rob. I used to work at Google, I was a developer advocate on the Chrome team.
Alice Boxhall: Yeah. I'm Alice Boxhall, I used to work at Google on the Chrome team. I was influencing features in Blink, and working on web platform stuff.
Brian Kardell: Yeah. So the funny thing is that I was very excited about the fact that they're shipping now, and I thought, 'Oh, it would be great if the three of us got together to talk on the podcast.' Well, first, should we start by saying what they are, how about that? Who wants to explain?
Rob Dodson: Okay. All right, we'll start with :focus-visible because that's the first one on the show notes. So :focus-visible is a CSS pseudo class, and it matches when the browser would itself have drawn a focus indicator and around that particular element. The reason why this is interesting is in the past this behavior was inconsistent between browsers, and even if you were on a browser and you were using something like the :focus CSS pseudo class, its behavior would be different from the browser's underlying behavior that it would use for particular elements, which caused lots and lots of confusion. So :focus-visible, hopefully, brings these things much more in line, makes them much more consistent and predictable for developers.The other one is inert, and inert is an HTML attribute that you can put on, I guess, any element, but primarily interesting for interactive elements. And what inert will do is it will make that element no longer focusable, and it will remove that element and all of its descendants from the accessibility tree. And this is really helpful if you have something, a good example is you take some big interactive and maybe you animate it off screen so it's not visible anymore. That doesn't mean that it's no longer interactive, and so it's very easy to create these situations where you have some big menu or something that, you've moved it off screen, but someone using a switch device or screen reader could maybe still inadvertently access that. And that's not really an experience that the developer is expecting, but that's one that they have created by accident, and so inert lets you, very quickly and efficiently, remove those things so that users don't end up in these unexpected states. How'd I do?
Brian Kardell: Yeah, I think good description.
Alice Boxhall: Magnificent.
Brian Kardell: Yeah. So both of these things are shipping, and I thought, 'Oh, it would be so fun to have an excuse to have Alice an Rob on, and hang out with them, and talk about this, and celebrate together this moment because it has been a big effort.' So congratulations, first of all.
Rob Dodson: Yay. Yeah, I don't want to mess up the podcast, but if I could, I'd shoot some confetti right now because I think you have it here in the notes, Brian, it was a seven-year journey or something that, just a ton of time.
Brian Kardell: Yeah. So I was just going to say that the first thing when I sent the invite, I was like, 'Wow, how did this start? I don't remember.' And I went back and began looking, and I found that it's taken seven years and that's an interesting thing to talk about because there are certainly bigger features than this, and it still took seven years. I think it would be interesting to talk about the history of that, and the challenges and just how it went. I don't know where it would even make sense to start. Does anybody have a... I don't remember which one was first, do you?
Alice Boxhall: I think for :focus-visible, might have been first, but I do have the sense that they were around the similar time.
Brian Kardell: Yeah, they were very close I remember, and I think, also, this is how I met both of you. I know I followed both of you online, but I'm pretty sure this might be how we got to talking about lots of deep stuff. That might be another interesting topic, is people might think, 'Oh, you worked on two features for seven years?' No, there's a whole bunch of things, and some of those have shipped, and some of them have not shipped, but some of them are still in the making.
Rob Dodson: I think one of the interesting things about this process that you were alluding to, Brian, is how, when you start working on these things, it leads in these different directions. You start thinking up new standards that could be added, but it's only once you're in the space, you're really deep in the subject matter, that suddenly the inspiration strikes, and you're like, 'It would be also really cool if we did this.' Or you're realizing you're putting too much into one standard, and you're realize, 'You know what? I think what we actually need is to break this up into some smaller pieces that could do these different things.' So there's one example that comes to mind with :focus-visible that we can talk about a little bit later. But it's just a very interesting process how, like you're saying, you start pulling this thread and it takes seven years, but as that's happening, also, you start exploring all these different other avenues while you're still trying to keep this one track going to get it to the finish line.
Brian Kardell: Yeah and it changed along the way. I'm not sure, I think it might actually have been my fault that it changed along the way because we began talking about, at least, :focus-visible was the first one that I think was shared publicly. And we began trying to dissect the problem and some of that started on Twitter, Alice found some tweets that she put in the show notes.
Alice Boxhall: Yeah. I was trying to do the archeology there to try and remember because I distinctly remembered starting a conversation with you on Twitter about what Marcy Sutton at the time, had referred to as button focus hell. So you had asked, 'When would you not want to see a focusring?' I responded something along the lines of, 'Well you're on a mobile device, you've clicked a button then this weird ring shows up. Tells you nothing, it gives you no useful information. It's just this weird thing that looks a bug.' So I think that was what sparked that discussion.
Brian Kardell: Yeah and then we got really into it. We had a lot of discussions and I was saying... Well I know for me, the reason I ask is because I wasn't thinking about mobile at all, I was thinking about my computer. And I'm a mixed mode user, I use my mouse and I use the tab key and sometimes I'm like, 'Where is focus? I don't know.' So I frequently really appreciate them and when they just disappear for some reason then I can't understand it, I find it a little bit confusing. But that led to this whole thing that led to Alice explaining things to me that I really never even noticed existed, they were really subtle things. Like Alice was saying, if you push a button, that feels wrong and it's not new that browsers didn't do that.And then that also got into this discussion about, 'Well, but that's what focus matches and it isn't even consistent.' So I think we spent a long time just thinking about the problem, and describing the problem and trying to find where there was some agreement. And then we wrote an article about it that was published in O'Reilly, where we had proposed actually a media query, basically, called input modality, that would let you say, 'The user is using it in this modality.' And the modality could switch and you could change which style, which things were being applied. I think that wrong term was my fault.
Rob Dodson: Wait, this is maybe a good question because this is a question I always had, and maybe this was explained to me at some point and it just lost in my mind. So it's talking about the media query, and in some ways the media query is very easy to interpret it's like, 'If modality is mobile then do this with focus, or if modality is VR do this, or if it's desktop do this.' And y'all mentioned, at one point that it was discussed and people did not like that idea, but do you remember why they didn't like it?
Brian Kardell: Yeah, it's interesting. So shortly after we wrote that article... I don't know, Alice, do you recall how it happened? If you took it internally to somebody or they just picked up on the fact that we were talking about it?
Alice Boxhall: I no longer remember, but I assume that it was something like that, that I went and chatted with some folks on the Blink team to be like, 'Hey, what do you think about this?' And you made a note that you recall, that it was a performance issue.
Brian Kardell: Yeah, I recall that suddenly the Blink team was asking if they could have a meeting with me, which had never happened to me before and I was like, 'Okay.' And they were like, 'We really like this idea that you and Alice came up with.' But the thing is, actually, every time a media query happens, it injects a whole new style sheet or it removes a whole new style sheet and that means you have to recalculate everything. Whereas, with the pseudo class, we just flip a bit and it's predictable, it's a very linear path to resolve what matches that, we know exactly what it affects. So they said it was considerably more performant to not use a media query, they're worried that modality... Somebody could, if they're a mixed user like me, they might switch modality, they might start using the keyboard.
Alice Boxhall: Yeah. So I wanted to clarify a point about the question Rob asked, which also brings me back to something that I was meaning to say in my explanation earlier, which is that the modality was not, what type of device is the user using? The modality is, how is the user currently using their input device. So it was less, 'Are they permanently on a phone? Are they permanently on VR? Are they permanently on a desktop?' Than, 'Are they currently using a pointer mode? Or are they currently using a...' I think that the term we tried, we tried to come up with a few terms, I think the term we came up with was a sequential focus mode, which is the mode where, typically, it'll be a keyboard. It could also be a switch device but the idea being that you are moving the page focus sequentially through the focusable items, and you want to know which focusable item currently has that focus. The other point that I wanted to make is that the example that I gave on Twitter, I'm not even sure whether that was ever accurate, but I'm pretty sure it's not now. I don't think that we show focusrings on mobile, but I haven't actually touched that this is just a vague memory.
Rob Dodson: I mean, this is totally worth discussing, I think Android used to, and it may have been if you had modified the default appearance of it, but I think it would show an orange ring. I'm pretty sure it did that because I have this vague recollection of we had a dropdown menu or something and an old polymer website that did it on Android.
Alice Boxhall: Right, so the modifying the appearance thing, that is when you lose that OS default, which you were talking about in your initial description, Rob.
Rob Dodson: Yeah. I mean, I don't know if people want to go this deep, but it might be helpful for anyone listening who isn't really steeped in focus to understand the rules of focus, which we could talk about a little bit, how it's roughly supposed to work, and then why it was really inconsistent because otherwise it maybe doesn't make much sense why we invested so much time in :focus-visible.
Brian Kardell: Yeah. Well, I can talk about the things in the article, and we can link to the article, but there's some examples that are just very clear that I think Alice just nailed once she described them. So on a mobile device, if you touch a form field for your password, you want to be really sure where that password is going. It's very critical that you know where the virtual keyboard is going to send your keys, you don't want them accidentally sending them to the chat or something. So you show a focusring on those, but all the way back to, I think IE4, there had been discussions about bug reports. People click on a button and it gets a focusring and people are like, 'That feels wrong. What is this ring?' Because they were primarily mouse users, and they didn't get focusrings on lots of other things. And that's actually the way that the focus pseudo class worked too. And so the net result of this is that browsers had certain kinds of rules for when you would show the focusring. And it's more subtle than that, which is one of those places where we spiraled off briefly, which is the focus navigation starting point.
Rob Dodson: Well, just to jump on that really quick, it was even inconsistent browser to browser. So as an example, Chrome, if you had not modified the default appearance of a button when you clicked on it with a mouse, so if you literally just write button in HTML and you click on it with a mouse, I don't think this is the behavior today, but it was a few years ago, you click on it with a mouse, default button, it does not show a focusring. If you do anything to change the appearance of that button, like you change its background color and you click on it with a mouse, it does show a focusring, but that behavior was specific to Chrome. And if you go to Safari, you click on a button, it doesn't really matter what you've done to the button, it just doesn't focus the button at all. So in Chrome, it actually focuses the button but there's this underlying magic that it's doing to be like, 'Should I draw a ring or should I not draw a ring?' And Safari, it's just like, 'I'm just not even going to focus this element.' Which means it's firing different events as well, like on Chrome is going to fire a focus event, in Safari I believe it doesn't. And I think, I can't remember which of the two behaviors Firefox had, but you've got these layers of just weirdness to this thing.
Brian Kardell: And they weren't consistent and there was no way to say, 'That thing that the browser does, that's what I want to do.' There was literally no way to do that and so there was this underlying magic in the browser that was... Even if you can't be 100% consistent somehow because of operating system, different platform weirdness, at least I want this to be very predictable. And what we found, we looked through a bunch of things, we talked to different people and we found that people would end up disabling focusrings or focus indicators because they wanted to style them because you have, say a blue background and the default ring is blue, and you're like, 'That doesn't work. I need to make this white.' If you style it, if you touch it at all, suddenly everything would start working weird and very inconsistently across browsers, and users would file a lot of bugs.
Rob Dodson: That was the other funny thing. Yeah, you write a focus style and now it's forcing it to just always be on all the time. You've escaped out of the browsers nice subtle behavior to having it show up way more than you were expecting. To your point, people would do that and be like, 'That's not what I wanted. Let's just get rid of this thing.' Ironically, so for anyone listening, as we were starting this podcast, we realized literally the site that we were using to record this podcast does not have focus dates on any of the buttons because I was trying to find a shortcut for the mute button and Alice was like, 'Oh, if you pressed space bar, it works.' And I'm like, 'What?' And then realized there's no focus states, if you're just having around you can't see anything but if you get lucky, you can hit space bar and yes, mute this thing. So it's a great example of, I don't know what the team behind this product why they chose to do that but it's very likely these are very custom looking buttons that they have on here. And they probably styled a button, a ring showed up when they weren't expecting it, and they were like, 'Let's just get rid of this.'
Brian Kardell: Yeah. So the reason that it didn't become a style sheet was performance. They're worried that we would create too many things that would potentially switch too often to be performant. I don't know how true that is in reality, to be honest, because container queries now are similar. You have a lot of rules and they kick in at all kinds of times. But it was a reasonable argument anyway and also, there was a preexisting, :-moz-focusring pseudo class that was Mozilla specific extension, prefix extension. And it was effectively very similar, it never really articulated itself super well, but the intent was the same. So we went the pseudo class route and we rewrote the little polyfil we had for it. And then it sat for a while and maybe, I don't know, it wasn't that long, and I used it and found some things that I was like, 'Oh well, now that I use it, there's the thing that I didn't expect.' And we tweaked it a little bit, and then... Is this the one that got picked up by...? I think it got picked up by Slack.
Alice Boxhall: Yeah. I think they were using it pretty early on.
Brian Kardell: Yeah and Twitter too maybe was using it.
Rob Dodson: Yep.
Brian Kardell: And they both also gave some feedback where it was like, 'Ah, we did this thing that you didn't expect and got this result that we don't expect.' Right?
Alice Boxhall: Yeah. So the example that I was looking into when I was trying to refresh my memory and that I remembered as an interesting problem, and that I've even had discussions with in the last year, just with friends who were developers, as this has been coming out, they're like, 'Oh, why does it work this way?' So I was interested to go back and remember exactly why we made these decisions. So the problem that they were having was that a user would press a keyboard shortcut, like a command key shortcut to open their little side menu that has all of the... The right hand menu that has some interesting stuff in it, power users would hit a keyboard shortcut to open that menu and it would pop into :focus-visible mode because they pressed a key. And that was our heuristic is like, 'If you press a key, we are going to pop you into :focus-visible mode, and the next thing that gets focused or at the current thing that has focus, will show a focusring, or will rather we'll match the :focus-visible pseudo. Well, this guy Todd working there was like, 'Yeah, this is not working for us. It's putting us back into this button focus hell scenario that Marcy described where users are just constantly filing bugs. Why is this ugly ring showing up when I've just hit a keyboard shortcut? It doesn't make sense.' And initially I was resistant, I was like, 'Well, but a keyboard based user would definitely be using that shortcut and would definitely want to see the focus style.' So there was a bit of tension there for a while, and then Todd gave some more examples and I think some other developers popped onto the thread to say here that we've had this problem too. And yeah, eventually I think the three of us was convinced that-that was not the right choice. And I think looking back through the thread, it looked at the time we changed the heuristic to be that only tab and shift-tab can change mode but I believe now that has since been revised. My recollection last time I looked and I think it may have even changed since then, was that a command/control key combo or a meta key combo won't change it into :focus-visible mode, any other key press will is my recollection.
Brian Kardell: No, that sounds right to me. I remember there's also cases where it's like you made a thing that's content edible or something and you press keys, they're letter keys or something and you want that to work, you know?
Alice Boxhall: Yeah. Or the other example that always comes to mind for me is a spin button. So maybe you've clicked on this thing, but even in my case, I really don't like trying to use the mouse for those things. I like to click it to get focus and then use the arrow keys for the fine adjustment. So it's nice if I start pressing keys to know, 'Okay. Yeah, the keys are going to the right place.' So that's just one example of the details that you are forced to think about once you are actually trying to standardize something. We're trying to write the spec text and you're trying to make the implementation that is going to work be everything to everyone.
Brian Kardell: It probably cooked for, I don't know, a year and a half, something that, we got feedback, we made changes, we got new insights, we made some changes and then it sat there for a while and then Igalia... So Igalia works on web browsers, and we have this model where we work with a single client. And so we have somebody like Bloomberg, Bloomberg tech come in and say, 'We're really interested in this grid spec, but it's not getting the priority that it needs and we'll hire you to do that work.' And that's awesome but when I was here first, I was like, 'But why does it have to be one company that pays?' Because that's better than the browser vendors plus the companies that Igalia contracts with is better than just the browser vendors, but why does it matter if the money came from three people or three organizations? We have this idea for talking about the complexities of prioritization and how investment in the platform works. There's a lot to unwind here. I mean, you can look at this podcast, we have a whole series of web ecosystem health that digs into all different aspects of this. So we ran this experiment to start that conversation called open prioritization, and we had to make this list of features that were call them shovel ready products, things that we could get to work on that weren't controversial, that were just needing priority, needing implementation in some browser and we wanted to get a real mix of things. We wanted to get something in HTML, and something in CSS, and some things in JavaScript maybe and maybe things that were the last implementation versus the second to the last implementation, or even maybe the first implementation, but we didn't want it to be overwhelming. So we picked six things and both :focus-visible and inert were on our list in no small part probably because I was on the panel advocating that they should be. So we did this and both :focus-visible and inert were the two finalists, other people agreed with us with their pocketbook, they said, 'We'll kick in a dollar or $10 or $50 or $5,000.' And it was people and organizations, and when you look at the real money that was raised, it was primarily from just a very few donations that were from companies like The Amp Project pledged $10,000 toward whichever one the rest of the community chose. So I think that's great because it gave developers a view into the complexities of prioritization. And we have to pick one, it's one is what we can pick. And here is what it's going to take to get it done, and now go out, and help raise awareness and find the companies to help back it up. And so that was cool and :focus-visible won, and part of the reason that-that got on the list is because Mozilla picked it up and so it was the easy argument. That's the last implementation of that one, and what's interesting here is that when Mozilla implemented, they also had questions, they added more tests and they were like, 'Hey, what about this?' And we were like, 'Wow, I guess we have to talk about that now.' So the second implementation added some more tests, it clarified a few things. It made sure that we were consistent in a way that we weren't when there was only the one implementation. And then when it won, :focus-visible is the one that won and Rego did it, he found a bunch more tests that he had questions about. And this is actually really common that the third one... The second and the third one ask questions that the first one didn't, it seems to me, I don't know. Do you agree or no?
Rob Dodson: I think so. I also think :focus-visible is such a can of worms, because focus behavior itself was never spec'd really that well. And I think Alice did a great job of trying in the spec to write out, here is the behavior and all the decision tree branches that this could go down, but previously that didn't exist. And so it definitely makes sense, there was a lot of questions based on that.
Brian Kardell: Yeah, but the fact that normally it's each implementation winds up coming at it with different people and fresh eyes, and sometimes they ask questions that we didn't think about and that we're like, 'Well, this isn't consistent and does that matter? How much does that matter?' Going through the exercise absolutely improved it. It took a long time but the end result is that browsers will answer this much more consistently than they ever have. And like you said, Rob, all of these things were very inconsistent and under specified, in fact, they're not the only things about focus. We had a huge document that we made of all of the spiral out of questions. And somewhere along the way, I don't know how, it is linked up, when I looked at the notes. And I don't know how Dominic wound up deciding to open this focus meta bug, but it included a lot of those things that we talked about.
Alice Boxhall: Yeah. I suspect that might have come more out of custom elements and trying to think about what do custom elements need to be able to specify about their own focus ability and focus states? I don't know for sure but I suspect that was the origin of that meta bug.
Brian Kardell: Yeah. If you follow through all of the links in all of the GitHub issues, you will go around in circles for a really long time, they will spread out far and wide because I remember one of the things that I was interested in very early on is, when I created a custom element can't I specify which one of these it is? Can't I pass an argument to say, 'You're texty, you act more like a text box versus you act more a like button.' And it took, took a while, but through a lot of those things there's a whole tree of issues there. Yeah, I don't know, I think it's very interesting, it is actually more consistent than I imagined it would be in so many cases.
Alice Boxhall: Yeah and in fact, we initially had a position that we didn't necessarily have consistency as a goal.
Brian Kardell: Right.
Alice Boxhall: Yeah. Earlier on the first draft of the spec text was deliberate about saying browsers can choose their own heuristics because we didn't want one browser saying, 'We think it should work this way.' To be a blocker to implementing it. The critical thing is that there is a way to say, do what the browser does because without it we end up with these fail states where either you get this confusing focusring where you don't want to see it, or in order to avoid that developers just switching off all of the focusrings. And both of those were fail states that we were explicitly trying to avoid, that were just the status quo at the time.So we were saying, 'Yes, we encourage this idea that the heuristics can be different between browsers and can change over time as we better understand this very poorly understood space of focus behavior.' You've got different operating systems that have made different choices for how their platform should behave based on various things. One of the things that I realized is that I think the reason that on Mac OS when you click a button, it doesn't get focus, and it took me years to understand and finally with the help of one of the WebKit engineers, that the reason for that is because there is a platform expectation that you will be able to use the arrow keys to scroll the page in the majority of cases.So you want to focus as few things as possible on click, and that is a platform wide choice that they've made, and naturally they want to be consistent across the platform with that choice. Versus on Windows, they very early on made a choice that, 'We want to focus more things so that you can interact with them with the keyboard.' Is my assumption, yeah.
Rob Dodson: I think on Mac OS too, if you hit the space bar it scrolls the page too, whereas it would click the button again, if it was focused.
Alice Boxhall: Yeah.
Brian Kardell: And interesting thing here to me is that the act of going through these conversations is that everybody wants to be sure, even though we leave a lot of room for interpretation, 'Does this fall in the boundary of the expected divergence from norms or are we actually going to wind up in a situation where we just, again, disincentivize?' Like you said, Alice, with the early use in Slack, they were like, 'No, this puts us back in a button hell.' When nobody wants to recreate an old problem with a new solution. It was slow but there was a lot of really careful thought and I think there were actually changes made to literally all of the browsers, not huge ones, but a little bit and we aligned in ways that I thought were probably not going to happen at the outset. And I feel like that's a win, we took some of the inconsistency and frustration out of the system after a really careful review and left it where we think it actually is beneficial.
Rob Dodson: Yeah. My thinking on this is that I feel and I hope that :focus-visible is better than the old :focus pseudo class, like the behaviors are just more consistent and more what developers expect. But also a big part of what I learned in the process is focus is tricky because there are times where the browser just doesn't know enough about what the user is doing or the developer's intention to make the best guess. And so it's very tricky when you're trying to build a selector that is doing that, is essentially doing that guesswork. So in the case of Slack and them wanting to say, 'Oh, I want to hit a keyboard shortcut, I want to move focus into this new panel that has opened up.' Then we started to think, 'Well, maybe we need to have a way to give focus even more information.'So for instance, there's this concept of focus navigation start point where you're saying, 'I'm not actually going to focus a control. I'm not going to put focus on a button, I'm just going to put it on a region of the page, like a div or a section element, and so if the user were to then press their tad key, it would move to the first interactive element in that region.' So we're like, 'Oh, maybe that's what Slack wants.' Or another option is, can you give arguments to the programmatic focus API to be like, 'I'm calling programmatic focus here, so maybe suppress the focusring, because as the developer I really know what I'm doing in this moment and I'm telling you explicitly what to do.' So those are all possible avenues that one could build on top of. That's why this process is so interesting, you get so in the weeds and then you're like, 'Oh, I see how we can keep building on this.' But fundamentally, I think that's the tricky part about focus is, you're having to make a guess a lot of the time or at least the way that the current focus selectors work. It's not dissimilar from the way that responsive images used to work, and then you added source set and you added sizes. And with those two attributes, you're like, 'Okay, well now the browser knows some stuff, and the developer knows some stuff and we use these two in combination to fill in the gaps and you get a good experience.' And I feel focus as well is a start down that road, but there's actually probably still a lot more work that could be done to even build on top of it, to give developers even more fine grain control so it's exactly the behavior that they want.
Brian Kardell: Oh yeah, there's definitely so much more. I mean, I think we still have open questions about custom elements, for example.
Alice Boxhall: Yeah. Last I checked the GitHub issue about specifying focus states for custom elements is still open. I don't know where those conversations have gone elsewhere, but this made me think of another... So talking about understanding what developers want reminded me of another thing, which is that different users will have different needs and different preferences as well. So one of the things that we decided to do in Chrome was to add a preference. So the preference does two things actually, so the preference, the way the preference is worded and the effect that it has is that whenever something gets focused, you get a little temporary, very bold two-tone focusring so it's white and blue. So it pops against any background that shows up and it's quite large as well, that shows up for a couple of seconds and then fades out. So if you are someone who really needs to understand where focus has gone, you can turn that preference on and you'll get this very bold focusring that is drawn by the browser, but it also ups you in secretly to :focus-visible always matches on the focused element. So any author style that uses the :focus-visible class will always match when that preference is on. And so that was just our way of trying something to try and accommodate users who really prefer to always understand where focus is, even if we guess that it's not going to be relevant to them in that moment.
Brian Kardell: Yeah, I actually love that. I think it was a surprise to me actually, I think there were some other things happening, there was a spacial navigation spec that was being worked on at the time that we had some interest and also concerns to make sure that it doesn't create some new interesting kinds of problems. And in talking about that, we were talking about, 'Well, look at the cases that it's solving and it should, they really even be moving focus.' And we wound up doing these discussions where we were talking about roving tab index, and why that's necessary and maybe there should be a different way to do that. There's a focus group proposal now, which is cool. I don't know if either of you remember this, but we had this conversation with Joanie who is an Igalian before I came to Igalia, in the bar at TPAC, in France I believe. And I still remember she called it, we were like, 'We need a name for this.' And she called it locus of focus, which I loved, but there's so many bits to this, and so many things to think about and so many ways to spiral out into other interesting parts, many of which are still not solved, but it doesn't mean that they're not started to be solved. They might be stalled, but these things move slowly. So look, we have talked for a long time and we didn't even talk about inert. So how about we switch and talk about inert. Inert also, we began as a polyfill, inert is really interesting because you can polyfill it pretty well because you could in theory actually do all the things that inert did, but it was very complicated. You had to juggle a lot of complicated stuff to do it. Inert as a concept exists already for dialogues, and it's necessary to say that everything that isn't, the dialogue is on the top layer and everything else is inert. You can't keyboard focus to it, it doesn't get click events, all that stuff. And I remember us discussing that and like, 'Well, but there are use cases for that are not just for dialogue, that's interesting for all kinds of other reasons and there's not an attribute for it.' But interestingly, I think there was an attribute for it, I'm looking at the show notes and I see there's all these pull requests on HTML, that's like, 'Remove inert. Re-add inert.'
Alice Boxhall: Yeah. I think when dialogue was originally being spec'd, they specified this concept of inert. And I think they were just like, 'Eh, why not? Why not just give it an attribute?' And then it was in there for a little while and then I can't remember exactly why they decided to take it out, maybe they were like, 'Oh no, no one's implemented this. Yeah, let's just take it out.' Is my understanding.
Rob Dodson: Yeah. My perception of this coming in from the outside was that dialogue had almost run a ground and I remember wanting dialogue to be a thing and then I kept hearing, 'Oh, this maybe not going to happen. It's all messed up or something.' And inert felt almost... It was smaller, the scope of it was a lot smaller and so folks on the browser side were more inclined to be like, 'Well, maybe you could do that as a starting point or something.' And so I felt we stole that piece out of dialogue land and started working on it because people were amenable to it and you could build dialogues with it if you used it in a clever way of saying, 'Oh, I've got a dialogue over here and everything else will be inert.' But then Brian, as you mentioned, it also had interesting use cases beyond just dialogues.
Brian Kardell: Right.
Rob Dodson: But I just always thought that was interesting because when it finally ended up, I feel like dialogue in inert had basically landed almost at the same time.
Brian Kardell: I was just going to mention that, they did actually land at the same time.
Rob Dodson: Well, it totally didn't seem that way at first it, seemed like dialogue was done, yeah.
Brian Kardell: Yeah. So it seemed dialogue was done, but it seemed dialogue was done for a few reasons, because on the one hand there was a community of people who are like, 'The existing dialogue is wrong, it's not right. There are things that we don't agree on.' And then another thing that I can maybe take some responsibility for is there was... This is the only event anywhere that I can point to where somebody argued that maybe we should stop pursuing that because extensible web says we should focus on these primitives so let's not push on that until we have these primitives. So I think there was a brief backing off of the pushing really hard to get dialogue done. But I think that also was, there were real things that people disagreed with, and we did just manage to sort out all those things and it took about the same amount of time to do both. So I'm glad we have both actually, but maybe it would be possible to have dialogue earlier, I'm not sure.
Rob Dodson: Yeah, we stuck the landing, I guess, it worked out. Yeah, we ended up getting some of the extensible web bits along the way within our...
Brian Kardell: I think so.
Rob Dodson: Speaking of polyfils, I was looking at the show notes and we have had some discussion about the inert polyfils. So I feel like both :focus-visible and inert were good examples where the approach of put something in the WICG, and put a polyfil out there and get feedback is really helpful. Alice, did you want to talk at all about the letting items break out of their inert parent thing and the thinking around that?
Alice Boxhall: Oh boy, yeah. So I was trying to remember how we came to that decision, not to... For inert to be a one way street, basically, so you put in an attribute on an element, and then everything in all of its descendants are inert and there's no way to escape out of it. And I think that our thinking at the time was, it becomes a coordination problem because then if you're not having a top down approach with all of the components on the page if you then import some component that just decides to have, say inert equals false on one of its elements. It doesn't need any permission to do that, it's just suddenly it's popped out of inert. And again, it's not clear that this was valid reasoning, but if it was in an eye frame and something in an eye frame decided, 'Well, I just want to make sure that this ad is not inerted.' That we didn't want to expose developers to that problem. We wanted to make it just very predictable, what's going to happen when you apply that attribute? And another API style issue is that having it as a proper boolean attribute, which is true if it's there, false if it's not, is just a bit nicer and a bit easier to use. So you don't have this thing that we have with a lot of the area attributes, for example, where you have to put a string, you have to put equals true or equals false. So I think that was another part of it I definitely have seen all along the way, including now that it's shipping people saying, 'No, I want this to work the other way around.' Without saying it in as many words necessarily, but saying, 'I want it to work dialogue works.' I want it to be the thing where you say, 'This element is not inert and everything else is inert', which we certainly discussed as a potential other additional direction that we could go in. So I remember, we talked at the time a lot about this idea of blocking elements and I think someone on the polymer team at the time even made a polyfil of a sketch that we had come up with for how that might work. So the idea would be, this is a stack in the page of elements, which are blocking the rest of the page. And this would be another underlying primitive of dialogue where you put something in the top layer and it makes everything else in the page inert, but it wouldn't necessarily have the positioning and maybe not the backdrop. Anyway, it wouldn't necessarily have all of the features of dialogue. So it would be a slightly more granular API than dialogue is, and there's no reason why that still couldn't be done. And again, like Brian was saying earlier on, it really comes down to prioritization and what is there the greatest need for the very limited resource, which is time to be spent on things? So I think we thought possibly incorrectly that shipping inert would cover the vast majority of use cases in the shortest amount of time. And maybe it was the shortest amount of time, maybe seven years was just the shortest amount of time that it could be done in.
Brian Kardell: It's difficult to prove the inversed somehow. I know this is a very common conversation that I have. That's like, 'Well, this took this long. Would this other thing have worked better?' Well, I don't know, maybe sometimes. The most important thing in all of this is we shipped the thing, yay. Because for every one thing that ships there's 20 things that didn't make it and I think it's awesome. Honestly, I think that's the best thing about custom elements and shadow DOM is just that they exist because they're not the first runs at those problems. The first runs started 10 minutes after Tim posted the first [inaudible 00:51:33] HTML. Everybody has wanted to do that stuff forever, and they got pretty serious with things XPL and we just couldn't get it done. And here we have an interoperable thing that is shipping in all the browsers and yes, it has flaws and yes, it has places where it's incomplete and places where probably it's even a little frustrating, but it exists and that's a quality that none of those other things have.
Alice Boxhall: Yeah and I think I wanted to pick up on something Rob was saying, this is the work of so many people. So I wanted to pick up on what Rob was saying about even though it took seven years, I feel really happy that we went through this incubation process. Folks that were using the polyfil and gave us this great feedback on what was working for them also that wasn't working for them. And I feel we were often very quick to give credit for the people writing the spec text, the people that are loudly advocating for things, or that have their name on the git commit. Personally, I'm so grateful to everyone that made comments on the polyfil saying what was and wasn't working for them or that raised issues about is this going to negatively impact certain types of user? That this is absolutely a community effort right down to the last commits coming from Igalia from the open prioritization project. Yeah, it makes me really happy that so many people contributed to this work.
Brian Kardell: Not to switch it back to the extensible web thing again, but this is the vision of that, is how do we enlist more people? And the way that we think that you can do that is by lowering the bar to participate. So not everybody can be part of seven years worth of conversation, we have a need now and so if there's an opportunity to say, 'Here's the thing, what about that?' Enables more people to be involved, and I'm so grateful that we found people to give it a chance, and try it out and then complain when it didn't work or say in places, 'This is almost really great or it's exactly what I want.' It's so many people and it's possible because we did this. I mean, it would be less people who would answer something that was natively in a browser, and we have also since really expanded experimental platform features and origin trials. And I think there's all kinds of good things that allow more people to try a thing, but to polyfil is really nice because you can use it on a real production thing like Slack. It doesn't have to be experimental or something that you might do, it can actually potentially help you solve your real problem. So I love it, and actually it doesn't stop, Alice, with Igalia, because we got a commit a week or two ago to... I think it was the inert repo, is that right or wrong? To fix a bug.
Rob Dodson: Yeah. One of the wonderful things about it being on GitHub is that, I think filing a bug against a browser can sometimes feel like you're just writing a note, putting it in a bottle and throwing it into the ocean, but actually filing a bug on GitHub, I don't know why but it just feels like you think, 'Someone's going to read this.' And maybe it's just because a lot of us spend a lot of time working on GitHub, our own work projects or personal projects are on there. But I feel the WICG being on GitHub has lowered that barrier of entry for people to give that feedback where previously it may have been intimidating or it may have just not felt it would be heard if you go and write it in some browser's bug tracker. So I think that's also a big part of the community participation that's really valuable.
Brian Kardell: Yeah and actually, I didn't realize until recently how widely used inert was. I see everybody would want :focus-visible. I mean, I understand why it won really because it's literally everybody has that problem. It seems like maybe less people would have the inert problems, but they're hard to solve if you don't have them. But actually it got over a hundred stars on GitHub and it's not the only polyfil there's also at least one other really popular one. So that's cool, it means that a lot of people looked at it, and a lot of people tried it out, and a lot of people either found it acceptable and kept using it or gave us feedback. So yay everybody. I think that's the system working as it should, even if it is still too slow. Yeah, I don't know. Do either of you have any other thoughts? I would to throw one other thing in actually, which is working on both of these has been great because of both of you, and five stars would work with again. So I know you're doing something else, but if there's ever opportunity for us to do something again, I would do it in a heartbeat.
Rob Dodson: Yeah, likewise.
Alice Boxhall: Absolutely same.
Brian Kardell: Do you think that there's anything that we missed here that is worth covering?
Rob Dodson: I wanted to give a shout out to... And I've been a little out of the loop lately, but Brian, are you still doing the open UI stuff?
Brian Kardell: Yes.
Rob Dodson: I need to give a shout out, sorry, I don't know if you just heard my dog shaking off very loudly, but I wanted to give it a shout out to that work because I feel like touching on your earlier point, you were saying that :focus-visible and inert they did really well in these open prioritization things. And personally, as a developer, I have at many times felt browsers feel they're focusing on stuff which is maybe novel or interesting, but not often the things that are my pain point that I experience every day as I'm trying to build webpages. So the perfect example is, 'I still can't style the select element.' And shake my fist. And so I'm really excited for things open UI and the work that y'all are doing there to try and say, 'Hey, there's still so much Greenfield space around making it easier to build UI and it doesn't all have to be loading performance.' Or I don't know, whatever browser seem to care about. But sometimes I just want to build a widget that looks good, it works good, and that's still really hard, and so shout out to that project because I think what y'all are doing there is awesome.
Brian Kardell: Awesome. I love that you expressed it the way that you expressed it, because one of the things that has become a lot clearer to me, especially since coming to Igalia and seeing the things that people are interested in, why they're interested in them and the complexities of there's so much stuff. I mean, there's just so much stuff, the web has become literally the foundation of our entire world, and when you have that many people, well, they're not all the same. That stuff is hard to uncover if you don't do a lot of digging about what's important and the priorities are just really complex, there's so many different angles to it.
Rob Dodson: Yep for sure. I'm happy you're fighting the good fight, Brian.
Alice Boxhall: Yeah, me too.
Brian Kardell: All right. Well, we should probably cut it cause we're an hour, but I just wanted to say thanks so much for coming and talking to me because I always enjoy when we get to sit down and talk, and hopefully other people will find some of this history and thought interesting. So thanks Rob, thanks Alice.
Brian Kardell
Rob Dodson
Alice Boxhall