Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--kids are at home--Rupert and with me is Chris--comfortable in a little, tiny sound booth-Coyier. [Laughter]

Chris Coyier: Yeah.

Dave: Hey, Chris.

Chris: Yeah, that's me. It's funny to be in the booth because I've been spending so much time at my desk getting it set up for good audio and stuff too, which is so funny because I have this booth. But sometimes it's nice to just stay at your own desk when you record something.

Dave: Sorry. You had a poster, a blog, or tweets. You were like, "When I want to sound really good, I talk from here. And when I want to sound really good…."

Chris: [Laughter]

Dave: I thought that was pretty -- pretty cool.

Chris: Yeah, I just am lucky in that way. But you know it's like at home, we're organizing the closets. The virus has us doing all these home projects that otherwise wouldn't get done. It's happening in my work environment too, you know, getting it all set up beautifully.

Anyway, that's neither here nor there. We're going to end up talking about browsers, the standards process, the Web, future things and past things, and all kinds of interesting stuff because we have an awesome guest who I can't believe hasn't been on the show before, but I believe is the first time -- Brian Kardell. Hey, Brian.

Brian Kardell: Hey. How you doing? I think this is my first time, actually. I am also fascinated by that. I thought I had been out, but I think I haven't, actually.

Chris: Well, it won't be the last time because the most interesting things of the Web tend to follow you around or maybe you follow them around or something. [Laughter]

Brian: [Laughter]

Chris: You're always at the lead of some interesting stuff happening.

Brian: I'm interested in a lot.

Chris: Yeah, well, that's great. Maybe this will be a point where we can end up talking about lots of things, future and past. I certainly linked to it because it ended up being kind of the home base URL for everyone recently talking about container queries again. Your blog post was called Toward Responsive Elements, and it was just exciting because it was the first time in a long time anybody involved with browsers at all signaled any kind of possibility that anything at all was going to happen with this. It was just like… [loud gasp] "What?! Yay!" You know? It doesn't even matter what it was. Any interest at all was exciting, so maybe we could talk about that first just because it's still exciting, if you ask me.

00:02:57

Brian: Yeah, sure. It's actually a thing that I want to talk about more this year, in general, that there's a lot that happens. There's too much that happens in the Web platform in standards and everything. It's like this huge firehose.

Different people are having conversations at different levels. It's not that there has been no conversation. There's been lots of conversation. The conversation never stops.

Chris: Oh, specifically about this one or just about everything browser related?

Brian: I mean about everything, but there's always somebody trying to advance some conversation about some aspect of container queries. When is the appropriate time to introduce what ideas and how much have you figured out? Yeah, I would say last year, when I came to work at Igalia, this is one of the things that I was really interested in pursuing, so I pursued with people in the community and with my fellow Igalians and outreach to people on Chromium, WebKit, and Firefox.

Chris: Cool, so you put yourself at the center of this container queries conversation, in some part because of your job but also probably your proclivities of being interested in this kind of thing.

Brian: Definitely yes.

Chris: Mm-hmm. I think a lot of people have it in their minds what they think container queries are or maybe there are listeners who just have no idea what we're talking about. As a little prequel to this I'll say, this is so hot because, if you ask people who write a lot of CSS, "What's the number one thing you want in CSS?" you're probably going to get this as the answer, especially in aggregate. If you ask lots of people, this will end up being the number one thing.

What it is, what we have is this tool called Media Queries, which swept the nation--not even the nation--or the dang world. Everybody uses the crap out of Media Queries for doing different things to a webpage based on different things. Probably the number one most used--in fact, I would be a million dollars on this--is the width of the browser window. When the browser window is at this width then apply this special set of CSS, which unlocked this whole world of building websites in a responsive way. But it turns out, now, years later, you know what would be also really cool is if it wasn't just the browser width that I could ask for. I could ask for the width of any container within that. Did I characterize that okay?

Brian: I think you did. In my experience, it is a near-universal reaction that when somebody learns responsive design and they learn Media Queries, you learn with something simple that is inevitably based on the browser window because that makes sense. But within--I don't know--a day or two days, you say, "Okay, now wait? How do I adjust this so that it's about the thing that it's inside of, not the whole browser window?" Everybody asks that question. In my experience, it's the natural next question. The answer is you can't.

Chris: Right.

Brian: That's kind of terrible.

Chris: You really just can't. You know? Unless you just do really weird things like tell JavaScript to measure the container, do a little logic in your JavaScript that says, "If this then that; if this then that," and what it does then is perhaps adds a class or something that says, "This element is small." [Laughter] Then writes some CSS for that. But we all know that observing the size of a container in JavaScript not only is a bit cumbersome but can be slow and a performance hog and stuff. Just not where we'd expect to be doing that type of technology work.

00:07:15

Brian: Yeah, and it also was previously impossible. Part of the challenge here is that you can sit down and write what you want but the complexity underneath that is phenomenal. If you've ever watched Florian's talk on CSS text, line breaking, and line wrapping, he has a 45-minute talk and it's just barely scratching the surface of that. To us, text is just magic, right? You don't think about the years of development, spec work, testing, and interoperability that went into that. What's not evident is the amount of magic that you need to create to make container queries where it's really, really, really hard.

Chris: [Laughter] I see, so it's one thing for us to say, "Hey, come on. Just build it. We want it. It's so obvious. Just build it." But, really, it's designing and it's on par with designing an aircraft. [Laughter] You know it's very complex.

Brian: Right.

Chris: Yeah.

Brian: Yes, it is like solving one of the world's great problems.

[Laughter]

Chris: Right.

Brian: It's very difficult.

Chris: Not everything is this way, right? There are things that can happen in CSS, HTML, and JavaScript that are a little bit just like everything is hard, right, but there are different levels of hard. This one just happens to be at the upper echelons of difficult.

Brian: Absolutely. Yeah. Like any engineering, there are all kinds of problems. I think most people have had this experience where you go in with a client and you're doing work with them. They see something develop in prototypes. It's like boom-boom-boom-boom-boom, really fast. Then they ask for this thing that seems really small and you're like, "That's actually really hard." [Laughter]

Chris: [Laughter]

Brian: That's going to take a while. It's really hard to explain why that is but then they can ask for something that they think is really complicated. You say, "Oh, yeah, that's actually really easy." It's definitely like that. There are all kinds of scale of things. There are things that can happen really quickly and things that are actually really difficult. Just like other software projects, what we try to do with the really difficult things is break them down into smaller, achievable steps.

00:09:39

Dave: Yeah. I was going to say, I feel like your container query post, which I think it's great to finally -- maybe we need to explain what Igalia does, but to have browser people start kind of chiming in. Before it was just kind of JavaScript authors, library authors, and things like that. Now it's browser folks and your company, I guess, would fall into that sphere.

Brian: Mm-hmm.

Dave: Starting to chime in and you kind of said in your post, this is a big problem and it has a lot of weird -- the recursive logic thing of container queries is a big issue. But what you kind of said was, "Hey, we could probably get this switch statement, basically, developed very cheaply." I'd be curious how you got to that conclusion or even, what is the feasibility? Are people interested in that? Then, beyond that, there was also a Firefox proposal recently too, which is kind of in this same spectrum.

Brian: In the past--I don't know--nine months, there have been a hundred different ideas thrown around, history reviewed, looked at, and dead-ends followed, and looking at where you could split the problem. One of the things that we were able to do two years ago, roughly, was say, "Okay, look. People are trying to do this with JavaScript. There is no real way to do this with JavaScript because there's nothing that lets you observe a box and we don't know how we'll solve all of the circularity problems but there are some basic ones that definitely need to be solved, so we need an algorithm for that and we need the internal machinery. That led to spec'ing resize observer and that got implemented really, really quickly and iterated really quickly because we got things wrong, actually, when Chrome did it originally.

Chris: That's a JavaScript API for watching a box. It's related here and, certainly, when that dropped, there was some talk like a little bit of hand-rubbing like, "We did it! Just use JavaScript now!" But it's still cool, though, not to be a bummer about resize observer. It's a great API or at least it is now, right? Would you say that? [Laughter]

Brian: I think it is really great that we have it because each of these steps can take a year or two years. The hardest thing is not being able to move at all. We can give developers a way to do the thing that they couldn't do before. They can do it with a lot more surety than they could before and a lot more efficiently. They can help figure out some of the harder problems that deal with recursion, circularity, and designs.

Yeah, I mean that's actually a big part of my sort of like ethos about standards is that the economics of standards for developers is kind of broken. You can't sit and discuss things for ten years. You have stuff to do, right? A much easier thing is, "Here is a thing that makes it easier for us to discuss and maybe give you some real value in your real job right now." If you have a container queries problem right now, that at least helps you address it.

It's not the ultimate solution but it helps us get to the ultimate solution because one of the things that you can do is show us the use cases, which is very difficult because so many things aren't even used for what they were created for. Radio, telegraph, and everything that is invented winds up being useful for so much more than we imagined it for. Once you get the powers out there and we see what people are doing with it, that really helps inform other things as well.

Dave: Like Edison. Did Edison invent the radio or whatever? [Laughter] I don't know. Let's say he did. He wasn't like, "And then people will use this to look at babies inside mothers' tummies." You know? That wasn't on the spectrum of, like, "Here's what I'll do. I'll use sound to look at babies."

Brian: Yeah. Not only that, but even further than that. We invented the phonograph thinking that people would record their voice and mail it via the mail to someone else.

Dave: Yeah.

Brian: We created the telephone thinking that people would attend operas and things via their telephone. [Laughter]

Dave: Oh, yes.

Brian: It's amazing, actually.

Dave: Big, big songs, yeah.

Brian: Yeah.

Dave: Yeah, no, I think it's just -- yeah, the use cases I can think of right now are just very minor compared to what would actually happen if we got something like this in the browser.

00:14:42

Brian: I think I might have actually sidestepped Chris's question there. I apologize. I think that the question about how we got to the switch thing.

Chris: Well, we jumped ahead. I'm interested in the switch thing, but you're kind of saying resize observer was a step in the right direction. What we're talking about now isn't what a lot of developers, perhaps myself included, imagine the final state of container queries look like but there's been another step. What is that step? That's the switch stuff?

Brian: Right. Right. The question is, what are the next steps? The next steps really have to do with figuring out how we don't have to re-architecture all of CSS in a way that is somehow also backward compatible with everything, [laughter] which is sort of demanded by a lot of solutions right now. There's sort of a decision -- not a decision but an agreement that finding where this sort of naturally slots into the architecture makes a lot of sense, and so in discussions.

There were a lot of discussions about things that people had tried and where they fit. Other people have come up with something similar to this. I think Martin Ohlschwager (phonetic) has a thing that is sort of similar to this in userspace, but the idea is that you have the selector matching phase and then you have the layout phase. You have painting of all these individual stages and the place where you want this to happen internally--forget about how we write it for a minute--where it needs to happen is right at the layout phase. Right? When we're figuring out those boxes, that's when we need to do the work and we need to do it without somehow recomputing the universe. That most naturally fits into the individual properties.

The idea with the switch statement or the switch function is, if we could express it that way, that might be useful as a small thing. You could do a whole bunch of cases. You could pre-processor to pretty and sugar it up to do more complex things. But if we could figure that out, if we could do some prototyping on that, if we can make ourselves feel good that that's the internal solution, then we're talking about higher-level things after that that ultimately just map to that.

Chris: Okay. Okay.

Brian: Does it make sense?

Chris: Yeah, the layout step. People that work in performance and stuff probably watch for that. Everybody probably has a little bit of familiarity, right?

What was that show--Aimee-something--Dave? I'm so sorry, Aimee. She did this research looking into the different parts of how the browser renders things. But layout is one of those steps and you can even see it in dev tools, right? When the re-layout happens, that's a step that the browser does. Yeah? That's the kind of moment--

Dave: Aimee Knight?

Chris: Yeah.

Dave: It was Aimee Knight, Episode 306, April 10, 2018.

Chris: [Laughter]

Brian: I think that Eric Portis actually has a really great talk where he illustrates this. I don't know. Maybe I can provide it for you for the show notes or something.

00:18:29

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Jetpack. Jetpack is a plugin for your self-hosted WordPress site. I have a bunch of self-hosted WordPress sites, sites like CSS-Tricks, and I think it's probably the most important plugin that I run.

It's not a plugin that just does one little thing. Jetpack is like this huge feature set and each one of those features is super useful. Huge things like it backs up the site. You can back it up in real-time - incredible.

It'll warn you when your site goes down. It'll block spam from your comments, which is incredible. CSS-Tricks probably gets ten times more spam comments than regular comments and, largely, I don't see it at all.

It'll update your plugins. It'll add security features like people trying to brute force log into your website. It'll allow you to log in easier because it allows you some single-sign-on stuff from WordPress.com. That's the first tab of features from Jetpack, which is amazing.

I think image performance is a super big deal on websites. I just use Jetpack raw for images on CSS-Tricks even though I'm an image nerd and want to do the best that I possibly can. WordPress does such a good job anyway. It does responsive images naturally. You flip on the site accelerator feature and then they are CDN-hosted too. Then you flip on lazy loading and you get that too, even in browsers that don't support native lazy loading. Incredible image handling just by toggling on a few tabs, which is amazing.

Their instant search feature, which is just launching, they already have a really good thing that you just flip it on and your search gets way better, which I use on CSS-Tricks, and I'll be using this instant search feature, which just takes that feature set and makes it even awesomer. A full-page search experience with all kinds of filter toggles and stuff like that. It's going to be awesome.

Now I've covered the first two tabs of Jetpack and there are four tabs to go, so I'm going to stop there for now. Jetpack for WordPress is awesome.

[Banjo music stops]

00:20:44

Chris: Why is this syntax so good? By this syntax, maybe I'll attempt to radio explain it a little bit. Let's say you wanted to set -- I don't know -- in your post, you used grid template columns, which is a very relatable property we would use in CSS that we'd want to change at different widths not only of the browser. We're not talking about the browser width. We're talking about the width of itself, the width of a container itself.

You'd say, "Hey, when this thing is real wide, when this container is real wide, I want it to be like a three-column layout with a special stuff. When it's a bit narrower than that, I want it bumped down to a two-column layout with the special situation. When it's real narrow, the typical phone kind of situation, I want it bumped down to a one-column layout." That's exactly the kind of thing we want to do with container queries.

There's a syntax in your post here, which it's very far from final, I assume, but it's the kind of thing that has browser vendors -- and I don't know. Who is saying yes to this? Who is saying, "Hmm…"?

Brian: Well, I don't know that anybody is saying yes to it.

Chris: [Laughter] Yeah.

Brian: [Laughter] But yes is a very final end of the road kind of thing.

Chris: Or not saying, "That looks scary."

Brian: Yeah, so actually--

Chris: Did I get that syntax right as well, that switch statement? Is that characterized correctly?

Brian: Yeah.

Chris: Yeah, okay.

Brian: Yeah, I think you characterized it very well. Actually, in a lot of conversations that came out, we were sort of beating around this idea, not the syntax or anything but the idea of where to slop it in actually was brought up by Ian Kilpatrick from Google who is kind of brilliant, in my opinion. We ran this around a whole bunch of people at CSS Working Group, people from Apple, Mozilla, Microsoft, and just other participants. Everybody was … (indiscernible) that this seems like really interesting to pursue but it's not the only idea. There are actually -- David has a whole stack of ideas.

Chris: Okay. Okay.

Dave: David Baron from--

Brian: Yes, David Baron from Mozilla.

Dave: --from Mozilla.

Brian: Yeah.

Dave: That's cool.

Brian: Actually, we had come up with a different idea altogether, which might still be interesting or useful. But I think that this is probably one of the two that is going to get some traction. I think I have some peers at Igalia--

Chris: That's pretty cool.

Brian: --who are just beginning to maybe dig into some code and experiment to flesh it out a little bit.

Chris: This is at the property level of CSS. When you're trying to declare a property, you have this opportunity to ask how wide the parent is. Parent is probably not the right word, but container. Then make that property have a value that's based on that size. It's pretty great. I think that probably solves a lot of what people are asking for.

Syntax-wise, I could see people being like, "That's a little weird," or, like, "Why is this so different than having it just be an at command kind of thing?" Whatever. At some point, you've got to just be like, "I don't care. You do you. I just want to be able to do this."

Brian: Right.

[Laughter]

00:24:25

Brian: Everybody wants to be able to get to the higher-level thing. I think the challenge here is to focus the conversation on where the problems are and where there are concrete steps and concrete things we can solidify to make those higher-level things more achievable. The history of the high-level things that everybody thinks is also usually not entirely correct. Things take way longer than we imagine them, the high-level things for the most part.

Dave: Why do you think that is? Is there a reason? [Laughter] I think we kind of talked. The main element took like ten years and it's a spicy div.

Brian: [Laughter]

Dave: Then there's that sort of kerfuffle, I guess, last summer with the standard Toast that Google, really, they were just intent to prototype but I think the whole world or a lot of the Web standard-istos and -istas kind of just sort of reacted like, "Whoa! What are you doing?" [Laughter] It seems like they were on a two-week flight path for an element versus a ten-year. I guess, what is your idea? What is your feeling? Why do elements, like high-level things, take so long? I think I know the answer to this as well, but how do we make that better? How do we make it not ten years?

Brian: Main is a particularly terrible example that even I throw out as just an extreme thing.

Dave: I mean it could be progress, meter, or details, dialog, help.

Brian: Details is a great example, actually. We got the last implementation of details basically last month or something like that when we switched to Chrome-y Edge. Input type color, we only got the last implementation up last year. There are still things that are rolling in from HTML 5, which a lot of people declared done a long time ago.

The reason that it is complicated is because you have to run multiple gauntlets. You have to run the "What is a reasonable discussion?" gauntlet, which is sometimes different because people have even different perspectives about the sort of role of the Web and what it should play. Apple and Google, for example, have different perspectives on some of this. There are people who are not even browser vendors who have strong opinions in other directions as well.

There's the conversation part, but then a big thing that plays into that is, what do you have right now? We have three different rendering engines that have taken, basically, 30 years to be created. They're very, very complicated things. There are things that we know that are wrong with them today and big efforts to help us escape those bounds like multi-year or multi-million dollar efforts to make your browser parallelizable, be able to take advantage of multi-cores, include new things, to be able to do things like regions and exclusions and all of the print use cases that we have never been able to take up. You have this software today and, when these asks come in, everybody has to consider what is the possibility that we can get there and is this a priority now. It's competing for everything else.

Then the other aspect of that is, once you actually agree, then people actually need to prioritize it. Everybody has different budgets and different constraints. An example of that I like to give is, if you're a user of an app and you have some problem with internationalization, then you see that app update this whole new, shiny UI with all this new skinning and everything but your internationalization problem isn't solved, your immediate reaction as a user is, like, "They think that--"

Chris: Come on!

Brian: Right, "They think that that is more important than the other thing." In reality, maybe what you don't know is that the designers finished up another project early and they had some cycles but the internationalization people all got the flu or something, right? There are practical things and smaller things that you can actually accomplish that are easier to prioritize, just like in any other software project.

00:29:36

Dave: I think I heard a talk by Mike Taylor from Mozilla. He was talking about window.event, which is a thing in old IE that made its way into Conquer or that made its way into WebKit that made its way into Chrome and everywhere but Firefox because it was not a standard API. Basically, window.event is whatever the last event that showed up was, or whatever - whatever the current working event is.

They implemented it in Firefox and then it takes months. They run tests and they kind of fly it through betas and things. This is for not a new thing. This is for an old thing that's already on every website. Then they ship it out and Jira goes down or something like that.

Brian: Yeah.

Dave: They were like, "Oh, no!"

Brian: Yeah.

Dave: "What happened?" There was some code somewhere in Confluence or Jira or something, some WYSIWYG that just bit the dust when Firefox had window.event.

Chris: Oh, gosh.

Dave: There's code in Firefox now that's like, "If you go to--" like, "Don't have window.event on Confluence," or whatever. [Laughter]

Chris: Oh, on one URL? Oh, god!

Dave: Well, there's like a handful, I think. It's like feature flagging on something. They're doing this for backward compatibility, like for non-spec stuff, but it was hard to get a non-spec thing out.

Brian: It's very, very hard. The platform is full of all of these legacy works and decisions that we can't take back easily. Then there are other things that become de facto standards.

Here's a good story. The JavaScript specification from way-way back said that the iteration order of things is undefined. It doesn't matter. It's, "Here is a bag and any way that you iterate it is fine."

Java had a similar thing with this with their hash maps back in the day where that's what the spec said, "It's not guaranteed. There's no predictable iteration order." But in fact, everybody implemented approximately the exact same thing, which was that there was a stable iteration order that was like insertion order. Whatever order the keys were inserted, that's the way it would iterate.

Someone, I think it was Opera, it might have been Google when they were redoing JavaScript engine things said, "Well, you know, we can do this thing and really speed up performance and follow the spec and not copy that. That that can't be important is not in the spec," but then stuff like Gmail broke because people come to rely on that behavior.

Chris: Wow. Yeah.

Dave: You're not just up against whatever browser is all getting together. You're up against past behavior and adoption. Right? There's the whole thing like we have to rename pieces of JavaScript because of new tools.

Brian: Exactly.

Dave: It's not that easy. That's kind of part of the gauntlet stuff you're talking about.

00:32:57

Brian: Yep. Yep, and so just those kinds of challenges are really challenging. I think the thing that I'm really trying to talk about a lot this year is to explain to people that really, ultimately, so much of this is impacted either just directly or down the line with what we're open to discuss right now has to do with, can we get this prioritized? What is the likelihood that we can actually get this prioritized?

For most of the Web -- well, for the Web's first 15 years, basically, the Web was dominated by proprietary engines. Historically, all of the decisions have been made by the people funding those engines. But that is completely reversed now. Everything, all of the engines are open-source.

Igalia, the company that I work for, the reason I came to work here, actually, is because we expand that by allowing other people to put dollars in implementation priority toward things.

Chris: Mm-hmm.

Brian: We can remove that aspect in a really big way. Right? I mean that doesn't mean you can just do whatever, but it means that all of the pressures that come with the prioritization problem are lifted and expanded. I think that's really cool.

Chris: If the world was still all proprietary browsers like in-house, not open-source, Igalia wouldn't exist, right?

Brian: Right.

Chris: Because it's irrelevant in that world.

Brian: Yeah, you're right. Yeah.

Dave: I think it's probably worth saying. Igalia, in my mind, is sort of this A-Team for hire. [Laughter] You'll paratroop into any hot zone and fight some battle that a normal browser is like, "We don't have--" or I guess one of the big vendors doesn't have the time or expertise, I guess, to build out. Igalia will work on Firefox features, WebKit features, Chrome features. It kind of spans the whole spectrum. Is that right?

Brian: Yes. Yes, we work on all of the JavaScript engines and all of the rendering engines.

Dave: Then your clients end up being like Amp or something - everyone's favorite framework.

00:35:22

Brian: Our clients are really, really diverse. We have contracts with all of the browsers and multiple properties. Also, if you go to WebKit.org/download, three of the browsers on that page are actually maintained by Igalia, not Apple. We're closer partners in that as well and we do that. Those are for, like, Linux and embedded systems. The embedded systems work is phenomenally interesting. The new things that it enables you to think about and prioritize are pressures in standardization that the Web has never had and they're really good.

Have you seen the thing about hardware-accelerated SVG?

Chris: No!

Dave: I've only heard, but I don't know anything about it. I assumed it was already somewhat hardware-accelerated.

Brian: It is not.

Dave: …device, but it is not. Wow!

Brian: I actually have a podcast thing that I do called Igalia Chats. I have a thing that will be on that. I hope you both listen to it. It is about how we wind up there and that Igalia is actually leading the charge in making that happen, which is a thing that, for example, Sarah Drasner has been on for a long time, like, we need to get these things hardware accelerated, so I think it's very cool.

Chris: Ooh! Yeah.

Dave: Wow.

Chris: I look forward to that as an SVG lever.

00:36:58

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by AWS Amplify. You know AWS, right? Amazon Web Services powers most of the Internet, it feels like.

There are a ton of things that go in the AWS bucket like EC2 allows you to spin up servers of your choice and has all kinds of configuration. S3 is for file storage and Lambdas is for running cloud functions - all kinds of stuff that, individually, you can set up, use, and are great. But there's so much more than that. There are a ton of different things AWS does.

AWS Amplify is kind of a package of tools to help you build full-stack apps for the Web. It's like--I don't know--just give me the stuff that I need that usually you need to build an app. Amplify is hosting. You need Web hosting? It's got that. It's got authentication for logins for your users. It's got GraphQL as a first-class citizen of it.

It's got serverless functions like I need the Lambda thing. I want to run some code in the cloud to hit APIs and do whatever else I need to. And it's got file storage if you need it. It's got some machine learning stuff in there if you need it.

Amplify is this easy to use, full-stack framework for getting started quick with building Web apps. It's really cool. The auth stuff alone is cool. It's just a few lines of code in there.

GraphQL has taken over the world of how to get things from a database, put things back in a database. Really front-end development-friendly way to do database stuff. Love GraphQL. It's just built-in as a first-class citizen. It's this scalable API. You don't have to provision your own servers. It just does it up for you - pretty cool.

AWS Amplify is really cool. Definitely worth checking out, especially as a front-end developer, so check all that out.

[Banjo music ends]

00:38:53

Dave: I'm looking at a WebKit status board and they have supported and preview, things that are coming out in the next one. There's resize observer, which I think you all worked on, right?

Brian: We did. Yes.

Dave: Then visual viewport API, did you work on that?

Brian: Uh… I don't know.

Dave: It seems connected to resize observer, which is why I was wondering. But anyway, those are the only two things [laughter] that are coming in Safari, apparently. But yeah, I don't think I knew that Igalia A) existed for quite a while but it's cool to see this idea of, well, here's kind of an independent, non-Google, Microsoft company that could potentially be hired to implement a feature, which leads me to my next question. How much is it going to cost Dave Rupert LLC to get container queries?

Chris: [Laughter] Let's get there in a minute, but can we cap off this container query because Dave's joking, but he's kind of not really joking? It looks like there's a world in which that type of thing is going to be experimented with.

Dave: I've been saving up all my ShopTalk bucks, thank you.

Chris: I know. I'm thinking a few hundred bucks is going to go a long way because we talked about running multiple gauntlets. I want to just cap off the container queries thing with that.

Brian's post talked about resize observer. That was a whole thing. It took a year or two to get in or something. That was pretty good, actually. Now, hey, maybe we'll get some kind of switch statement, which I think the world would rejoice for. That first gauntlet to run was the conversation gauntlet to make sure people are involved and talking because I would imagine if you jumped to the next thing, which is probably some attempt at spec'ing maybe or implementation even that, if you skip the talking phase, people would be like, "Uh… What?!" [Laughter]

Brian: Oh, yeah. Yeah.

Chris: Yeah, right?

Brian: There's nothing that will kill an idea faster than somebody--

Chris: Having not talked about it?

Brian: That then having somebody sort of convey somehow that it is further along than it is, which is actually really challenging. I think the thing that Dave was talking about, about the high-level proposal that Google did with switch and Toast and what killed that, a lot of that was killed by effectively messaging, which is a shame because, honestly, the interesting part about what they proposed had very little to do with either of those elements and a lot more to do with the stack of vision, discussion, and proposals that came with it that unfortunately didn't get discussed very much because--

Dave: Yeah, there was a cool -- it was three things, right? Like new elements. But then there was this idea of, like, let's ship a Web component first and then it gets standardized. Then there was another idea of, like, let's do Web components but already embedded in the browser, and there's a standard library of elements inside the computer, inside the browser. But all those things happened all at once, and I think it was a shock.

Brian: Yeah, I mean I think that was the really interesting thing there because we haven't had new elements in a long time. We have but not the kind that gets everybody excited.

The thing that's interesting there is that the way that we got to HTML 5 because, if you recall, the Web was stuck because 95% of it was IE and, even when Safari came along or when WebKit first came alone, it had just the tiniest percent of users. If you were working on websites, you were like, "Oh, that HTML 5 thing is cool but is it worth me doing something for one percent of my users?" It was a really hard challenge, like a chicken and egg problem.

Polyfills really helped us. Developers helped incentivize that game and got us out of that bind. The thing is that polyfilling elements in what I call sort of like the first year of polyfilling, that was a terrible experience because you're not polyfilling. It's basically a library, right? You have to take your DOM and transform it into something completely other thing.

Then what do you do? You have to reason about two different sets of CSS selectors and you're better off just always using a library and then sort of what is the point?

There were a whole lot of questions raised back then about how we go digging ourselves out of this problem. Google's proposal included things like, well, what if we just removed--? What if we just said that basically HTML itself is done and then we have these extension specs? We can serve those in a way that they can be progressively enhanced so that you get parity. You could actually polyfill elements more or less. But we could ship those same implementation in the browser, which is just really an interesting set of ideas that I would really have liked to see discussed more, but Toast, so -- [Laughter]

Dave: [Laughter]

Brian: Yeah.

Chris: Yeah, and that was tricky. I'm sure there were just piles and piles of nuance to all of that but, to some regard, I would defend the people who cried foul a little bit in saying I'm glad there are still watchdogs out there. If nobody yells, then it's dangerous.

00:44:49

Brian: Yeah, I don't fault anybody for having that reaction. It should have been messaged more carefully and there were some pretty obvious things like that the intents are dramatically misunderstood what they were supposed to be, what they're supposed to mean. Yeah, it's not to blame any particular person or people. It's just unfortunate--

Chris: Yeah.

Brian: --that we got distracted by something that wasn't really the cool thing, right?

Dave: Well, yeah, there are so many -- I don't know. It comes down to the people problems. That's, I guess, why the gauntlet is hard. There are a lot of people involved, especially as a thing matures. I can build a thing myself and it works great. But then I invite non-sited people to use it and it doesn't work so great. [Laughter] As my exposure grows and it becomes more official-official, more opinions jump in and could crash the velocity of it.

Brian: Oh, yeah. There's just an increasing number of things we need to consider, especially when you talk about Web standards because you're sort of dictating things in many different architectures for historically very few people. Do you know what I mean?

Dave: Mm-hmm.

Brian: Historically, very few groups of people would have to prioritize and get the work done. That also made it really challenging.

Chris: Yeah, okay. I think that's about good on that. There are these gauntlets to run and talking about it, standardizing it, implementing it, and all that. It's complicated and there are different companies involved and priorities that have to be prioritized and stuff. That leads us to -- that gives just another reason Igalia is interesting is that your priority levels don't have to match any other company's priority levels. These browser engines are open-source. All of them are now and, presumably, they're at least a little amicable to taking outside contributions. They obviously are, right, because you've implemented all kinds of stuff.

00:47:06

Brian: Yeah. We have, actually, great relationships with all of them. They are very open and want other people to contribute and people do.

Chris: If Firefox is busy on something else because -- well, we all know Firefox right now is on this massive privacy kick. Every message out of that company right now is, like, "We'll save you from the horribleness of the Web." Maybe they're a little bit more worried about working on stuff like that than they are working on some new color functions.

Maybe just ain't nobody got time for new color functions over at Mozilla right now. I have no idea if that's actually true, but let's say it is. That's okay because you could if you really cared or I really cared or Dave Rupert LLC really cared, could get involved and get these new color functions going, whatever they are.

Brian: Yeah, that's right. In that particular example, there's another aspect of that that is worth pointing out, which is that those are different people that work for Mozilla, right? By and large, the people who would be implementing color functions are probably not the people who are working on security features.

Chris: Yeah, fair enough. Right. It's not always the same people. It's often not or never is, maybe. [Laughter]

Brian: Yep.

Dave: It feels like to me, though, the existence of Igalia is it sort of takes the -- I always think of, like, person-hours, you know, for a browser per quarter or something and then that's when I get a new feature, once a quarter or something. It seems like a very fixed asset. But Igalia, this idea of, like, well, there's this company that could just -- you know, based on the number of dollars that go in, they could scale up and find enough C developers to implement features or whatever.

It's just interesting. It relieves a little bit of, like, this constraint for me to know independent companies can kind of start building and contributing features into browsers, especially because they're not closed source anymore, so that would be way harder to get an NDA from Microsoft to go work on Edge or whatever - Trident. You know?

Chris: Right.

00:49:22

Brian: Yeah. I think it's very, very cool and I'm interested in continuing to expand this as much as we can. We're actually going to do a sort of crowdfunding-based prioritization experience.

Chris: What?! All right! Here we go! Here's the thing. Let's talk about the thing. Let's say there's Patreon for browser features, right? How do you want to talk about that?

Brian: Yes.

Chris: That seems like a thing that could and probably will happen at some point.

Brian: Yeah. No, it's definitely going to happen. The particular platform, we're still working out a few things, but the basic idea is, for this experiment we're going to focus on achievable things that are uncontroversial. We're not going to get container queries in this experiment.

One of the things that we will probably offer is some work on one of the proposals like implementation experimentation work and maybe some spec'ing kind of stuff. But you'll see that the rest of them are concrete things that have a definite, you're going to see some actual real value in the browser.

For example, one of the things, like you mentioned, is color functions. WebKit is working on the color functions and Chrome began to work on color functions. If we can close up the Firefox one, then all browsers will have that very soon. That's a concrete thing that you can say, "If we invest in that, we'll get that." That has a finite time. We kind of understand the time scale and everything. But if we say, "Or we take that same amount of money and invest it in maybe experimenting for proof in this thing that might still not happen," it's a little bit harder for people to want to invest in that, right?

The idea is, we will lay out a whole bunch of uncontroversial things that are in a couple of buckets of sizes and then it will be sort of a race to fund, right? One of these will fund and that's the one we're going to do.

Chris: Okay. Okay, I didn't realize it was like that. It's like a--I don't know--vote. Like you put a dollar in the bucket for the prize and the one with the most dollars in the bucket wins the thing that you're going to do next.

Brian: I think what's interesting about that is that that is how prioritization works, right? You have a fixed number. You can only do one. You have to pick one. Which is the one? That's part of the purpose of this small experiment.

Also, it's not that we can't do any more of these. We certainly can. If a single company wanted to work with us, that is what we do today, a lot of what we do today. Definitely, come talk to us.

If this is successful then we'll do more. The challenge is, how much bandwidth do we keep available to work on the thing? Currently, we have bandwidth available for one of these experiments. That is, again, the prioritization problem. Yeah, I think it could be interesting.

Dave: No, I think it's cool. I think one example we said in DMs or something was math ML or math Markup, which is maybe something you're already working on. Apparently, you were saying it's in every browser but it was ripped out of Chrome at some point, like on the big Blink fork, just because it was kind of a mess or whatever.

Dave Rupert does not care about math. I don't want to put my dollars on math. [Laughter] But MIT, probably super does or now that kids all go to school online now, maybe math on the Web should get priority. Maybe there's way more interest in expressing math in HTML.

Brian: Yep.

Dave: You know. Not to be super capitalist about it but, in some ways, you can be like, "This is actually important to us. I want to put money behind it." At least get an implementation in this one browser that is missing or something.

Then you all, because you're more, I guess, experienced. Dave Rupert, I can fork Blink. I know how to do that but I'm not able to surf the browser process fluidly. That would be a nightmare. I think you all are way more equipped to do that and it would be way worth my--whatever--ShopTalk bucks to chip into something in a big effort, you know.

00:54:34

Brian: Yeah. Yeah. Yeah, we are doing that with math. I have several blog posts about that on my blog, you can go read. I won't take a bunch of time with that. Also, I did one of those Igalia chats on that.

I do think that that is a thing that I spent most of the history of my career being in a very similar place, like, "Well, I've never needed math in the things that I work on to share math, personally." But, at the same time, at CERN when they were making the early browsers, there was support for math because there were two things that were really, really obvious that were needed. One was graphics like vector graphics, and the other was math.

Even back then, CERN's browser had experimental support for a math thing and it was one of the first things that was created with W3C. It's obvious that there is a need for it and it is clearly if you want to share research or you want to do learning or whatever, we say, "You don't put text in images," right? That's a well-established rule.

Math is text. It's not images. It's text. If you change your background color, you want to make sure that it changes. If you change your font color, you want to make sure that it changes. You want to make the denominator clickable, et cetera. Right?

I think those are really important, good for society, but for a lot of us maybe not immediately exciting because it doesn't help us get container queries or--I don't know--better high-def color or something.

Dave: Yeah, like ultra-high-def color or I, Dave Rupert, want accessibility functions.

Brian: Yes.

Dave: Like ensure contrast and stuff like that. I know figuring out color is a step towards that but then I'm looking at your blog right now and you have top-level await. That's something a lot of people want, so maybe they'd all want to chip in on that. That's kind of a cool avenue for us normies, I guess, is what I want to say. [Laughter]

Brian: Yeah, I mean I have things in this list of things. We can maybe talk about focus visible in WebKit--

Dave: Yes.

Brian: --is one that I think would be really cool. I'm biased because I helped define it.

Dave: [Laughter]

Brian: I have the same bias.

Dave: Yes.

Brian: But I think that that would be huge.

Chris: Yeah. Inert is a good one. Yeah, it is.

00:57:28

Brian: There's a selector list for not, I think is one. Containment in WebKit is probably really interesting because, if we wanted to get any of David Baron's proposals, the first thing is you need some kind of containment and WebKit doesn't have that yet. There is a grid inflex on buttons. I don't know. Maybe I can share. Maybe I can share the list of names.

Dave: A flex gap? I want flex gap.

Chris: [Laughter]

Brian: If you have ideas that you would like to talk to me about as possibilities, definitely let me know. Hit me up on Twitter, email, or whatever.

Chris: The idea is -- the point of this is that individual developers like the three of us -- maybe not you, Brian, because you work on this, so you're disqualified, but like we're--

Brian: Oh, no, no. I'm going to give some bucks to something.

Chris: Are you? Okay. [Laughter]

Dave: [Laughter] You establish an independent corporation and that corporation can--

Chris: We throw some bucks at these features and then it gets done. How satisfying is that? We're not just starring tickets anymore. We're funding it actually happening, which is so cool. Companies maybe can do this too, but at a different scale, right? If there is some really rich company out there that wants something to happen but doesn't have the expertise but they do have the money, they could participate in this too, but they'd probably have to just talk to Igalia in a different way because the point of this is not to do that, not to have one overwhelming voice come in and just say, "We want to do that." They can still do that, but that's a different part of this experiment. This is more about individual developers having a say in particular features.

Brian: Exactly. The experiment is more than one. There is a question about whether it is possible to make the more than one into a million or whether the more than one is six companies find a way to efficiently reach consensus on what is the actual important thing because that, again, doesn't happen because it's mostly in theory. You're in theory; you're talking in a working group, and so everything can be important. But then when it comes down to prioritizing, if you say, "Well, the five of us need to decide which one and then we're going to put real dollars toward getting it done," that is sort of an open question. I think that the key here is that there are millions of us developers.

Meetup.com. has, I think, 13 million people who identify just on Meetup as Web developers. We can act fast, right? We can make something happen.

Chris: Yeah. Yeah.

Brian: But companies are slow and deliberate in their decision-making, budgeting, and all that kind of stuff. That's part of the experiment is to see because I really do think that we can convince one another and that, collectively, arguing why this one and not that one is actually helpful. It's a helpful exercise.

Chris: Yeah. Let people do it with dollars and buckets. That's cool. For the record, you can't put your dollar in the container query bucket because it's too big of a bucket. It's too weird. The point of this experiment is a little more scoped down because that one is big, unknown, and vast. The rest of these ideas, it sounds like for round one, will be a little more easily actionable.

Brian: That's right.

Chris: This is not live yet nor does it have a launch date. If you're excited about this, just hold your horses and you'll hear from Brian, I'm sure, at some point when it is.

Brian: Yeah and tell me if there's something that you think fits this criteria, like a pain point that you think could be addressed that is uncontroversial. It's just lacking in some browser or something.

01:01:17

Dave: I guess I know -- I'm Googling it right now -- thewebwewant.fyi, is that what it is?

Brian: Yes, it is.

Dave: This could play into that too. You don't have to listen to me. Don't take product advice from me. But there are a lot of ideas, like, "I want this in the browser. I want this in the browser." There's a lot of demand, I guess. There are a lot of wants and grievances. I feel like this is an outlet to maybe help solve some of that.

Brian: Yep.

Dave: I like it. I sign off on it. [Laughter]

Chris: I like it. Cool.

Dave: I like it.

Chris: That's about all the time we have.

Dave: All right. Yeah, we should wrap up because we are at the time, Brian. Thank you so much for coming on the show and wowing us with your kind of browser insights. We talk about browsers a lot on the show and it's probably painful for you to listen, so I appreciate it - suffering. [Laughter]

Brian: I really love listening to the show and I think it's great. Thanks so much for having me.

Dave: It was nice to get somebody with some expertise. For those who aren't following you, watching your speed paintings, and giving you money, how can they do that?

Brian: You can follow me, @BrianKardell on Twitter is the best way. You can check out my blog, bkardell.com.

Dave: Awesome. Yep. Cool, and we'll keep an eye out for this big Kickstarter for features. Looking forward to it.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. And start saving your money because I'm going to ask you to fund focus-visible. [Laughter] Chris, do you got anything else you'd like to say?

Chris: [Loud inhale] ShopTalkShow.com.