Brian Kardell: Right. So I'm Brian Kardell. And we've been discussing things about the health of the web ecosystem. There's always this sort of wide discussion, usually when something bad happens, like we lose an engine or something. And we talk about what this means for the health of the web. But this is actually a pretty poor proxy, beyond some things that seem almost self evident. One engine is certainly too few, and probably a hundred is too many. And, beyond that, it gets into all kinds of different nuance that we don't talk about so much.So we've been talking about all those different angles, and nuance and everything from different perspectives, like how is the development work funded, and why is it funded that way? And that good or bad? Have we seen any changes? The move of everything to open source. Originally, everything was proprietary, and then became all open source. And how does that play into it?So I have some guests today that we're going to talk a little bit more about the standards themselves, and how they get made, and how the standards process works, and who's involved with that. So,
Miriam Suzanne (Mia): Hi, I'm Miriam Suzanne, and it's good to be here. Thanks, Brian.
Rachel Andrew: Hi, and I'm Rachel Andrew. And, yeah, it's an interesting discussion to be having, so it's really good to be here.
Brian Kardell: I guess let's talk about who works on standards, basically? I don't know how much people really think about or talk about that. We know Google does, right? We know apple does. And we know Mozilla does. And, at different times, we add Microsoft, and Opera, and some different players into different degrees.
Rachel Andrew: There's a lot of people working on this stuff, that I think the web development community probably aren't that aware of. So there are other user agents, as well as browsers, as well as web browsers. So we have things that output to print, for example. So there's lots of publishers who are using CSS, for example, to output books. And they're all the people in the EPUB community. They're using the same standards, and they input into them.And so that's one group of people who I think we don't necessarily think about when we talk about the ecosystem, because those things do feed in to ... If we're talking about a CSS property, for example, we might need to think about how that works with print, and how that's going to work in that kind of output. So that's a bunch of people.And then we have the people who are like myself and Miriam, who don't actually work for a browser vendor, or a publisher, kind of independent, and yet have somehow ended up involved in working on the web platform. And there's a growing number of people who are involved in that way.
Miriam Suzanne (Mia): Yeah. And, interestingly, there's also sort of ... Adobe is very involved, right? They're not a vendor, in any sense of using the specs to create some output, they're just an interested party.
Rachel Andrew: So there's an awful lot of companies and organizations who are adjacent this stuff, and use some of it, if not all of the platform. And so that's, I think, not as well understood by people who aren't involved in standards bodies.
Brian Kardell: I think that there is actually some interesting history around Adobe, and why and how they got involved. Everybody thought for a while that we were going to get the better web. The HTML web was really good for documents. But this model where you have this VM that has the ability to have windowing toolkits, and things where you write programs, but also supports documents. There were all kinds of entries into this trying to win, to control the market, by being the first one to just define it, without actually getting the standard in.And so, from that, we had XUL and XAML. And Adobe had Flex. And all of them had their own VM that worked like this. And right at the very end of this, Adobe launched their VM, and it embedded WebKit. When WebKit came out, and everyone was working on it very actively, I think that's how Adobe got involved.But, yeah, Igalia also works on a lot of embedded things. And embedded devices are everywhere. Everybody thinks about the browser you use on your desktop, and you have the browser you use on your mobile phone, but you also use a browser on your TV. You don't realize it.If you have smart appliances, they probably are running browsers. Your car infotainment system, airplane, train, digital signage, point of sales systems, you probably encounter seven other things built on web technology, that you're not even realizing are browsers. And lots of those people are increasingly also involved in standards.
Rachel Andrew: Yeah. I mean, for a couple of years, I was the W3C representative on the AC for Frontiers. And going to the meetings, the W3C meetings, you realize actually how much broader the web is than what most web developers, and what really I thought for a long time. You sort of think of, yeah, web browsers.And it's incredibly broad, the number of companies and organizations that are using web technologies these days. And that's kind of really interesting, because we don't hear a lot of those sort of stories.
Brian Kardell: Yeah. Let's talk about that, since you mentioned Frontiers. Because, over the years, the W3C ... I talk about this a lot, none of these standards bodies are fixed in their design. They're always constantly evolving.And one of the things that happened a number of years ago is things got a lot more open, and they wanted more people who can bring different points of view and expertise. And they created this invited experts. So you don't have to work for a big company to participate, and come to meetings and all that kind of stuff. So you were eventually nominated, but I think that lots of people started as invited experts.
Rachel Andrew: Yeah. So I'm now back to being an invited expert. So I eventually became a member of the CSS Working Group, as an invited expert, during the time when Grid was leading up the shipping. Because I'd done a bunch of really kind of advocacy work around Grid, and just encouraging web developers to look at the emerging spec. And then also sort of contributing a bit back to the spec, with ideas and things I'd picked up from talking to developers.And so, at that point, I was asked to become an invited expert. And what I always say to people is, if you become an invited expert to Working Group, you basically get an expensive hobby. Because you're not paid for this. And I'm a freelancer. I work on contracts. And so anytime I'm spending working on standards, I'm doing in my own time, typically. And I'm paying for going to meetings and so on. And I've been in a position I've been able to do that.And one of the things that then came about was that Frontiers wanted to join as a member organization. For people who don't know this, basically, to become a member of the W3C, typically that's a company. So that might be a company like Google, or it might be quite a small company. One of these publishers, or what have you, might be a member of the W3C. And that lets you then send people to meetings and be fully involved. So if you are a W3C member, as an organization, you need to have at least one representative who ferries information and so on.So I became that person for Frontiers. So, for a couple of years, they funded my standards activities, which was great. And I did stuff with them like spec reading workshops and so on. But the W3C is not really set up for non-corporate members so much.
Miriam Suzanne (Mia): Yeah, it's very expensive to join.
Rachel Andrew: It's very expensive. And just the whole system is very much set up for you being a representative who has got a remit of a company behind you. And you're going to bring the information from the W3C back to the company, and bring the company's interest into the W3C. It was very difficult to figure out the model for a volunteer organization, and being their member. And, of course, with the whole coronavirus thing, it meant that I couldn't do a lot of activities that I might've done in the second year of my term with them.So I'm now back to being an invited expert. They've decided not to renew their membership. But it's an interesting thing. In that whole situation, I feel like there needs to be another way to be a member almost, that enables talented people to get involved with standard processes, without having to fund it themselves. Because that means that only ...I'm in a position of privilege, that I have been able to fund my standards activities, that I've been able to have that hobby. I couldn't have done it 15 years ago or so, when my daughter was younger. There's no way I could have funded it. So I think that is something that needs discussing really.
Miriam Suzanne (Mia): Yeah. It's been interesting joining recently. I mean, I joined right when COVID started, or right before. And I can say that makes it cheaper. I don't have to pay for travel to the meetings. But downsides too, of course. But in filling out all the paperwork ... And there's a fair amount of legal, making sure that your work for the CSS Working Group is all public domain, that you don't retain any rights to the work.And a lot of the questions were around, is there any way my company could become a member? And, if so, that would have to be the path. So a lot of arguing that, no, OddBird doesn't have any particular reason to become a member, besides the fact that I've been invited to do this work. And I'm not strongly affiliated with Mozilla, or Google, or Apple, or anyone else that's already a member.
Brian Kardell: Yeah, this can get complicated as well because you ... Certainly, well, it's a special skill, if you wind up doing something somewhat specialized, like spec writing, which I would like to get to that as a topic in a little bit. Spec writing is sort of a specialized skill. But just consensus seeking, and learning the ropes of how these things work, and kind of getting good at it.And once you've been doing that for a while, everyone would hate to lose you. And that occasionally happens, where a company is involved, and then there's something like the coronavirus, and they say, 'We can't be involved anymore.' But some of those people who are really critical, we want them to remain involved. And this creates a real tricky situation paying into the membership, because that's how they fund themselves.We actually covered some of this on previous podcasts, if you want to go listen to it, with Jory and Pia, I think it was two podcasts ago, where we talked about some of the funding of the standards bodies themselves and how they operate.
Miriam Suzanne (Mia): But then we are the backdoor, right? I mean, as invited experts.
Rachel Andrew: Yeah. I mean, it's a bit of an odd situation. Because, I mean, for instance, I currently ... I mean, I say I'm a contractor. I currently work on a contract for both Mozilla and Google. In most of that work, I'm actually working on MDN, on behalf of the both companies.So I have affiliations with two browser vendors, yet I'm not on the CSS Working Group for either of those companies, and they're not paying me for any of the work that I would do there. So if I can get work that aligns with my interest in standards, then that helps. Because I feel like, 'Well, okay, so I'm doing this other work on my own time.' But at least everything I do is around the same subject. And I'm thinking about it all the time, which is great.
Miriam Suzanne (Mia): And I know that there are several of us that are getting money either through contracts, or through open funding from the browser vendors, even though we don't have a strong affiliation with them. I don't work for Google, but Google has a fund where they pay for open source work. And I do get some of my work paid for through that. And I think that's a common thing for some of the invited experts.
Brian Kardell: On that whole invited experts are the backdoor, they are kind of a backdoor, although they're a backdoor into, as Rachel said, having a very expensive hobby. Not just very expensive in terms of billable time, but to be a really good productive member of something like CSS Working Group takes substantial time.
Miriam Suzanne (Mia): Especially if you start working on specs.
Brian Kardell: Yeah, yeah. That's what I was just going to say, actually write specs, or work something through the spec process, or do the things that are involved with that, like collaborating with implementers to find out what is and isn't plausible and why, and how we fix that. That is all really, really time-consuming, and frequently operates on a timescale that is way outside of anything.
Rachel Andrew: Yeah. And I think that's why I try and work on adjacent work. So I'm working on MDN typically, so I'm documenting the web, which at least means I'm constantly thinking about this stuff, and interacting with our developers, and talking to them about it, and answering their questions.And so that kind of means that, although I'm not actually paid to be on the CSS Working Group, I'm actually thinking about this stuff all the time. So then when stuff comes up in a Working Group discussion, I don't have to go and research it, because I've probably just written the docs in MDN about it. So that kinds of helps. But I realize I've got myself into a fortunate position there, where I can balance my expensive hobby with my actual paid work, in a way where both feed into each other, which they obviously do. Where it's not so good is actually the specs that I work on. I mean, [multi-cul 00:13:47] is also interesting to some people on the web.But a big area of interest to me are those specs that are interesting to publishers. Now, publishers don't have money to fund spec writers. So I'm unlikely to get money to, for instance, work on page floats. If I'm going to work on page floats, I'm probably going to have to sit and do that in my own time. Because there's nobody to fund that work really. It's, I guess, fairly niche. Although, there's an awful lot of people would like to have that work done. They just don't have anything to pay for it.
Brian Kardell: Yeah. I mean, it's an interesting aspect of this, that I think, effectively, it takes money to pay people for their time, which is a good thing. I mean, your labor should be compensated, right? We shouldn't take each other for granted, and require super heroic people to do years worth of work for free.And so we have found lots of ways to fund that, but then there's also this thing about membership. And once you're a member, it's not just your time, it's also, as Miriam said, travel. You have to maybe travel to face-to-face meetings. And you always could not travel. There was always ways to attend virtually. They try to compensate and make that possible. But once you get into it, you realize there is a huge, huge, huge benefit to being in the room with people. Yeah.
Miriam Suzanne (Mia): It seems like the hallway conversation.
Rachel Andrew: Yeah. It's the coffee break conversations. That's what we've really found. I think, with doing all this virtually, we can do the cracking through issues and resolving on things, but we don't have the conversations over coffee, where someone says, 'I've been thinking about this thing.' And someone else goes, 'Oh yeah, I've been thinking about that too. And here's my take on it.'And that doesn't happen virtually. And if you're a virtual person dialing in, you miss out on all of that, when there's a natural physical meeting happening.
Brian Kardell: Yeah. And then somebody from across the table who wasn't even part of the conversation, and you think that the area that they're from would not even have interest in this, suddenly they chime in and they say, 'No, I'm very interested in this.' And I think that that's the way that a lot of things get movement and interest and momentum, in a way.
Rachel Andrew: Yeah. I think, again, it comes down to this privilege of being able to be involved with this. And if we say to people, 'Oh yes, you can be an invited expert. We know you can't afford to travel. But that's okay, you can dial in,' we're almost relegating that person to being a second class member almost, because they miss out on all of that stuff. And that's not a great situation. It shouldn't be a case of, 'Oh, well, you can pay for your travel, so you can be fully part of us,' when a lot of those people are being paid by their companies to be there.That seems wrong to me as well. And it's something I think would be great to solve. So that if you find a talented person who could be working on standards, but can't afford to that, there is a way to say, 'Here, we can fund you to do this. We can get you here. We can fly you to this meeting that happens to be in Japan this time.' Because, otherwise, it's a diversity thing. If you're only saying that those who've got the means to have this expensive hobby can be involved, that's just wrong.
Miriam Suzanne (Mia): Right. It also changes what's being worked on. Because you mentioned earlier, if you're most interested in those specs that are mostly for publishing, and publishers have less money ... I mean, budgets are not evenly distributed across the membership. It's very clear that, say, Google is bringing the most funding to this, because they can.And then now with Google and Microsoft working together on Blink, there's a sense that Blink can do anything and get way out ahead. And it's what they're interested in then that gets funded.
Brian Kardell: Yeah. I actually think that that's really critical, and it's a huge part of the ecosystem health that we've been trying to talk about. So what's interesting is that it's one thing to be a browser, and it is another thing to be able to have the quality of interaction and involvement that you need to make something happen. And they're not exactly identical.So everything requires some funding. And it is rather expensive to join the W3C. But a lot of companies do that. I mean, there are about 500 member organizations. And they join for various reasons. And, as we said, it's not cheap. It's not cheap. There's the membership fee itself, which is not cheap, but then there's also travel, and somebody to act ... You have to actually pay your time, which is maybe a day a week for a single working group. But a lot of people are on multiple working groups. And, again, the better you get at it, the more places you get involved in, and maybe for example, run for the technical architecture group, or the advisory board, or something like that. And that's a whole other big commitment. It gets to be a lot.And so what's interesting about this is that in the, I would say, fairly recent past, it's become more and more common for people to hire people, like both of you, who specialize in some aspect of this, and can help them navigate that process. I think also a lot of people don't realize Ellica, or Fantasai on the CSS Working Group, who is on a million specs, and I would say is probably one of the key CSS Working Group members that has the best grasp on all of the things at the same time. Florian, who also is involved in a lot of specs, Amelia, who does SPG. All of these people are that, they're experts in this, that you can hire to help your company do these things, without having a whole division of your company necessarily that is full time on this, making a browser more or less.And I think that's really good. And Igalia does the same thing, not just for specs. We also do specs, but for implementations. Because one of the key factors in this is, if you want to talk about the specs, that's great, but if you can't get it implemented, it's not worth much. Knowing that we don't have the resources to get the implementation queue really stalls a lot of conversations. So I think these are really positive developments actually for the health of the whole thing.
Rachel Andrew: That's great. Typically, companies like Igalia, I think that's been incredibly helpful. I came across Igalia when I was working on the Grid stuff. Because I was actually speaking at a conference, CSS conf, about Grid, when it was really just starting to be implemented into Chrome by Igalia. And they were there. The people working on it were actually there at the conference. And so I was speaking on it, they were super excited, because I was talking about this thing that they were working on, and trying to get author interest.And so I came across this, that's what was going on. And understood the story about how Bloomberg were sponsoring that, which I had not come across before. And so I think that's an interesting thing that there can be as well sponsorship from outside, from some other company, then paying a company like Igalia to work on certain implementation. That struck me as very interesting.I think the thing about the contractors, about individuals ... And there are several individuals on the Working Group who are paid as contractors. The issue with that is how does an independent person get from probably having the ability to work on this stuff, to being in a position where a company is willing to pay them to work on this stuff? Because there's quite a ramp up to understand just how standards organizations work, and to learn how to write specs, and to learn how to contribute.And, actually, if you're a person who's got that body of work behind them, you're probably someone like me, who is in a position to find out where they might get paid, or get paid for adjacent things like I do. I don't get paid to work on specs, but I get paid to write about them. What does that new person, who doesn't have any funding, and doesn't have a huge amount of experience, but just is good at this, what's their track? How do we get them into this? How do they get to be a contractor on this stuff?
Miriam Suzanne (Mia): And, currently, it's almost like you have to be discovered or something. Somebody has to come to you and decide your-
Rachel Andrew: Yeah. You almost have to be granted this. And, again, it's people who are in a position of privilege, who are likely to be able to spend the time to get to that point. So that, I think, is an interesting facet of this.
Brian Kardell: Yeah, it definitely is. And I would like to even talk a little bit about how all of us, and even some other people who we now associate with the web platform, how did they get involved? So I know Tab Atkins got involved before he worked at Google. Showing the talent for that, and a good understanding of things, is how he eventually became I think the only editor actually employed by Google, which is interesting all on its own.But, yeah, how did you wind up ... Because in my conversations, frequently, it does require some heavy investment in a very expensive hobby, and then also luck, a lot of luck, and privilege. There's even cultural aspects to this, right? If you go to a meeting, and you speak up, and you have what people intuit as intelligent insights, or things to say or something, maybe something about your background also like heavily influences the things that you would do to get into that position, where you could be, I don't know, as Miriam said, sort of discovered.
Rachel Andrew: Yeah. I mean, I think that's even certainly for myself. I mean, I got involved in web platform stuff via the Web Standards Project. So I was writing about web standards and so on in 2000, and got invited to be a member of the Web Standards Project in 2001. So I've essentially built my career around web standards, and the web, and the importance of that. And so everything I've written about, and the work I was doing as a web developer, was based on that.So that's really, I guess, why people have known about me, and then the fact that I've just written a huge amount of stuff. So it's hard to read stuff about CSS, without stumbling over something I've written about it, particularly around layout. And that goes back a very, very long way. So that was my in, really, was just by being someone who writes a lot. And the public speaking came a lot more recently than that. It was mainly writing. And that was how I got known for knowing about these things, I guess.
Miriam Suzanne (Mia): Yeah, for me, I mean, I was always interested in standards, but I would say I thought of myself more as a consumer of them, and a teacher of them. I didn't really get involved in the process until very recently. But I just built some tools and shared them. And I built SUSY, which was using SASS, which ... Again, I mean, these similar problems are in the open source world, right? I was able to do that because I had certain privileges, to be able to afford to spend some of my free time, and to have a company that supported me spending some company time on these open source tools.And, really, I think regularly I'm here because OddBird has been insistent that we want to be part of the community. And Miriam's interested in that, make her do it. So the company has been very supportive. I've been working there for almost 15 years now. And it's why I'm here, is because I was able to put in that time. And then Mozilla noticed Jen Simmons. I got to work with her on the Mozilla developer channel. And I made a proposal for a specifically, based on the work that we were doing there, teaching the Cascade. And that got me invited to the Working Group.But I still couldn't contribute much, because I didn't really have funding for it. OddBird was paying me some, but couldn't afford to have me spending full time on it. And then Google came along and said, 'What if we pay you to put more of your time into this?' So it is that having the privilege to get started, and then somebody notice you, and like the hand of God, pull you up and fund you and make it happen.
Rachel Andrew: Yeah. I mean, that's it. There's so many things, where I think back at it, it's been a bit of luck, it's been because ... In my case, a lot of it has just been that I'm willing to work very long hours. And so I've done my contract work, and then I do my other work, whether that's web standards advocacy in the early days, or stuff for the CSS Working Group, or what have you.And, again, I'm in a position where I'm able to do that. And I've been doing it for 20 odd years. I'm not going to stop. But not everybody's in that situation, in terms of their other commitments, and what have you. So I think it's an interesting thing to discuss, really. Because we've got a bunch of people ... I mean, same as with a lot of open-source stuff, as you say, Miriam. There's people working for free on things, which massive companies, well-funded companies, are benefiting from.And it feels that there should be a way just to help people get involved in that process, without them having to either work ridiculously long hours, or not earn the money they should be earning, or what have you. I mean that doesn't seem like a great way forward.
Brian Kardell: Yeah. I've been stressing for the past year, maybe year and a half now, this notion that we need to think about the web platform as a commons. Because, literally, everything about modern life relies on the web, literally everything. As I was saying, with embedded systems, you can just see the trail of ... You kind of can't do things today that don't use web technology.And so, in a way, this is the roads and bridges, this is the infrastructure of everything. And everybody benefits from it. But who is paying the people? And why does it work that way, I think is the really interesting question. How can we do better? I guess, sort of the overarching theme of this. And I like the idea, and reiterating the idea that none of these things are fixed in stone, and they have changed even in fairly recent years. And there's a lot more room to do even more.I think Open Web Docs is a new thing that I'm pretty excited about. Because it is a way to let lots of people pitch in. I don't know what the right way to call this. In my mind, I think about it like a voluntary tax, but maybe the word tax turns some people off. And that can be to companies as well. But rather than the companies dictating what gets done, that is left to a more collective decision, which I think is, in a way, very, very interesting, as a new thing to try.Open Prioritization is also trying to do something like that, like, 'Well, we know that not everybody can be Google or Apple.' Not everybody can fund the whole spec work, or the whole implementation work of something. But we have lots and lots of things that just are ... We have potholes. And we have lots of things that could be taken last miles, or could be fixed or improved, in great and important ways. Maybe there are opportunities where many of us could make that happen, in place of a single entity.Rachel had mentioned, publishers don't have money to pay for this. That's an interesting thing. Because, of course, many publishers do have considerable money, but it's where they prioritize it. And they think that, currently, this is the cost benefit value proposition for me. And maybe that involves sending somebody to work on specs for a couple of years or not.But it's maybe a whole different thing, if we can say, 'Here's a feature. And we're not asking any one company to pay for it. But maybe if a number of companies pitched in a very small amount, we can do a lot of practical pothole fixing and bridge building.'
Rachel Andrew: Yeah. I think that could be a really great way forward. And that's why I liked the idea of the open privatization thing. So we saw that with Grid and with Bloomberg, that they wanted that technology in the browser. And so they were willing to fund it. And they're obviously an enormous company, and a lot of companies wouldn't have the money to fund something like Grid. But, yeah, as you say, there's lots of smaller things, or things that groups of companies would get together and say, 'Yeah, we want this spec sorted out, because we want to be able to implement it. And we can fund that.'Because we're not talking about huge amounts of money, when we're talking about paying for the contractor to work on a spec, we're talking about one person. And that's actually not vast amounts of money, if we're talking about just spec development, for example. So you'd think that there could be better routes for that. I don't know.
Brian Kardell: Yeah. I think there's all kinds of interesting possibilities. In fact, if anybody in the listening audience has thoughts and ideas on that, share them with us. Because I think we're constantly trying to do better, not just the people here, but standards, and the whole entire ecosystem is constantly ... We're aware of these things. And it's just how do we do better? I think it is constantly getting better, but it only gets better when we have new ideas and try new things.
Rachel Andrew: I think, as well, there needs to be a way for people to see what the possibilities are. Because there's not a huge amount of good understanding, I think, about just how it all works. To actually get to a point where you understand how this whole process works takes a very long time. And it was only really because of Frontiers naturally going to do W3C meetings, as opposed to just CSS Working Group meetings, that I really got an understanding of the whole thing and how it goes together.So expecting companies to fund the thing as well, how do they find out that that's even a possibility, if they're not embedded in this stuff already? And so I think that piece is also interesting. How can we expose the fact that it's possible to do you know what Bloomberg did, for example? And how do we expose that to more companies, so they realize that actually it is possible to contribute to either getting a spec completed, if that's the issue, or paying for implementation work, if that's the issue? I don't know whether there's a huge understanding that that's even a possible thing.
Miriam Suzanne (Mia): I would say the same thing for getting involved, actually doing the work, right? There's no how to write a spec. There's no way that you build up from small specs to large specs. Somebody invited me to do this, and then I just tried to figure it out. There's not a training course.
Rachel Andrew: No. You just have to ask other people in the Working Group, and depending on ... Yeah. I mean, I find that quite difficult. I sort of think, 'Oh, am I just being stupid, not understanding this thing?' And not wanting to go and pester people constantly.
Miriam Suzanne (Mia): Right. Yeah. I mean, I've been in the field for quite a while, and I didn't really see that as an option, like, 'Oh, that's a job I could go get, or an an expensive hobby I could go get, or find people to pay me.' I mean, it wasn't really on my radar as an option, to become a spec writer. And I don't know if that's something that other people think of, or would be interested in, or if there's ways to make that feel more available as a potential path.
Rachel Andrew: Yeah. Because I think when I have these discussions with people, they sort of say, 'But anyone can contribute.' And it's true. Anyone can contribute. But to actually come along and propose a change to a spec on the CSS Working Group repo, I mean, that's quite a big deal, really.And then, just as well as that, the whole what's going to happen when you do that, the whole bike shedding and discussion, which, if you're not used to how that goes, may well seem ... And I've seen it in the past year. People have come with perfectly reasonable suggestions, that just happen to have been discussed to death before, and for whatever reason, they're not going to work. And so this person gets shut down. And then they're just like, 'Oh, they don't really want my input,' kind of thing.And so all of that I think is just very difficult to sort of penetrate and get into, and be in a position where you can start to contribute, and not feel like you're just being knocked back all the time.
Brian Kardell: Yep. Yeah. That is actually a surprisingly difficult thing. Because if you have come from the outside, you experience some of that, right? You experience some of seeing what seemed like a very reasonable idea, get, I don't know, seemingly short shrift. Or we've already talked about that. Stop trying to make fetch happen. It's not going to happen. Right?
Miriam Suzanne (Mia): But even some that do end up happening, why did it take us 12 years to do container queries? Well, there's good reasons for that.
Brian Kardell: That's exactly what I was going to say. Actually, we were saying, no way you can lift the veil and see ... Just seems like one day we decided, 'Let's do container queries.' Or one day we decided, 'Let's do Grid.' But there's years of effort and things behind that, that go unseen.And I've heard people in talks, and on Twitter and things, say, 'We can get things done really quickly if we want to. If the CSS Working Group just really feels productive, and wants to set their mind to it, they could make anything happen. We did Grid and Flexbox in, what, like six months?' And it's like, 'No, no. There were many years before that six months, where you became aware of and started paying attention, that went into that.'
Rachel Andrew: Yeah. I mean, I think that sort of the patience in its own ... Because I talk quite a lot. When I do my various talks and things about CSS, I often include stuff about the process, and about how things are made. And I do point to how long things have taken, and why they've taken that long, and why something couldn't have happened, because we didn't have the things that go before it that made it possible.And I think that, yeah, there's a lack of understanding of that. And, I mean, why should people understand that? I mean, you don't have to understand all of these intricacies that are typically involved. But, yeah, I think it is just difficult to get people past that hurdle.And if they're not used to discussing things in this sort of robust way which things are discussed ... And people that are typically very friendly, but tend to be quite direct when discussing things that are going to go into a CSS spec. It's certainly not rubbishing ideas, it's just speaking the mind about it. But, yeah, if you're not used to that kind of discussion around your idea, it can seem quite harsh, I think.
Miriam Suzanne (Mia): I think there's also just ... One of the strengths of CSS is how interconnected it is, in a sort of built for design systems. One part of a design affects other parts of a design. That's really powerful, but it also means we've got this huge number of specs that are all intertwined, in ways that are maybe not obvious until you dig into it.So most of us aren't Ellica. Most of us aren't spending our full time understanding all of the different specs. So it can be confusing, even once you're working on them, if you have a focus, and you don't really know all of the places that it might impact.
Rachel Andrew: Yeah. Yeah. And that's it. And, generally, people are pretty helpful if you ask questions. But they're busy people too. I think, in general, most people are quite surprised as to the small number of people who are actually working on this stuff. There's not many people writing your layout specs for example. And so it's quite difficult sometimes to just have a question answered, or what have you, if you're starting out, and you've got all of that to go over. You don't quite know what you're asking yet.
Brian Kardell: Yeah, absolutely. I think that thing about time is super important to all this. One of the things that I have worked on a lot is incubation also, where possible, enabling things to be polyfilled, so that you could ... It's a whole different thing, to come around in, I don't know, 2007, and say, 'Here's this idea we have for flexible box layout. It's very complicated. And we need people to comment on it.' Just to do that alone, even once, is a pretty significant ask of your time.The way that I learn about whether I actually like a thing is by using it. Lots of things sound good. App Cash sounded good. It sounded good, but then you try to use it, and you're like, 'Oh yeah, this is terrible actually.' So many things that we've tried sound really good. And then when you try to use them, then you have lots more questions and comments. Something doesn't work as you expect it to work. And you only realize that when you go to use it.I think one of the things that has been really helpful recently is the ability to turn on experimental web platform features, and have origin trials and things like that, where we can, as quickly as possible, give people something. And say, 'Yeah, just try it. And use your questions. And here's a polyfill, and you could make it work.' And it will have some costs, but this way you can potentially use a real thing, and maybe accomplish something, which is, at the end of the day, what most people want to do in the first place, and comment on it before it becomes a standard. And let us know where it doesn't meet your expectations or criteria.This is currently harder with CSS, but that's part of what Houdini is about. I know we did this with a bunch of things like Inner and Focus Visible, and we got a lot of really, really useful feedback, and improved things quite a lot.
Miriam Suzanne (Mia): But it reminds me also of the way that open UI is approaching things, I mean, in a format where it's easier to prototype. It's harder to prototype CSS. It's easier to prototype components. But trying to build out custom elements, web components, that sort of prove the concept before moving them into a browser.But I think also a thing that's interesting with that, there's more and more of these community groups opening up, which maybe are that path in, that way to start writing spec proposals, start getting involved without needing membership, or invited expert status. Anybody can get involved in a community group. And there are spec proposals coming through those community groups.
Rachel Andrew: Yeah. That's true, I think. Yeah. I'm not sure how much understanding there is of how that stuff works out there in developer land. I mean, the stuff about having stuff behind flags and origin trials is interesting. Because I'm sure we all remember the vendor prefix mess that sort of proceeded that.And I think, looking at the history of Flexbox and Grid, I think sort of highlights the issue of shipping stuff with prefixes, and ending up with three versions of Flexbox, versus the fact that Grid appeared to just sort of appear out of nowhere, once all the flags were removed. And so it is harder to get feedback on CSS features when things are behind flags, which really was the start of my Grid advocacy, was because I realized that without someone showing how it would work to people, no one was going to think about it until it actually arrived, if it ever arrived. Because if there wasn't interest in it, maybe it wouldn't arrive.And so that was really what I was doing was trying to ... And there was a period where I was just mocking stuff up. It was a period between the IE version and it ending up in Chrome, where I was essentially just mocking up all my examples, so I could show people how it was going to work. So, yeah, Houdini would make a lot of that stuff, I think, easier these days.But, yeah, it's interesting. Trying to get excitement and feedback on things, which are hidden behind flags, is also sometimes a bit challenging.
Brian Kardell: Yeah. I think the interesting things that go into that are, like I say, you have to ... I imagined it was very time-consuming for you to ... I mean, what you're effectively doing is the paper version of web platform tests, right?
Rachel Andrew: Yeah.
Brian Kardell: You're like, 'Here is the input, and here is the result.' But that means you have to take a lot of time to make sure that that's right. And that's a big ask of a lot of people's time. And, at the end of it, they don't get something, other than a feeling that they understand it, and maybe helped provide feedback.It's very, very possible that it could be five years before you see that, in a way that you can use it, even in one browser. That's an unfortunate cost benefit thing for developers to consider. So the more we can get to meeting developers where they are, and saying, 'Well, I can give you this theory and lesson, but go play with it. And then come back and let's talk about it.' I think that's very, very relevant, without it escaping the realm of the vendor prefix.
Rachel Andrew: Well, yeah. I mean, I think that's why, with Grid, once there was a very solid implementation in Chrome behind a flag, then interested people were able to play with it. I mean, the Grid By Example site I made was exactly for that. I made tons of examples, and let people look. Enable that flag and just go, and look at these examples, and see what you think. So it was kind of that try to create an easy route in, for people to play with it. And I think that's-
Brian Kardell: It's a great site, by the way. It's really, really great.
Rachel Andrew: Yeah. I think it got a lot of people interested, because it removed that barrier. It wasn't like, 'Oh, you need to go and understand the spec, and build yourself some examples,' it was like, 'Well, here's the examples, just toggle that flag, and have a look.' And that kind of thing caught people's imagination a bit about it. Because they were immediately then a designer. He's going to think, 'Oh. Oh yeah, that exactly solves this problem we have.'And so, yeah, I think exposing this stuff to people, particularly with CSS, where it's not like an API, where you can just kind of talk about, 'Well, what are you going to give it this, and get back that and that.' With CSS, you kind of need to see it. And a lot of people are more on the design spectrum. And they need to be able to see and experience how it's going to behave, I think, to really start offering feedback.
Brian Kardell: Yeah. And what I like about that site too, is, even for me, seeing the examples, it is really, really helpful. But then having something that's a little bit more like code or dev tools, that you can tweak and input, and see that your understanding of what you're seeing is correct. Right? I think those things are just so valuable.And I think, while they're a step further away, polyfills are even better. If we can get really high quality polyfills, they're even better, in that they let you try to solve a real-world problem. If you haven't check it out, the W3C tag has a great note that they wrote, a tag finding on polyfills and the evolution of the web. And speculative polyfills are what we're talking about here, not the traditional Remy Sharp polyfills, where three of four browsers support this thing, and you just need to spackle the hole. Right? We know exactly how it's going to work. And we can say, 'If your browser supports this, then you don't need it, because they're all going to work the same way.'But these are what we're talking about is speculative polyfills. So this is an experiment. It might never actually be a thing. And if it is a thing, it might not look exactly like this. What we're trying to do is figure that out. So use the polyfill. Do useful things, or try to. And it's likely you'll find lots of useful things, that you wish you could do, that you can't. And we need to know that. But it lets developers do a useful thing.So, at the end of the day, the reason that a lot of people come to the CSS Working Group is because they keep experiencing some pain, and they have some idea about how to make the pain go away. They have some desire to do something that they can't do. And if you say, 'Here's a way that you could try to do that,' and it's useful whether it becomes a standard or not, because it will help you alleviate the pain or do the thing. But the barrier is really low now. You can tell us if it's terrible or great or whatever. That's, I think, really great.
Rachel Andrew: Yeah. Definitely. What I think would be very useful, and it'd be nice to see, would be to try and promote those places where actually author input has changed for the better. I know of those sort of places in some of the CSS stuff.And I think that actually when people are engaging with this very slow moving process, and feel like they're throwing ideas and nothing's happening about them, to actually be able to see that, oh yes, ideas coming from the community, they are happening. It's not happening in time for my next project, but it is happening.
Miriam Suzanne (Mia): Ideal container queries aren't quite possible in the way that we imagine them, because there's so much potential for infinite loop problems. But the whole thing is based on ideas people have been talking about for 12 years. But the idea is not new. And there have been polyfills out there doing something container query-like for several years now, which was also helpful. I mean, we got to look at all of those speculative polyfills, and build off of that.
Miriam Suzanne (Mia): Right. And sometimes that ends up looking very much like the tools that people were using. We're sort of able to take it in fall, and just port the idea over. And sometimes it ends up looking very different, but containing some part of the idea. I mean, we learned from SASS variables, and then created something entirely different from SASS variables. But still those pre-processors proved the concept.
Rachel Andrew: Yeah. Yeah. I mean, I've developed product. And I can kind of see that developing the web platform is very, very similar. You have a product guide, a content manager system, and people come with ideas for this thing. And, typically, what you implement is not their idea exactly as they came. Because what you tend to do is get lots of other people's ideas too, and try and solve a whole bunch of use cases with that thing, or see if there's two very similar things that perhaps are really the same thing at core.And I think the web platform really is just very similar to any other kinds of product development. You need to get those use cases. And bouncing around a bit to find out is that the only thing that needs to happen like that? Or are there other things that are similar? And sort of work them all together. And I think that the length of time some of these things take is just that. We need to get enough use cases, to be sure that this thing is going to be useful to as many people as possible when it's implemented. And obviously this-
Miriam Suzanne (Mia): And then, also, how is it going to impact Grid? How's it going to impact Flexbox? How's it going to work in a block model? How's it going to work with Ruby text? How's it going to work with ... Even beyond the basic use cases that you're trying to solve, how is the idea going to interact with everything else that's already there?
Rachel Andrew: Yeah. And the stakes are so much higher with the web platform. Because once it's out there, that's it. It's staying out there. So it's not like we can deprecate stuff very easily, or what have you. We don't break the web. So the stakes are fairly high. If we're going to have something there, we want to make sure it is good and performs well, and doesn't have accessibility issues and security issues, and all those sorts of things.
Brian Kardell: Yeah. I was just going to say, I really like the comment that you made there about how it's a lot like a product. It is a lot like a product, if you can imagine the largest product you can possibly imagine, that can't ever break, that can't ever release a new edition, that is completely incompatible with past editions somehow.
Miriam Suzanne (Mia): Web 2.0.
Rachel Andrew: Yeah, exactly.
Brian Kardell: For other competitors who have their entire own products to manage. But thinking about that is actually really helpful. And I've written and talked a lot about that. So many things we look at about the platform, we tend to not look at that. And I remember, I think it was Jen Simmons, though maybe ... Yeah, I think it was Jen Simmons that said, at some point, as soon as she went to work for Mozilla ... She had been on the web for a long time. Everybody knew who Jen was. And as soon as she went to Mozilla, I think she tweeted something like, 'As soon as I got there, I realized suddenly, oh right, this is a product.' Right?It seems so obvious at some level, but there are people with skills and time. And you can't just be like, 'We're going to do this thing because it's the right thing to do,' and just make a thousand of those decisions today. Because, at the end of the day, you need to have the people to do the thing. You will have to find a way to prioritize, get things done, ship things, fix bugs, and-
Miriam Suzanne (Mia): And convince these companies that it will be profitable for them somehow.
Brian Kardell: Yeah, exactly. And it's really interesting to look at things through that lens. Because as Mia said very much earlier, ultimately, that there is some bent of priority to who's sponsoring that. People want to sponsor things that they think are most important, but also they want to sponsor things that they can get done. And, just like any other product, there's all of these hidden things.It might be that you have 10 requests for thing A, and you could roughly sort out a thing A. You know you can do that. But you know it's going to cost you six months worth of work. You have a bunch of requests for thing B. And thing B is maybe the most important thing, but there's some rearchitecture happening in your product. It would just be way more cost efficient to wait until that's done. So you're going to wait until that's done.And then you have things C, D, E, that are ... Maybe they're not important. They're not as important. But you have free resources. And those people can do those things. And so you get those things [crosstalk 00:55:22].
Miriam Suzanne (Mia): Wait, is thing B Subgrid?
Brian Kardell: It could be Subgrid. Yes, it could be Subgrid. I mean, it could be, it could be Subgrid, or it could be aspects of MathML, or it could be things about container queries even. So yeah. I mean, it's full of interesting things, when you begin to think about it through that lens a little bit.
Rachel Andrew: Yeah. I think, for me, it's trying to explain a web developer sort of thing well, that just all these enormous companies sat there on their hands, refusing to implement these things. And so something I've tried to do is show a bit how the sausage is made, I guess, when I do these talks and so on, just explaining why things take so long, the number of decisions, but also the fact that it's a very specialist thing to write these specs, and then to implement them.And although they're huge companies, there are very few people, say, able to implement layout in a browser engine. And I think it's helpful to people out there in the community who want to contribute, to understand the process a bit more, I think.
Brian Kardell: All this is really, really helpful, the more of it we do. It is also relatedly funny, how much discussion there is in the web community that portrays things as being entirely political, like Google versus Apple. Do you know what I mean?
Rachel Andrew: Yeah. I see often in articles really weird assumptions that people have made about why something hasn't happened or has happened, that you're kind of like, 'I know full well it was just because there was no one to do it right then.'
Brian Kardell: Yeah. I know that it's because we're currently implementing the next gen layout systems.
Rachel Andrew: Yeah, exactly. And then you'll see this article where someone's suggesting that this is due to some enormous battle, or someone didn't want to do it. And I'm like, 'Where did you get this information from?'
Brian Kardell: Or even very broad-
Rachel Andrew: It's like they're just making stuff up.
Brian Kardell: Even very broad conspiracies that fit the narrative. Right? But, yeah, I don't think that they're silly, necessarily. I think people are doing the best they can with the information that they have. And, I mean, they are probably filling too many gaps. It's easy to not see that, I guess, is what I'm saying.
Rachel Andrew: Yeah. I mean, I know it's sort of historic ... I think there's this story about warring browser vendors, that comes from the browser wars time. And I obviously was involved at that time with the Web Standards Project. And there's this mythology almost that's carried through. And I've had it directly asked me, people were like, 'Oh, do they are not all fight with each other at the CSS Working Group meeting?' I'm like, 'No, mostly they're just all sort of chin scratching, and wondering if it's possible.'
Brian Kardell: It's mainly our death matches, that people imagine it's like a Kung Fu movie.
Rachel Andrew: Yeah. But I'm also like, 'You know you can search the archives, if you really want to know what was said about this or that. It's all there.' But, yeah, I think there is a sort of mythology about what actually happens, which doesn't really match what really happens. If people came to meetings, expecting a fight, then they'd be sadly disappointed.
Brian Kardell: I'm not saying that there is nothing like that. I mean, there are business/political struggles, of course.
Miriam Suzanne (Mia): Right. The spirit of truth is that these companies do have cultures, and do have things that they prioritize. And it's true that Apple is sometimes prioritizing something different than what Google is prioritizing, for business reasons.But it's also true that, as soon as you start working with these companies, they're made up of individuals who have different ideas, and they disagree with each other. And there's different departments working on different aspects of something. So Google isn't always coordinated in what they're proposing to the web. They're having internal struggles too. Right?
Rachel Andrew: Yeah. And then just how much isn't, oh, this browser is refusing to do it for political reasons. It might be that browser was just saying, I don't think we can do this because old code.
Brian Kardell: It is easy to imagine. And I think there is this mythology that leads people to believe that everything is this. But most things are actually entirely more mundane, boring things.
Rachel Andrew: Is this even possible to implement in this particular engine? And that might be different. It could be something that's super easy for Firefox to implement, and almost impossible for Chrome to do, just because of the way things are. And all of that is stuff that, yeah, we'll get them painted as, oh, this browser is holding back the web, and all that sort of thing. And everyone's looking for the new IE 6, which is the terrible browser today. And it's not particularly helpful.
Miriam Suzanne (Mia): Yeah. And it's not even going to happen in the same way again, now that browsers are evergreen, and releasing more on six week schedules, rather than six year schedules. We're just not likely to see the same sort of ... Yeah, it's also interesting with companies like Igalia, and just how many of the browser engineers are working on multiple browser engines.
Rachel Andrew: I mean, that is really helpful, just in terms of moving things forward. Because if you've got someone who actually understands the internals of more than one engine is super useful. And you see that in discussion.
Brian Kardell: Thanks for coming on. I think that there was a whole lot of interesting things here. And thanks for effort. And I'm really happy that you're both involved, and that there are ways that people are funding your work now. And if other people have needs for those kinds of skills, there's a small community of people that is doing some of the really great work, and would like to help to connect you.
Rachel Andrew: No, it's been really, really great to have this discussion. It's always fun to talk about the behind the scenes things. I hope it's been interesting to the people listening. So thank you.
Miriam Suzanne (Mia): Yeah. And I hope that we can continue to sort through these questions. I mean, I think there are a lot of open questions, about how do we make this more accessible to more people? How do we get more diverse viewpoints involved and funded? And I'd like to see those conversations continue happening.