Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I am Dave--March 240th--Rupert and with me is Chris--getting a new office--Coyier.

Chris Coyier: Of all the weeks you didn't do a spooky intro, Dave, this one is going to come out like right by Halloween.

Dave: [Vampire voice] Oh, sorry! I meant to -- I really meant to be Dracula again. [Laughter]

I'm out of it, dude.

Chris: You know what I'm going to dress up as, I think? I'm going to dress up as a select element that's not really a select element. You know?

Dave: [Vampire voice] Oh, you'll probably only have one outfit unless something changes about that soon.

Chris: [Laughter] Yeah, but I can colorize it any way I want to color it. All I do is just use some tie-dye, some paint, and then I have my color how I want it. You know?

Dave: Hey, Chris, how does that relate to the show? [Laughter]

00:01:17

Chris: [Laughter] Well, this is going to be great. This is going to be a show, I think we're going to end up talking a lot about evolving the Web platform, the Web platform just being a hand-wavy term meaning just like browsers, in general, the Internet, all that. "Use the platform," is what people say. I buy into that. I'm a Web platform kind of guy. I think we all are here. The Web is good to this darn world.

What I mean by evolving the Web platform is we're going to talk about changing stuff, like the process of changing the fundamentals of the platform, meaning APIs and stuff, but also CSS, HTML, JavaScript, stuff that I'm sure you're all aware changes slowly over time. But it changes very deliberately, and so we're going to talk about some of that deliberation, I guess.

This is a complicated process. It has to do with standards bodies and all the people over there that do stuff. There's going to be developers involved like squeaky wheels like Dave and I. [Laughter] There's going to be browser vendor people and the whole complicated stew of people involved over there.

Our guest knows that world better than anyone else, probably. Our guest is Greg Whitworth. Hey, Greg.

00:02:36

Greg Whitworth: Hello.

Chris: Hey. Let's just do this part first. You were at Microsoft for a long time. You're at Salesforce now, right?

Greg: Yep. Yep.

Chris: Cool, and so you're not a browser vendor anymore. Unless Salesforce is going to build a browser, which I wouldn't put it past them.

Greg: [Laughter] Yeah, not right now. Not that I'm aware of.

Chris: [Laughter]

Greg: Yeah, it's been kind of interesting kind of coming to the other side of the fence after seven years on the platform team over at Edge.

Chris: Yeah, literally, they call it the Platform Team. That's cool. You're still involved in the Web process, so now you're kind of like an outside influencer - almost or something.

Greg: Yeah. Yeah and, interestingly enough, a lot of people may not know it, but there's a large desire for that. It puts you in a potentially good position because the majority of people, as you hit on, in the standards bodies are browse offenders, so it's a good angle to come in from. Yeah.

Chris: We had a show with Brian Kardell as well. He kind of lives in this world a little bit, too.

Greg: Mm-hmm.

Chris: Although, with a company that's kind of very specifically about, you know, this--

Dave: Implementation.

Chris: Yeah, implementation with Igalia. Did I say it right?

Greg: Yep. Yep.

Chris: Cool, so he's similar. He's a Greg Whitworth-esque person in the world.

Greg: [Laughter]

Chris: [Laughter] Cool, but one of the things that we have to talk about, probably spend most of the time talking about is form controls, which is a subject, I think, near and dear to your heart. You've been working on it for a long time, right?

00:04:11

Greg: Yeah. Yeah, so basically where this started was on the move to Chromium from Edge. Basically, we did a ridiculous, massive Excel spreadsheet, as you would at Microsoft, of all the things that we thought our end-users would be missing and would be losing. One of them happened to be, we actually continually invested and kept our form controls up to date for different form factors, accessibility, and look and feel.

Chris: Hmm.

Greg: Chrome did not, so that was one area, so we started kind of updating those.

Chris: The second Edge goes Chromium, you're probably going to gain some stuff and you're going to lose some stuff. In the losing column was worse form controls?

Greg: Yeah. Yeah, well, and if you remember, we have a massive-- Man, I still say "we."

Chris: Yeah.

Greg: Microsoft has a massive amount of dual-factor devices, and so its touch is actually very, very important and almost all of the form controls were not touch-friendly in any manner.

Chris: Ooh. Wow, okay. Well, that--

Greg: Not to mention, accessibility is a massive -- if you think high contrast, for example, which is the most used accessibility feature, none of them had high contrast support out of the box.

Chris: Okay. Okay.

Greg: All those things, yeah.

Chris: There's work to be done on form controls. Now where my ears perk up -- and all that stuff perks up my ears, too. It's not that I'm not interested there.

Greg: Sure.

Chris: But there's this kind of more day-to-day, in my world, thing where it's like there are HTML elements that we all know, love, and use sometimes, like literally a selects dropdown. Angle bracket select, I'm talking about, in HTML. You click it and a bunch of things open. You can select one of them and rock and roll, right?

But then there's this proliferation of people that have decided to rebuild that essentially exact same thing and they did it for reasons. That's another aspect of what I'm sure we'll end up getting into today is, like, why are they doing that? What does the research suggest? What's an alternative to that? What's the future of that? Why do we care at all?

I know you have a blog post about this that really digs into the data and what are developers saying about this kind of thing. Do you want to go there? Can we go there?

Greg: I'll go wherever you want, man. I could probably spend three hours talking about this, so wherever you want. Direct me. I'll talk. [Laughter]

Chris: [Laughter] Okay, so we've set the stage. We know that, at the genesis of this, you were at Edge. You're Web platform. You're concerned about form controls and wanting to evolve them and, also, the squeaky wheels like me in the world that are just like, "Why can't we style form elements? Ah!!"

Greg: Yeah, I actually think that's an important one to hit on because what was interesting about it, and it's a correct question to ask, is when we were working on these, when we were putting all that time and energy into, you know, the design teams both at Google and at Microsoft, working together on what to make, what the defaults kind of look like, and experiences.

Upper management correctly asks, "Why are we spending time on this, because I don't ever see these anywhere?" It was one of those things that, like, yeah, they should be default but should we be really putting the rigor and polish to make them this great when I don't see them on the top Web properties?

I think that kind of hit the nail on the head with regards to the status quo of just, this is how it's always been - and it has. Thirty years now, you've never been in, to your point of … select, you've never been able to style it.

Chris: Hmm. You're saying Wikipedia doesn't have selects on it. YouTube doesn't have selects on them.

00:08:19

Greg: Well, they're still highly used, but a lot of times there are hacks to make it so you don't actually see them or you only get the popup. You actually have an article that I reference quite often with the checkbox hack where it's like, sure, technically you're using the input type checkbox, but you're not. You're just basically using the model to send via forms, right?

Chris: Yeah. Right.

Greg: You're not actually using it. Then the thing that ended up coming out of that is we were doing external and internal interviews across different major Web properties and, like at Microsoft alone, we found seven different component library teams.

Chris: [Laughter]

Greg: Just do the math on money there and then, when you scale that out, just look at -- so, now I'm at Salesforce. We have an entire team devoted to it. You can just do the math on how much money across the industry is being spent redoing literally the exact same thing--

Chris: Redoing it.

Greg: --that ships in the platform but due to specific gaps - to your point. I will now let you direct it, but I just did want to hit on the dollar and cents and how there is this built-in status quo of--

Chris: Yeah!

Greg: --things are fine. Things are fine.

Chris: Just at Microsoft, if you fix this, you'd make money, let alone the entire industry together.

Greg: Oh, for sure.

Chris: How interesting. Where I think of it, and I know Dave thinks about accessibility a lot too, that's a big angle to this because perhaps the biggest talking point that I hear is, "Okay, fine. I'll rebuild the select element. How hard can it be?"

The implementations that you see of that, you've probably seen a hundred of them in your life. They're almost always bad. It's really hard to get it right from all the perspectives and mostly from the accessibility one. Does it work with the keyboard? Does it work with the mouse correctly? There's a laundry list of stuff that, in order to perfectly replicate a select, is difficult to do and often just isn't done.

Greg: Well, yeah, and it actually goes well beyond that. That's kind of why I would point to that survey data because all the browser vendors, it becomes untenable and this is something that we kept trying to reiterate with people, I would say in power positions, that can say yes or no to a team spending time on it.

It's very easy for a browser vendor to say, "Oh, well, they should go test my browser, and they should be testing this AT." It's like, but then when you look at a browser matrix and you say, "Okay, well, I need to support Safari and I need to support Mozilla and Chrome and Edge," and pick any matrix you want of inversions. Then say, "Oh, okay, now I'll go test high contrast of this control. I'll test keyboard support of this control."

Then what's funny is people say accessibility, but every AT, assistive technology. Think narrator, voiceover, NVDA, any of those. They are browsers themselves, ultimately. They have their own implementations.

In order to truly know those, you need to be testing those. James Craig, in a recent call, I thought, was wonderful, from Apple, was like, "Hey, you know, I bet you none of these sites are testing braille devices, but the browser vendors do." That's a perfect thing of, like, hey, I want to change this arrow on my select. In order to change that, I'm throwing away all of that energy and those relationships between those assistive technologies in the browsers solely to change that arrow, so yeah.

00:11:48

Dave: Just interjecting, I have an accessibility audit right in front of me. Here's the platforms they tested on: Android, TalkBack, Windows Dragon Eyes -- or Windows Dragon, which is where you talk at the screen and it does things -- high contrast, Windows high contrast, the Windows Narrator, Windows ZoomText, which is like text magnifier, I think, zooming in like a thousand percent or whatever.

Greg: Mm-hmm.

Dave: iOS VoiceOver and Mac VoiceOver. This is just one audit I have in front of me.

Chris: That's a lot. That's a lot.

Dave: I think it's eight different platforms times whatever, five different browsers.

Greg: Then all of those have different modes to traverse. Some will do -- yeah, again, like I said, we could spend an hour talking about these subtopics. But, yeah, accessibility is one of the number ones we called out from an end-user paint point perspective. Yeah.

Chris: Here's a quick thing, though. If you then just use a select and you're not doing anything fancy -- it's a form. It's got a select in it -- there's some degree of comfort there, isn't it? All these browser support matrix crap kind of, in my mind, goes away.

Greg: Yep.

Chris: Because you're like, I'm not doing anything fancy here. I'm just doing the thing. I expect these browser implementations to do it correctly. Now, I know there might be nuance there and some of them might not, but I'm kind of expecting if I just use a form and a select element -- nothing fancy. I don't get involved in any other way -- that that's just going to work and doesn't really require testing.

Greg: Yep.

Chris: Yeah. Okay. That's all.

Greg: Or like a passthrough. Yeah, it's definitely not what Dave just listed out.

Dave: Yeah. Well and, for me, it's an NPM package that comes in the browser. I don't have to test the NPM package. I just have to write the code. It just worked.

Greg: Exactly. Yeah.

Dave: But you should test the code that they do. But anyway.

Greg: [Laughter]

00:13:41

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by WooCommerce; WooCommerce being the free, open-source plugin that goes on your free, open-source WordPress install. That is if you self-install. You can run WooCommerce, essentially, as like what powers the e-commerce on WordPress.com as well. But it's all just kind of like built-in and they help you along in that process. Totally a good way to go, too, by the way.

Do you know I have a bunch of sites on WordPress.com? If there's just a simple blog, like I have this emailisgood.com one that I run and I have some for some silly side projects that I run that I'm like, I don't want any technical debt but I want a nice blog that I control. I do that on WordPress.com. But anyway, this is not a part of that, necessarily.

Let's say you want to sell something; do e-commerce on your WordPress site that's not on WordPress.com, like a self-installed one, which I have even more of those. For example, CSS-Tricks.com. I have WooCommerce on there and I have on and off over the years. But I can't see ever turning it off now because it's been so good to us. Especially over the last six, eight months, I've been using it more.

One of the things I wanted to do was have subscriptions for the site that was low-key, low technical debt, and just low maintenance for me because sometimes I bite too big on something I'm not ready to do. I'm not a one-man e-commerce shop. I don't make purses, walking sticks, or anything that I'm trying to sell to people.

In this case, what I wanted to sell on CSS-Tricks right out of the gate was kind of like a membership. I called it MVP Supporter because that's what you really are when you sign up for this on CSS-Tricks is just like a "Hey, thanks," kind of thing. I get emails once in a while of people literally asking to do that. "Hey, can I buy you a beer?" kind of thing, which is extremely generous and extremely awesome.

Now, there's a way to do it. You sign up as an MVP Supporter on CSS-Tricks and I try to do some stuff on the site for you. For example, I rounded up all of my favorite CSS-Tricks and made them into a "book" that you can read on the site. Really, they're blog posts and I think it's better that way anyway because then they're interactive and they have links and all this stuff.

You have access to read all of that. Great reference material, I hope - the best CSS-Tricks. You have access to it because I set up a subscription in WooCommerce on my WordPress site that does this, that gives you that access. It ties in with the membership plugin. You get a subscription, which gives you a membership and makes the whole thing happen.

Now, I also sell other things there. We drop ship some posters, products, and stuff. That's really cool. Of course, WooCommerce does that too. I really dig the subscription thing. Very cool.

Thanks so much, WooCommerce, for the support.

[Banjo music stops]

00:16:43

Chris: This is what you're coming at it, and now you're not at Microsoft. You're not on a Web platform team, but you're kind of on a Web platform team. Why does the Greg of today still care?

Greg: [Laughter] Because I've done Web development, what, since '95 or whatever. I would say it's primarily a passion project. But, as I said, Salesforce also has a team that does this. And so, if we're able to make it so that these controls ultimately can live in the platform, everything Dave just listed out we can alleviate not completely because, again, you should still be testing your sites but you don't need to be ensuring that keyboard up and down works on your select--

Chris: Yeah.

Greg: --and tab management is correct and all that other stuff. You should just be like, "Hey, does the flow sound right? Does the internationalization work correctly and all that other stuff?" It's not testing that sub-piece over and over again.

Chris: Right. We've talked about selects because that's one of our favorites.

Greg: Mm-hmm.

Chris: Your data suggests that select is one of the biggest targets just because it's rebuilt a lot. Isn't that what the data suggests?

Greg: Yeah, and it's the most -- probably outside of maybe date and color, built-in is probably one of the most complex one but it's the most recreated. Yeah, if you look at the most frustrating control, it's near 50%. It takes up 50% of the votes, so to recreate.

Chris: Okay, so it's a big target.

Greg: Yeah.

Chris: But there's all kinds of stuff, right? There's search inputs.

Greg: For sure.

Chris: It doesn't do that much interesting but, hey, it's there and it's got quirks too. It's suggested that if you take some big survey, you ask all these developers that do this stuff day-to-day, "What do you want?" and I ask this once in a while only anecdotally on a much smaller scale, and even I will definitely get answers that just vaguely say, "Just give me more ability to style form stuff," if you're a CSS person. "I just want it to feel normal. I just want it to be like--I don't know--that little X widget in the input type search. Why can't I style that thing?"

Greg: Exactly, yeah.

Chris: Give me a sensible CSS selector for it. Anyway, so wow, there's a lot there. What if we don't do anything at all? We covered this a little bit. The consequences then are what?

Greg: Yeah, so basically, as we kind of hit on, everybody kind of goes and rebuilds them in their own little silos. Basically, takes their design and does their best with their probably smaller teams. Weirdly enough, the argument I always say with regards to accessibility, trying to tell upper management that it's important and convince them that it's important, and so them taking the time to go build out a control that takes into effect all of those different things, one thing that's with regard to accessibility but then also, again, just rebuilding it.

You just referenced the search one. Okay, so like to go rebuild out yourself. It's a very simple one, but okay. I need to go build a box, make an asset, you know.

Chris: Mm-hmm.

Greg: I put it in there and so you're already adding time where I could have just put in a pseudo-element, potentially, or at least just been able to reach into that containing a pseudo-element that exists there and swap out that content rather than recreate the entire thing.

Chris: Yeah. Well, a checkbox is also a huge one. You already mentioned those a little bit. I remember working -- I was at SurveyMonkey a long time ago. Of course, they changed it and who knows what the original reasoning was, but they had a very iconic checkbox and radio button that were just really big. They just were bigger and the native ones have always been--I don't know--it feels like a little bit small; maybe built for the era of when things were mostly mouse cursor oriented. Sometimes, you think of those little, tiny checkboxes and you're like, that's not going to work on mobile. I need a big 44x44 pixel tap target.

Dave: It was like 680x480 screen.

Greg: I was going to say, the resolutions too.

Dave: Super zoomed in, right?

Greg: Yeah. Yeah, and that's where, again, going back to those 30-year issues like when we were redoing the Chromium ones, then there's Web compat. The layout kind of has to stay the same, by default, so they stay these little, tiny things so you don't break sites.

Chris: Yeah. Right.

Greg: Even though, of course, when we went to our designers, they were like, "Oh, yeah, we have checkboxes from our design systems across Microsoft and Google. Here's what they look like." It's like, yeah, they're all those 44-pixel ones for good touch targets and stuff. It's like, all right. Can you scale it down to, like, 15 pixels? [Laughter]

Chris: Mm-hmm.

Greg: Just look terrible, pretty much.

Dave: Designers love that. They love that.

Greg: Oh, yeah. Yeah.

Dave: That's the kind of work they love.

Chris: If you just said, "We're going to change the Web platform such that you could apply a width and a height to input type="checkbox" it makes some kind of logical sense to that. But you're saying, there's enough CSS out there on the planet that if you respected those values all of a sudden, you're going to have breaking websites.

Greg: Yeah. Yeah.

Chris: That's kind of like not cool in the world.

Greg: Just doing that out of default of just saying, hey, weirdly enough, you mentioned this. I actually have an explainer open literally just for checkbox because I feel like it's a good starting point. One to kind of get the ball rolling with this.

That's kind of one of the questions that's in my head of, like, how do we make it so that that default can occur? I'm currently thinking, leaning towards when appearance none is activated. But we'll have to go look at compat data and kind of see the overlap of, hey--

Chris: Oh.

Greg: --when appearance none is there on a checkbox, as well as is width and height still there. If we start respecting that, would that potentially break layouts and all that other stuff? That's the way I'm leaning right now because appearance none is very, very vague in definition.

Chris: Right.

Greg: I don't want to get too far into this, but my first initial draft will probably be linking into that and saying, "Hey, if that's there then, hey, you can have access to these properties that people have always wanted to touch."

Chris: Yeah. Yeah.

Greg: But currently, that isn't the case.

Chris: So interesting. All I can do is pontificate on things and let you go for it. But part of me is like, that makes a lot of sense as a first step. I mean I think so because then you're wiping out -- at least in my experience, I think that's what it's supposed to do or what it often does. This is a CSS property and value, appearance none.

Greg: Mm-hmm.

Chris: It just kind of like wipes out what's there, like resets the control to nothing, like BYO styles. Yeah, that would make sense to me.

Dave: It's very much like I'm shifting the car into manual, like I'll take care of it.

Greg: Mm-hmm.

Dave: Is sort of how I--

Chris: With that respect to the height and width, sure, but then you're kind of on your own to bring something that looks checkbox-esque to the party, some background or some particular styling.

Greg: Yeah and that's where my explainer doesn't stop there.

Chris: Yeah.

Greg: This is kind of where I don't want -- again, I don't know necessarily how you see this discussion going, but that's kind of where the open UI stuff comes in. I'll actually be proposing those, the anatomy that are defined there, and recommending those as pseudo-elements because then that kind of allows you to start doing what you were referencing with the search with regards to, "Oh, I only want to change this one part. I actually don't want to add a border or this, that, or the other. I actually just want to touch this, just this part, or I want to adjust that."

Pseudo-elements come with a ton of limitations that you have to check because you're kind of like, okay, well, to make it so that they can change the color, okay, well, in order to do that we then need to make it so they can never change what the X looks like.

Chris: Oh, I see.

Greg: You better love the variability between -- like for example, at one point -- the X is a bad example, but if you were to think of a password reveal, like an eyeball. Those work very drastically across operating systems. You better love the eyeballs that ship with those OSs and UAs or, sorry, browsers because then you could change the color real easy but you couldn't make it match your brand if you had a specific glyph you had for eyes or Xs or whatever.

Chris: I see. Yeah. Really, a tightrope you've got to walk.

Dave: My eyeballs all have to have big eyes with big eyelashes. It's in the brand.

Greg: [Laughter]

Dave: It's in the brand guide.

Greg: Yeah.

Chris: With the checkbox, if we were speculating, it'd be like, okay, there's the UI of the square itself.

Greg: Mm-hmm.

Chris: How rounded is it? What's the border? What's the background? Is there a gradient involved? Yadda-yadda.

Greg: Well, and that's where I don't want to get into that.

Chris: Yeah.

Greg: What I want to do, and this is actually great, I'll just bounce it off of you all because I'm actively writing it.

Chris: Okay. Let's go.

Greg: You can tell me if it's dumb or not. Yeah, basically, what it would be doing is, we have a rough draft anatomy already in Open UI. Basically, the checkbox currently has a determinate, indeterminate states and checked or unchecked. Basically, most design systems and component libraries across the Web have different glyph spaces for the indeterminate or checked.

Chris: Right.

Greg: Basically, when checked state are adjusted, they change the checkmark out in some way. In order to light up the scenario that we were just talking about, being able to change it, all of the pseudo-elements, all of the CSS properties, I would like for you to be able to adjust. You wouldn't be able to detain -- aspects of display types, you wouldn't be able to adjust. This is where I say pseudo-elements are limited. You can come in and say, "Okay, well, now I want to align self-center assuming that you're in a flex or a grid layout," because you may not be.

Chris: Yeah.

Greg: So, that may not work. But with regard to the glyphs specifically, I'm probably going to say it should be a background image. The reason why that I find that valuable is a lot of the implementations are actually just painted. They're not even graphics or SVGs. They're just direct to render calls to the rendering.

Chris: Really? Like the checkbox?

Greg: Yeah.

Chris: The check in the checkbox is not--

Greg: Yeah.

Chris: --a normal resource that you'd think of it as.

Greg: Yeah. Yeah, and so what I'm trying to piggyback on there is, there is the new paint API that basically came out of CSS Houdini.

Chris: Right.

Greg: That basically becomes an image. What I'm going to propose is that it be a background image is how this is implemented and then spec that. What that then means is, technically, under the hood, they can still call their same render logic, and it just kind of maps back to that same statement.

But then that also allows your normal CSS developer that, yeah, I go produce a PNG that has an alpha channel. I'll throw it in a background image and, cool, it works. It does what I expect it to do.

Chris: Which opens a world of possibility.

Greg: Yeah.

Chris: That would be amazing for designers.

Greg: Exactly.

Chris: Cool.

Dave: I wonder. Feedback time. I wonder, though, if people want animation.

Greg: Mm-hmm.

Dave: Like little pops and sizzles. I think of, like, material kind of has that when you fill in the checkbox. I wonder how that would all work, but it seems like a good first pass.

Greg: Yeah, you would probably be able to do very simple animations, but you wouldn't be able to be like -- and again, it depends on how your container is implemented. But one that's real quick that I reference in one of the talks I gave was if you're on Amazon and you're typing in your password. They actually have the word "show."

With this one, you would have to insert an image for the word "show," which is really hokey. But then others I've seen, the eyeball is outside of the password box field. Let's take that scenario. Well, if I want to move the eyeball outside, a common thing people would do is, oh, well, I'll position absolute and I'll make it right zero. I'll make it so that the checkbox itself is positioned relative.

But the thing is, the user agent may have said, "Hey, this input is overflow hidden and you can't touch that." At which point, now your eyeball is gone. It's completely clipped.

To your point of the animations, this is why I say pseudo-elements are good and they get you -- I would say they probably solve a good 50% to 70% because I haven't actually done a study on this. But they solve a good amount. If we supported widths and heights and said, "Hey, you can change the checkbox itself and you can change the border and the gradients, you can do all of those things," but, "Hey, unfortunately, we're probably going to need a next here in order to light up exactly what you may go do if you were to completely rebuild your own from scratch," I still think it's a great first step because pseudo-elements do require, unfortunately, that limitation. But it's a good foundation to build on top of, I guess, is my point.

Chris: Yeah.

Dave: Yeah. The other thing I wondered about with a raster asset, I think you said no SVG, but I would need different, crisp graphics for even this new iPhone that's 72 billion pixels or whatever.

Greg: [Laughter] No, it could be an SVG.

Dave: Crushed crystal. Okay. Okay.

Greg: I just was saying it would need to be -- yeah, go ahead.

Dave: But then times theming, right? Because now we all have light modes, dark modes.

Greg: That is the benefit of saying, "Hey, we're going to go," because the way we initially implemented the password because we actually had a proposal for the password reveal at Edge. Initially, the way that we implemented it was, it was implemented as an SVG, and so the fill color would propagate in. You could adjust basically the glyph color.

Chris: Hmm.

Greg: The problem is not all glyphs are created equal, and so do you need multiple glyph colors in order to achieve that? If you end up like my center eye is black but the outside is a different color and then you say, okay, well, I'm going to send in black, so now you can't actually even see an eyeball? It depends on where I then decide to put that fill color.

Then in the inverse, you want that complete control. You end up hitting what you just referenced. I have dark modes. I want them to be able to change a property in some admin panel of highlight color and that'll change all my glyphs. Okay, well, now you're going to have to generate images on the fly because, unfortunately, at CSS time, you can't propagate in that information because it takes that SVG and it rasters it, even if it's SVG.

Dave: Hmm.

Greg: You can't dynamically propagate those values into it.

Dave: I tried. I tried to do that last week.

[Laughter]

Dave: It didn't work.

Greg: It would be cool.

Dave: I just had to put two SVGs in. It was fine. It's fine.

Greg: Yeah. Yeah and, like I said, I think it's a good step in the right direction but you're quickly seeing how, like pseudo-elements, you kind of have to choose a path. You can't just have your cake and eat it too, unfortunately, with pseudo-elements. That's why we're not stopping there. [Laughter]

Dave: [Laughter]

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you by Framer. That's framer.com/shoptalk. Go there. Sign up for free or get 20% off any paid plan. That's very generous. Thank you, Framer.

When you've spent hours designing something beautiful for the Web, the last thing you want to hear is, "Uh, sorry. Uh, we can't build this." You know? Ugh. Ugh.

What you need is a tool that bridges the gap between design and development. Framer can be that bridge. It's a browser-based prototyping tool that enables designers to use code-backed components and dynamic transitions to visually express ideas. When the time comes that you, perhaps as the designer, are giving it to a developer, the developer can jump in and easily inspect the elements, get the CSS or the JSX right from there.

Custom animations custom-built with Magic Motion. It's powered by Framer Motion, which is an open-source library that's awesome, that you should check out, for React.

It all comes with complete, clean code, which can be taken right from Framer and you can move it right into production. It's the gap. Framer is the bridge.

Sign up for free or get 20% off any paid plan by visiting framer.com/shoptalk. That's framer.com/shoptalk.

[Banjo music stops]

Chris: We're talking about the accessibility concerns a bit, too, but Dave was also like, "Well, just NPM install it," kind of thing. There are performance benefits here, too, if you don't have to rebuild anything.

Dave: Mm-hmm.

Chris: You get some performance out of the page itself because it's just using the platform, as they say.

Greg: Mm-hmm.

Dave: See. Sorry. I'm curious about the future here. Let's say all the form elements get fixed. Do you have a date for that, Greg? Is it next year? Next Tuesday?

Greg: Oh, goodness gracious. Yeah, I don't know.

Dave: Let's say they all get fixed. I wonder if there's a bar where it's good enough to where I don't need to bring in all my custom mumbo-jumbo. You know what I mean?

Greg: Yeah.

Dave: Or I wonder if it's going to be this: You open the genie out of the bottle and it's, "Oh, now they're good and I can style them. Now we've opened a whole industry of custom style components," or something. I wonder what the future holds. Maybe both futures. I don't know.

Greg: I could it seeing both. I would say, when you were talking about good enough, I actually feel like I would say that is kind of our -- good enough is probably not -- I wouldn't say our goal. We've done a ridiculous amount of time looking at all the use cases for the majority of the top pain point form controls and have come up with a model that I think is good--kind of to the extreme--along the spectrum. But also understanding we should come fill in the pseudo-elements. We can get those out the door much faster, still unlocking use cases but not unlocking all of them.

I always like to think of jQuery. Why did the majority of people reach for jQuery? It was because it saved me four lines of fetching a specific element and chaining things together. It provided all this roughly syntactic sugar around JavaScript that I was having to write. Once they added query selector all and promises and stuff, it's like I have never ever needed or thought about jQuery, man, probably close to a decade now.

Chris: Yeah.

Greg: You end up finding those and that's kind of where that survey is driving the direction of the top ones we'll focus on. I think, over time, you will see people going, "Oh, okay. Cool. Yeah, I don't need to bring in--" You may still bring in a bootstrap, but the hope would be bootstrap is actually just using the native ones there.

Chris: Right.

Greg: The libraries would change over time and that's kind of the angle we're going. That's kind of why the open UIs of the world and everything bring in the component library authors and the wonderful tab knowledge experts such as Dave Rupert here, in hopes of making it so that it solves enough use cases that everybody, whether they be bootstrap or material design or office--it doesn't really matter--can go leverage them.

Chris: You think the next generation of those things will be like, "Hey, use these amazingly designed, incredibly beautiful checkboxes," and it's like 40 lines of CSS. That's it.

Greg: Yeah. Yeah and I wouldn't even say that they're -- yeah, basically, the goal, and to try to put it succinctly, the way that kind of try to describe it is there is an implicit definition of controls on the Web platform. But to, I would say, my surprise when I first started looking into this, there is actually no definition of a control - standardized definition.

What's interesting is, actually, all the controls on the Web platform follow an MVC model. For those that may not be aware of what that means, it's a model view controller. If you do any type of form engagement or even components for that matter, you know that, hey, the input has a value, you know, a property hanging off of it. Well, that's part of its model. You update and change its model.

You know required is a part of its model. Is it required or is it not? Basically, all of them have built-in kind of controller code, so the select example you referenced. It has a button that, when I click it, it changes a state of open. Granted, if you have multiple, a lot of those are written into the page, so they don't have a button.

Chris: Yeah.

Greg: But anyway, you're changing that controller code and that controller code has a known understanding of what a select is. It's like I'm going to have options underneath of me. When you press the keyboard arrow down, I'm going to traverse to the next option. I'm going to highlight this thing that's selected. Then when you hit enter or click a mouse button, I'm going to update the value.

What we're really trying to do is lean into, let's fill out the model in the view because when we go look at the majority -- and I say the majority, like 80% to 85% of the use cases -- they're wanting to slightly tweak the view. It's like let's give them that capability to tweak the view, I would say, to the extent that it kind of goes to the extreme. But also define the behaviors as well, so when you do get into that 10% of people that are like, "No, I actually want to prevent default that you've got assigned to this button and take it over," they can do that as well.

Chris: Mm-hmm.

Greg: But ultimately, we want to be able to say, "Here is the defined anatomy," so the parts.

Chris: Yep.

Greg: "Here are the defined behaviors and the states," but allow the author to change the view while also the UA is shipping a decent version. You need to give that kind of switch of, like, "No, I want to go into this interoperable where I want to reuse the behavior," similar to what we were talking about with appearance none because that's technically how appearance none is spec'd. WE just haven't evolved to that next step of saying, "Okay, well, now let's go define all the parts and maybe a base style sheet," that, when you're in appearance none, everybody goes and falls back to this default DOM structure and default style sheet to where then everything Web developers have wanted is possible.

Chris: Hmm.

Dave: The model would still -- the logic that makes the select box do a select box, that would still be there.

Greg: Yep.

Dave: But it's kind of like -- now it's just basic HTML that is on the view. That's what the view spits out. It doesn't spit out the weirdo custom--

Greg: No, exactly.

Dave: Or like, what, OS-dependent--

Greg: Yeah.

Dave: --replaced element thing.

Greg: Yeah, I mean it would still be probably technically a replace element, but we're defining everything in Shadow DOM terms. It would be Shadow DOM-esque, except for the fact they wouldn't be -- like they would already be pre-known to the browser. It's kind of introducing you, to an extent, to Web Components. This is the thing we haven't defined fully yet. It may just be we actually go define all the pseudo-elements for the parts.

Chris: Hmm.

Greg: But we do have the part attribute, for example, and so we do have a capability of saying ::part function and referencing that part. We may just lean into that rather than standardize everyone.

Chris: That's interesting. That's literally a part of the Web Component spec, API, or whatever you call it.

Greg: Yeah.

Chris: The form controls of today are Web Components?

Greg: No. No.

Chris: But they might be?

Greg: The form controls today are -- oh, goodness gracious, dude. It really depends on which form control you're talking about, which engine.

Chris: But they could be.

Greg: It's all over the map. Yeah, and that's--

Chris: Maybe--

Greg: Yes, and that is kind of what we're looking towards. I'll end up sending you guys the link. I recommend referencing it. It is a read, so grab some coffee.

Chris: [Laughter]

Greg: It delves in very deep into how I would say we're looking at that more extreme bucket because we wanted the full picture while also understanding we want to check off some smaller boxes along the way.

Chris: Yeah.

Greg: It basically gets into that full anatomy and it's leveraging, basically, what was defined Web Components because, ultimately, Web Components were actually just defining what the browser already did because it replaced element. They actually had HTML underneath of those, so you take an input type range.

Chris: Yeah, that's a Shadow DOM, kind of.

Greg: Yeah, exactly. We do it. We have a bunch of HTML underneath of it. We just surface to the DOM that it's just an input type range, but it's just HTML and CSS underneath of that - in a lot of the cases. Some of the cases, it's like I said. It's custom render calls to the--

Chris: Yeah.

Greg: Yeah, so.

Chris: I would think Web component activists would be excited about that, too, if there were more of them native to the browser. That that would get people more excited about using them themselves for building other things. I don't know.

Greg: Yeah, and I think this again goes back into the -- my hope. Yes, I would love to leverage Web Components and make them be native. My also hope is, down the road, again, since so many of the Web Components people build are just these. [Laughter]

Chris: Yeah.

Greg: They would actually maybe -- we would need less actual building of components. They would actually not need to go build the Web Components themselves. And so, the components you would end up seeing are ones that aren't actually native yet but may be down the road. You may be building out a Carousel component or something like that.

Chris: Yeah. Well, if Web Components could extend to other Web Components, which they kind of can.

Greg: Yeah. Yeah.

Chris: That'd be pretty rad. Okay, well, I want to get to this.

Greg: Yeah.

Chris: Because you've said the word "Open UI" a few times, but we haven't really defined it, the URL there being open-ui.org. It looks like there's a lot here but, for example, along the sidebar, you can click to the select element and it just gets way into select.

If we're just mouth blogging and we're like, okay, a select. Yeah. Whatever. It's open or closed. It can be multiple or not. I don't know. It seems pretty simple, right? This does a good job of showing kind of the deeper anatomy of a select, showing you just how complicated a select can be. Is that the point of this? What's the--?

Greg: Open UI, like I was saying there, there were seven teams I spoke with at Microsoft. Salesforce has one. Basically, all it's trying to do is there has never been a standardized place for what controls or components are and how they're actually defined. Because of that, controls are interesting, controls and components, both of them, because they actually span the entire Web platform.

Basically, there's been piecemeal attempts, so like CSS has added pseudo-elements, which get you some things but not all things. Then HTML has certain things. The one I like to point to the most is details and summary where it actually starts defining the anatomy.

Chris: Yeah.

Greg: It'll be like details has a summary. When a summary is clicked, it propagates to the details and it takes this event and it changes. Basically, right there you're saying, here is the anatomy and the behaviors.

But it then doesn't go and say, "By the way, we're going to make sure that all of them have these parts and these parts are referenced via pseudo-elements in CSS." Again, they're not taking the entire picture.

What that ends up doing is every single component library design system teams out there that exist come up with a design. They end up producing what a lot of them refer to as blueprints, which is basically what Open UI is trying to follow. It's actually allowing the Web Component design system to drive the direction of this. This is something we quickly saw in the Chromium stuff.

So many of the questions we were asking, we would actually turn to our component library authors and say, "What did you all do?" because, on the Web platform, we don't build them every day. We're not constantly in this world.

They'll have user research of, "Hey, in Office, we saw this from end-users, so here's the best experience, and here's the best way to do that control." We didn't just want to stay in the Web platform silo and pretend that the Web platform folks are the smartest and most brilliant.

That's actually why I'm really excited about this because of the fact that it gets us out of just even the component library. Let's pretend none of this ends up in … platform. Obviously, we all hope that that does, but just even that, everybody getting together and sharing that knowledge of saying, "Hey, we're all going to work on this blueprint together. Share knowledge. Share expertise," because when you go look across the landscape, people like to … that their controls and components are so drastically different when it's not the case at all.

Chris: Hmm.

Greg: Like 80% to 85% of them overlap. There may be one obscure one that does something drastically different. But the models and the anatomies are almost a one-to-one in most cases.

Chris: You're kind of providing that here.

Greg: Yep.

Chris: You're like, "Look. Here's how a single input work. This is how it's done in semantic UI. This is how it's done in Ant Design. This is how it's done in material or UI fabric or whatever. Look. Look. They're all the same. Look."

Greg: Yeah. Yeah and again, the CSS working group actually just had -- somebody was like, "Hey, let's standardize the file pseudo-elements that exist across browsers." It's like, "Okay. Cool. Let's do the research on that," and we have an open PR that'll land here soon for the anatomy of that.

Basically, it's like, let's do the research and just make sure we're not designing ourselves into a corner because the only reason we want to add this stuff is so that people use them for all the end-user benefits you noted earlier with regards to accessibility and performance and all of those things. If we don't unlock that then people aren't going to use it. So, let's not waste our time spec'ing nor implementing pseudo-elements that don't drive us toward that.

Chris: The biggest design systems in the world here that you're referencing, so if you reference all of them together--

Greg: Yeah.

Chris: --chances are you're going to get it right.

Greg: Well, and then on top of that, we are always looking for more design systems. We don't want to pretend that -- or even if it's not a design system. It's just, "Hey, I use the same select button on every single one of my sites and I only happen to -- you know I'm a person of one, a team of one," which I have been in the past at some Web dev shops. It's like, please include that as well. We want to make sure all the use cases are covered. I don't want to diminish ones that are more one-off.

Yeah, you quickly see the Venn diagram is drastically overlapping. Even ones when people will bring up, so for example a lot of people bring up the iOS scroll wheel to me, for example. It's like, again, we could make it a CodePen challenge of everybody go leveraging the model and the controller of a select, you know, design ones. I've built radio ones for watch faces. I've built the scroll wheel one because the model is the same. You get N plus options.

Sure, I have a window that's position fixed that takes up 60% of the viewport and it's at the bottom. Okay, well, now let's add in touch gestures to make it scroll. Yeah.

Chris: What Greg is talking about is you open up a selection on iOS. The experience is not at all like desktop where you see this little menu and you just pick the one that--

Dave: You get a slot machine.

Chris: Yeah. [Laughter] You go to Vegas for a minute and you spin them around.

Greg: Yeah. Yeah, and so it's like I'm really trying to, and that's kind of why we were saying, ultimately, you want to get to the point where every behavior is defined because you then do want to be able to have people say, "Well, on that touch event, I want to prevent default because I do want to do something a little different."

Chris: Right.

Greg: In that next stage, this is what's beautiful. I met with … working group about this. Every single one of these component libraries and design system teams, like I said, go to HTML specifications, CSS specifications, CSS-Tricks, Stack Overflow, you name it, to put together this blueprint on how best to build out this design that they've been handed. Then they also go to ARIA best practices.

The thing that I can't stand -- I love that it exists, but the thing that's so unfortunate is the design system or component library author now has to go through and do an algorithm in their head. If you go through and read them, they're like, "Sometimes they may have this at the top. If that is the case, then you do this. Sometimes they may be this. If that, then reference down here. Do that."

Chris: Hmm.

Greg: Once you define the parts, which again CSS pseudo-elements already do, certain HTML elements start going down that road as well. Once you define the parts, you can get very concrete about the states and start getting into the controller code.

You can start saying, "Here are the behaviors that are tied to these parts, and here are the implications." When this is clicked, you're going to change ARIA role or you're going to change all those different capabilities, which then you have a spec for, which then allows the Web developers of the world to come and say, "Oh, this part has an unclick event, you know, a listener tied to it, so I can then just hijack that for my needs on this part." Yeah, it just becomes very powerful and, like I said, even if they don't end up in the Web platform, it's getting all these experts that do this daily showing, if you're going to go build your own, the best way to do it backed on user research, based on real usage on top Web properties as well.

Dave: There are some things, like Open UI, one of my favorite pages is the component name matrix where you just list what components are in each design system and what they're called. I guess it's kind of the idea of, probably, abstract what this thing is called across a bunch of things. We've talked about these interactive elements like checkboxes, selects, and I'm kind of into tabs right now.

Greg: Mm-hmm.

Dave: There are probably things that are fairly ubiquitous like badge, which probably doesn't need an element, right? That's just some--

Chris: A span.

Dave: A span. Yeah, right, with a background color.

Greg: Yeah, and I love that you brought that up because, yeah, basically, I would say the initial goal here was, actually, let's just start. Let's take those seven teams at Microsoft and across the industry and try to make them one. Let's try to just leverage the knowledge base and, yes, we will probably end up with 30 or 40 components across that left side and I don't expect 30 or 40 new elements in the Web platform. But I'm totally cool with somebody coming forward and saying, "You know what? Let's stop pretending there aren't 80% of Web traffic getting this element."

While, yes, you're correct the badge is a span, it also comes with the ARIA semantics and this expectation - going back to the braille reader. I just feel like it should just be on a case-by-case. Is there a strong reason to put it in there?

We actually already have one, so along the left side, you'll see that there's a skeleton component. Every design system and component library out there, pretty much the majority of them, have a skeleton component but we can't define an anatomy for it because it drastically differs. Some of them, if you think of a financial site, they'll be like stock charts. In another, it'll look kind of like Facebook where it's got an avatar with some stuff. Basically, it's a div, honestly, if you get down to it.

Chris: Right.

Greg: The only thing we could define would be a container. That said, there are ARIA benefits to a skeleton of doing it right. There is an ARIA busy, and we actually went to the ARIA working group. We're like, "Hey, should we have a new role for this?" because it's wildly there. Basically, we can come up with a way to accomplish this for accessibility but maybe we should just make it a role because it is so ubiquitous.

They were like, "No, just recommend these two different properties." I don't remember them off the top of my head, "These two different attributes." Ultimately, that's okay. Like Open UI, some of these may just be, "Hey, if you're new on a design system team and you want to know what the definition of a skeleton is." We may not be able to find enough overlap or enough meaningful content but, hey, at least we still have a definition of what it means, which is okay, again.

Chris: Yeah.

Greg: Open UI is kind of going that full-spectrum, taking it case-by-case, and saying, "What is the 80%, 90% overlap? Let's get a blueprint in there for that."

Then also, hey, like Dave referenced tabs. I think that's a great example of one. Let's get it in here.

I can see us being able to walk over to WHATWG and say, "Hey, we've done all the research. Here's how it should behave. Here's how it should work. We're going to submit a PR for a tabs element and here are the parts that should be applied to them." Then we can also have the same discussion of, should we have pseudo-elements for these or should they be elements? You know what I mean?

Chris: Right.

Greg: That's kind of the flow that we kind of expect it to take. Dave is helping work on the tabs one, so I'm super excited to see that come through and lend his expertise there.

Chris: Yeah. I could see a new HTML element working for that.

Greg: For sure.

Chris: Although, that's a whole can of worms here. But I like the idea that the skeleton wouldn't be because there are other things that get involved here. I was just kind of reading about this new CSS thing called containment.

Greg: Mm-hmm.

Chris: There's containment, but there's also one that I forget. There are a couple of different ones involved. If there happen to be an HTML element named skeleton, which I cannot see the day that that would happen, but maybe, that then it would be your job to rip it entirely out of the DOM and replace it with a div or whatever else comes in when the skeleton is no longer needed. That's going to be problematic for reflow and stuff.

Now the CSS property that you've just applied to this thing because you want it to--I don't know--have better performance for layout is moot because you just ripped it the hell out of the DOM and replaced it with something else. It's not just accessibility. There are other concerns as well, I would think.

Greg: For sure. Yeah.

Chris: Okay, so that's Open UI - very interesting. Again, open-ui.org will get you there. There's an explainer. It's all very interesting research here - very cool.

Greg: Please, people, get involved. Like I said, we want anybody that's willing to engage if you build for controls. It's a community group. We have a Discord channel. Even if it's just to jump in there and tell us we totally screwed up on anatomies for certain things, by all means.

Chris: [Laughter]

Greg: It's pretty lightweight.

Dave: I could even use -- is that the best way to get involved, hop into the Discord?

Greg: No. GitHub issues is probably the best spot, but we have a biweekly call. Like I said, I'm trying to really let the -- because I have years of standard experience and this is one thing that I would love for Open UI to potentially crack, which is, I'm trying to let the component library and authors tell me what makes most sense for them with engagement here. It's because I don't want it to get so bogged down into, like, hey, process historically.

Yeah, we have a Discord channel, which is sort of unique in the W3C and then we just have a massive Zoom call that I just send out to everybody on the Discord channel. We may end up with people that have never been in a standard meeting. The Discord channel is a great place to kind of stay up on things, but GitHub issues, go scroll through there.

Yeah, if you jump on there, ping me. I have an office hours normally on Fridays where I'm just more than happy to jump on, just chat, and help people get started. Yeah, the Discord channel is great.

Dave: This is something like the W3C or what working group or whatever. They're aware of this initiative? Are they kind of bought into the process or not quite yet?

Greg: Yes. Actually, this was a really risky scheduling of this call because, last Monday, I really wanted to have a -- I wouldn't say hold everybody's feet to the fire, but kind of like get as many people from the different Web platform places in one spot because, over the past three months, we've had numerous form control discussions on the CSS working group. Basically, they end up being meta discussions like: What about interoperability - this, that, and the other? It has nothing to do with the actual either pseudo-element or property we're talking about.

Basically, we had the meeting. I think I've shared the video with you all. Hopefully, we'll be able to put it in the links or whatever. It basically walks through the problem and I wanted everybody -- we literally have it … in the official minutes of, like, "Yes, this is a problem and we should help try to solve it."

Then also say, "Hey, we don't only want to start from the far right." This is one thing that I would love to get into deeper at some point with someone. I feel like the pendulum has swung way too far. When the Web started, we had all this magic and then it became, okay, let's describe the platform, so they moved to basically all JavaScript land to do everything down there.

We got a few benefits like we have Flex and Grid and some things that, like, hey, if I want to come from the more -- I just want to be in front-end but I don't want to be a hard-core JavaScript developer, I kind of want to come from that way, too. That's kind of why there are pseudo-elements and the hints kind of become valuable. But also understand the far right as well but take the direction from the left because I think that's where we'll solve the majority of use cases and get them the most usage.

Yeah, so that Monday meeting was great because we literally had a representative from every browser vendor. We had people from the accessibility working group there as well because they had showed -- I had thrown out the Holy Grail for me would be to get rid of ARIA best practices because, once we get to the parts and behaviors, we can actually just have unit tests for all these components.

Dave: Mm-hmm.

Greg: They were like, "Oh, my gosh. That would be heaven if we could get there." So, I wanted everybody there. I made sure to get as many component libraries and design system authors on the call as well.

Basically, there was a lot of agreed upon, Open UI will be where form control discussions and components happen. For example, Miles from Apple brought up, "Hey, you know, I want a font picker control." We're now going to use that as kind of like a good example of, like, "Hey, I want a new control on the Web platform." You bring it to Open UI. We do the anatomy, the definitions, the standardize of the behaviors, all that kind of stuff. Then you take that next step of, okay, well, now let's take it to WHATWG.

We've engaged with -- you have Office.com on the call. They would probably have good insight into what a font picker would need to have, right? You know, and Word and Outlook.

Dave: Yeah.

Greg: I'm thrilled how that meeting went.

Dave: Cool. Yeah. No. Yeah, that's sort of to make sure that people are interested. You know.

Greg: Yeah. Browser vendors, pretty much. Yes.

Dave: It's cool. It's cool. It's fun to have meetings. [Laughter]

Greg: Yes.

Dave: But if people don't care about the outcome, that's different. It sounds like people care, so.

Greg: Yeah.

Chris: Let's do a real quick zinger for Greg because Greg is a connected guy. He knows people who knows people. You know? You know?

Dave: Yeah. Yeah.

Chris: Let's say you, Greg, were a company that rhymed with Blazilla.

Greg: [Laughter]

Chris: You had massive layoffs recently.

Greg: Uh-huh.

Chris: You being Greg had lived at a company that went through a Chromium transition.

Greg: Uh-huh.

Chris: Largely, it was presented to the world as a very positive thing. Could you imagine being at Blazilla and deciding that we're also going to make that transition? Do you see a company like Blazilla going Chromium?

Greg: Oh, goodness, gracious.

Chris: [Laughter]

Greg: I appreciate this question. You know what? I can and I actually feel like we could use another hour because I actually don't feel this is as dangerous as a lot of people, like the whole single browser engine statement.

Chris: You heard it here first, Greg. Blazilla is going Chromium.

Greg: No! No, no, no, no, no!

Chris: [Laughter]

Greg: No. No.

Chris: Just kidding.

Greg: No, I'm saying -- yeah, I wouldn't be shocked just because -- and you know what's funny? David Storey, I'll give him a shoutout -- when we went to the new Edge and we focused on interop and not Chromium, when we started focusing on interop and doing all the WebKit stuff, he was like, "We're going to move to Chromium in a few years." I was like, "What?! No, we're not." He's like, "No, this is exactly how Opera went. The second that you're implementing somebody else's properties, it's the beginning of the end."

Dave: [Laughter]

Greg: Sure enough, he was right. You end up having to spend so much time treading water that you want to advocate for Web developers and make innovations. Firefox and Mozilla still is -- or Blazilla, as you say, still is. But yeah, with all the layoffs and the momentum, and then you drop in Microsoft into Chromium, the speed at which things are going to move is just going to exponentially increase.

Again, I would love to have another discussion on the whole browser engine, "Is that harmful for the Web?" thing because I can easily come back from my Edge HTML days and make arguments that it is important to have diversity and a willingness to, downstream, implement in a different way.

Chris: Yeah.

Greg: But that's a whole other hour, and I don't want to take up your time.

Chris: I love those conversations, too, but I'm afraid the ShopTalk audience is only subjected to that once every couple of months.

Greg: [Laughter]

Dave: Yeah. We'll have to take it to the blogs this time, Greg. Thanks so much for coming on the show. For people who aren't following you and giving you money, how can they do that?

Greg: Giving me money, give it to a charity of your choice. I don't know if ShopTalk has one. By all means, link to one. Then Twitter is @GregWhitsorth. GitHub is @GregWhitsorth. Then, yeah, Open UI is @OpenUICG on Twitter.

Dave: Awesome. Well, thank you so much.

Thank you, dear listener, for downloading this in your podcatcher of choice. Hopefully, you're energized about the potential to style select elements.

If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

Chris, do you got anything else you'd like to say?

Chris: Open select, go to ShopTalkshow.com.