Brian Kardell: Okay. So I am Brian Kardell. I'm a developer advocate at Igalia, and we've been having this long conversation and about the health of the web ecosystem. I've had different guests on and this time I am joined by a colleague of mine.
Eric Meyer: Hello. I'm Eric Meyer. I'm also a developer advocate at Igalia, having joined more recently than Brian came on board, but happy to be here. Hey, Brian.
Brian Kardell: Hey, how are you doing, Eric? I'm really glad that you're on here. I hope we do some more of these. I think this should be fun.
Eric Meyer: Yeah, totally.
Brian Kardell: If you don't know Eric, he is the author of the CSS Definitive Guide, co-author as of the latest version with Estelle Weyl.
Eric Meyer: And congratulations to my co-author, by the way, Estelle, who just joined the Open Web Docs.
Brian Kardell: That's excellent, I'm really glad it is...
Eric Meyer: Super awesome.
Brian Kardell: That's a great effort. I'm really happy that we're involved and could help start that too. Okay, so we have been discussing the health of the web ecosystem, and we've discussed it from lots of different angles, and one that Eric and I have been talking about recently, given a lot of things that have come up, is how are the communicational channels in the ecosystem working? A number of events over the past couple of months and even some podcasts like our friends, Jake Archibald and Surma on the 203 podcasts recently had a, is Safari the new IE? The title makes you think it's one thing, but it's actually a lot more nuanced and I appreciated the conversation in that. I don't know. What do you think, Eric?
Eric Meyer: Well, I don't think safari is the new IE. I think Safari is Safari and IE was IE. But I agree with you about the podcast Jake and Surma take on. It was longer and more nuanced than its title would have suggested.
Brian Kardell: Yeah. They dig into that question, because it seems to be almost a meme at this point. But we thought about how are the communications channels working and what are the impacts of that? Are there impacts to the health of the ecosystem? I think Eric, we agreed, it could be better, right?
Eric Meyer: Yeah, it could be better.
Brian Kardell: Things have improved in a lot of ways. Everything is a lot more open. Everything is done theoretically in public. There still is a members list. I don't think that it actually gets an email.
Eric Meyer: The mail that I've gotten from it since rejoining has literally been things like reminders that, hey, we've been invited to the Color API workshop to participate. Just to remind... It's solely administrative, from what I've seen.
Brian Kardell: All of this stuff is there, anybody can participate. But that's in theory. In practice, I think developers, they have questions. Like why is this thing getting done and not that other thing? Or why does it seem like this one group, whichever group you happen to think at that moment, is being very productive, whether that's the CSS working group or a TC39 or back in the HTML file, maybe it was the HTML the what wig.Why are they being really productive and this other group isn't? They seem really stalled out or something. They seem to be taking longer. Or like, what happened to that thing everybody was talking about that I thought was going to be a standard, whatever happened to that? Or why is this thing being deprecated or even what does that mean? Which is the thing that happened recently.I think these are all really good questions. And while they technically have access to all of the information, I think one of the challenges is we don't do a lot to sort of help them consume that.
Eric Meyer: Yeah. This is something that I think a lot of people have noticed. Certainly you and I have talked about it and helped each other in certain points with the fact that a lot of these discussions don't happen in just one place. A change in WebKit might have been discussed in part on a W3C CSS working group, GitHub issue.Then it might also have been discussed on a couple of WebKit bugs that have been filed in the public database. And then if you have access to radar, there might've been a radar that's not open to the public. And so, all of the steps that lead to a given change usually are not all in one place. They're scattered around and only a very few people will have followed all of those steps in the process. Then going back and trying to find them all is a challenge. It's not easy often.I think this is where the CSS working group, for example, shines most of the discussion, if not all of the discussion of a given issue will be on that GitHub issue. From a standards point of view, from a committee point of view, usually you can find most of the information. It's not perfect. Sometimes things are scattered a bit, but they're usually centralized. It's when it comes to actual implementation that things start to get scattered.Because somebody will file a chromium ticket that says, 'Hey, the working group has decided to change the definition of this key word to be the slightly different thing. It's been clarified and so this needs to be fixed.' Then there'll be a whole discussion in there about, what does that mean for the chromium code base and what do we have to change? And here are the ref tests and this and that and the other thing.Then three other people will have filed related bugs and they're all, they're linked to each other. But as humans, the hyper and hypertext sometimes can be a little difficult for us. Okay, I have to read here, but then I have to go over here and read here, but those two separate things have to be integrated, and then go back and read some more and then go to a different place, and I think that's the challenge for a lot of people.Even for us who have been, sometimes when we've been following this, we've had these conversations where it's like, 'Somebody described what that solution was going to be. Where was that?'
Brian Kardell: Right. I think the other aspect of that too, is even if you are really, really motivated and you had infinity time to dig into this, the linking is imperfect. You will find in all those cases where it is on GitHub. Those things are pretty well linked. This will say this links to this thing in this HTML repository, this pull request, and this pull request links then to this issue and then that has three related issues in CSS.And those, if it's discussed in the working group, the bug posts the minutes to that issue. But there are times that breaks down where a little aspect of the conversation winds up over in WebKit or it winds up over in Chromium, or it winds up not properly minuted, where somebody references like, 'Well, previously we discussed x and x might have 10 years worth of history behind it and it'll have a link to any of it.'So sleuthing it out and understanding all that stuff is not easy, to be fair. When we lack information, I think just as humans, we try to fill the gap somehow, and we fill it with whatever seems to make sense. And sometimes we fill it with narratives that seem to make sense.
Eric Meyer: Yeah. We interpret what we can see through the lens of what we expect and what we believe. For everything, but also for this. If you've already come to the conclusion that Google is evil, then when Google does a thing and you don't have all of the backstory, that gets interpreted in a, well, what evil thing are they doing this for?Or if you've already decided that Apple doesn't really care about Safari and the web, or at least about standards, then when WebKit or Safari does a thing, you tend to interpret it in the sense of, well, why would they have done this when they don't care about the web? That puts an internal spin on things.
Brian Kardell: Yeah. It's not good for developers because they have all these questions that we've articulated. But it's interesting to think about how that combination of two things impacts the health of the ecosystem. Because I do know that there are cases where that has been counterproductive. Where nobody wants to be yelled at all the time.It is really tedious work to get one of these things like herd all the cats, get a little bit of everybody's time, advance things. Then if people get really angry with you for reasons that are, maybe you know are just not true, that can be really exhausting. I've seen certain things just get dropped.
Eric Meyer: Certainly, it's understandable if a developer at a company, who is going to have a whole bunch of things on their plate. They've got a very long to-do list. If there's one item on their to-do list, that gets lots of people yelling at them on Twitter and in bug reports, and wherever else. I'm certain there's a temptation to say, I could work on these other things where nobody's yelling. I'm just going to put this one down for a while because I don't want to be yelled at again this week, if at all possible. So I'm going to go work on other bug or other feature or whatever it is. Then as I think have all of us, once you put something on the back burner, often you never get back to that burner.
Brian Kardell: Yeah. The more negative sentiment is around something, the more people will reevaluate in a different way, like is this worth it for me? Or maybe for us, to be the ones taking the breadth of this? I think that's really interesting. On the one hand it's really good that developers have that power. That we can exercise the power to shut down a bad thing. I think we could use help making sure that it's always the bad thing that's getting shut down.I think there's a really good example, actually, that happened recently, a lens that you could view a specific thing through. There was an announcement of a deprecation and we won't even dig into all of the stuff about that right away. But one tweet in there said, 'Breaking changes happen often. As a developer, you should always be checking things in early channels.' Now, I know where this came from and I do know a lot of the history and stuff here. And so [crosstalk 00:11:58]-
Eric Meyer: I'm interested to hear that history and where that came from.
Brian Kardell: We can dig into that in a minute, but the way that I read this as all of the engines are constantly being updated. We like that about them, that they're constantly improving internals, that they're improving performance, that they're redoing their next gen layout engines and there's a huge, huge surface area, ad sometimes we mess up and we want to know about that as soon as possible. I didn't think about that as, we just stop shipping features all the time. That's the lens that I viewed it through. It's not how it was largely we received.
Eric Meyer: No. I didn't even perceive it the way you did, which is interesting. Now that you've said it, I completely get it. Basically, it's Google thing. Because we update every six weeks the way that everybody wants us to. Sometimes stuff breaks and you should always be testing to make sure that we didn't break something. Always be testing so you can tell us, hey, you broke this. You need to fix it before the next release, is I think what you're saying, where they were coming from. Whereas I read it as, hey, stuff breaks on the web all the time and we break stuff on the web all the time and you should be ready for that.
Brian Kardell: I think people read it as, we break things on purpose. That, I think it's not the case. I think that the case is everybody agrees that should be really, really, really, really rare and done with great caution. This reminds me actually of when I first start getting into standards. There was this, the ECMA specifications. This is what is really interesting, is that we have all of these controls to test now, to make sure that we don't break things.But the number of things that are still under-documented or that we have compatibility but we don't even realize where and how, it's way better than it was but it's still imperfect. An example of this is when I first got into standards. I had been using them for a long time but when I first started contributing to discussions, this story was relayed to me as I proposed a thing.That was the ECMA specification for a longest time, it had this concept of being iterate to properties of an object. It said that properties were iterated in no particular order. No guaranteed order to iteration. As long as you iterate them, you are spec compliant. Java also by the way had this in their HashMap specification, said the exact same thing. Basically the same idea.
Eric Meyer: So they could be read back in the order they were created or they could be read back, sorted alphabetically. In either way it's back compliant.
Brian Kardell: Exactly, exactly. But it turned out that actually implementations did agree, but only to an extent. But people learned this. They just discovered it, because they [crosstalk 00:15:06]-
Eric Meyer: They discovered that everybody returned stuff in the same order.
Brian Kardell: Right. So they built things based on that. When some engine, I believe it was Opera first, but I believe the same thing happened to Chrome, when they were doing their implementation, they were trying to improve performance of their JavaScript engine, and they realized that they have this trick and they can actually make it faster if they don't maintain this in search in order. And so they did, and it was entirely spec compliant. And all kinds of things, like Gmail just broke.
Eric Meyer: I shouldn't laugh, but that's funny.
Brian Kardell: We passed all the tests though. That kind of thing does happen. If you look at it through that lens, it's a completely different statement. Not at all bad in a way. It's good. I think that's tricky because this communication stuff is really hard and it requires many individuals to understand the same thing. I know, Eric, you and I occasionally through, here's a thing, a draft. And we read drafts for other people. And very frequently, somebody is able to say, does that mean x? And you say, what? It is really hard to convey the thing that you mean and only that and not something else.
Eric Meyer: It's basically impossible to write something in a way which cannot possibly be interpreted differently than the way you intended it. Human language isn't that precise.
Brian Kardell: When you combine these two things about it being hard to assemble the backstory and communication being hard and things, it feels like can go off the rails. It is interesting to look at a couple of these, like the alert one. Let's fill in here. It seemed like there was a popular narrative that began to happen, that Google just wants to break stuff. And that really, it was just a couple, or maybe even one individual who just has way too much power. And just on a Tuesday morning, he was like, 'Let's break the web.'
Eric Meyer: Stroking a persian cat while they say it.
Brian Kardell: Right, exactly. But of course, I don't know that anybody really has that image in their head. That's a bit of a caricature presentation even for me. But you get what I mean. That was like the sentiment was a lot more closer to that. But the real thing is that is a real problem because these are very old APIs. They're way from the beginning. I think these are Brendan Eich year old original inventions.They present basically an operating system level dialogue. It has been really hard to make end users understand that, even just that. It has been actually really hard to make an end user to understand domains. Sometimes it's like we think to ourselves like, 'Well, just learn it. It's not that hard.' Or whatever, but the number of vectors here is actually really incredible.When I started at Igalia, there was a thing that was fascinating to me, where there was an open bug. Because URLs can contain Unicode characters. People would register some domain with a lookalike characters. You would get like apple.com is what it looks. And like, no.
Eric Meyer: Because the a in apple.com was like mathematical a or something like that.
Brian Kardell: Exactly. Exactly.
Eric Meyer: Mathematical a pple.com. But if somebody clicks on a link in a spear phishing or just a regular old phishing email saying, you need to update your information at apple.com and even if they look at the URL, which lots of users don't, and they're like, 'No, it's apple.com. All right, click.' And they go to the site. Even if they look at the URL bar, which most users don't, yeah, apple.com. Like you say, unless they literally open the certificate information, and even that, who knows? Maybe the certificate says apple.com, but it's using uppercase mathematically or whatever. There's a lot of ways to fool non-savvy, or even savvy users. Having described that whole chain of things, how many of the people who are listening to this podcast wouldn't necessarily catch that?
Brian Kardell: I would not. I don't think that most human beings would. Even very, very tech savvy people would completely miss that. The real story here is that that is very difficult on its own. It's difficult when you add that it's coming from an OS level looking dialogue.But where this gets really, really, really snarly is with cross original frames. You've added a whole nother level of things that we can't communicate. People don't understand, this is not coming from the page you're looking at.
Eric Meyer: You might have something else.
Brian Kardell: It could be from anywhere who happened to get a third-party IFrame into your page. Because from the third party, you can present something top level. Not just top level but top level and can be confused with the operating system or browser level dialogue. This long been a known thing. This is not a new thing. This has been discussed for a lot of years and it was nobody's first choice to want to just be like, let's turn them off.
Eric Meyer: Let's turn off prompts and confirms and alerts in cross origin frames. Which is what Google had initially proposed to do. It wasn't just to switch them all off for everything. It was to switch them off when they cross origins.
Brian Kardell: Browser manufacturers have tried a number of things over the years. There've been a lot of really big efforts to try to make that clearer. We've tried a bunch of things and it would seem that those things have not worked. There was a very real problem for real users here, where we're talking about it in this few steps removed way, but I can tell you that I have family members.I know other people in the web community who have family members who have had their identity stolen, their bank accounts compromised. These are not minor inconveniences. These are things that like ruin lives. Lawyers and years to resolve. In the priorities constituencies, users are first, right?
Eric Meyer: Right.
Brian Kardell: If we're trying to solve the problem for users and we cannot solve the problem for users, there is one sure way to solve it, which is to turn it off.
Eric Meyer: If there's an attack vector, if you can block the vector, then no more attacks can come on that vector. Which is what Google was effectively trying to do with this cross origin, or disabling.
Brian Kardell: Everybody went to their respective drawing boards and tried to figure out what is the way to do this. There was a bunch of study. They looked at the HP archive. They looked at, I don't know, seven to nine million sites now. They got data. That data is based on homepages. It's not remotely adequate, but it's informative. They look at what was there and they said, 'Well, that's actually surprisingly low, so let's get some more information.'Then they added some instrumentation, some stats counters to Chrome. These measure what real users are encountering and use. That was very, very low for these specific ones, these cross origin IFrame.
Eric Meyer: Right. 0.006% or something of that magnitude.
Brian Kardell: I think it was even less than that per the cross origin ones, but-
Eric Meyer: Probably.
Brian Kardell: So they made this proposal, like let's do that. That proposal was a year ago. It wasn't now. There were discussions and there were people who went and did manual checking of things. 100 URLs that were encountered. They went and looked at them manually to sanity check the results. In those ones that were reported, that they had the cross origin, they couldn't actually make them viral.So they said, 'It's possible that really a lot of these are dead code. They're false positives.' The number is in practice probably even lower than what we see. All of the vendors said, 'We agree. That would be good and if you do that, we'll follow you.' It was not controversial. It was not a Google decision made in a vacuum on a whim. It took a very long time. There was a lot of research. And there was a way for you to opt out of this. But it turned out that that actually was insufficient. They shipped it and they were wrong.
Eric Meyer: Well, that's one of those fascinating situations of, everything that went into the decision, they were right about. But once it was executed on, they discovered, they ran into the buzzsaw of the internet in part, but also I'm sure that there were cases they hadn't caught that got caught. I think the breakdown honestly is in, there isn't really a way for developers, the global population of developers, to know that these sorts of things are coming down the pipe.Because there isn't a new surface that slices and dices these things and sends them out to people based on their interests. This is a sort of thing that from what I can tell, a fair amount of enterprise internet software, not internet, but intranet software, actually does do sometimes. There are, I don't know, payroll applications that use... They do alerts and confirms and prompts and stuff across IFrames. Whether or not it's cross origin, I'm not an enterprise expert.But there isn't a news bureau that what people can sign up for to say, I'm an enterprise software developer and send me stuff that touches on enterprise development. So that six months ago when this was under discussion, they could have gotten a little alert, no pun intended to say, a little news item that says, 'Hey, there's a discussion about removing these things in this situation. And for them to then go and be part of the conversation.'It's not like I'm saying that that's an easy thing to do, and sure we can say, well, if they'd signed up for the... If they've subscribed to this GitHub issue or they had alerts on this bug repository or whatever, then maybe they would have known about it. But no, there's already too much. We're already drowning in information. Even knowing where to go is often difficult or borderline impossible to figure out. I didn't know about this really, until it happened. And I'm a lot further into these processes than a lot of people.
Brian Kardell: When it broke, the things that broke, once you heard the things that broke, you're like, 'Well, that's really obvious. How did you miss that?' The way that we miss that is two-fold. One is people are humans, humans make mistakes, so we will make mistakes sometimes. To their credit, I think that the team actually received this feedback and they delayed it. They said, 'We're going to go back to the drawing board, think about how we can improve this.'But there's only so many things that we can think of and to think of these things, we need more developers in the conversation. But this is actually surprisingly hard. I started writing articles in 2015, talking about this, there's an economic mismatch of you want better standards. That means you need to be involved. But standards move at such a slow pace and they happen in so many places, that if you try, the information firehose is so big.It's like that scene from the UHF movie where the kid gets shot across the room. It's a lot of information that you cannot possibly be expecting every developer to handle this. What is maybe interesting to know is the other side of the community knows this and we have tried a number of things. Some of them have been reasonably successful. But it is amazingly difficult actually to engage the community in this conversation.
Eric Meyer: Yeah. People are busy.
Brian Kardell: What else is interesting about this is, even if you manage to engage the community in a big way by creating a really simple A or B question, like which one is more important to you, A or B? Or how should it work? Like A or like B. Very frequently when somebody asked one of those questions, many people when they answer the question, they think there is only one right answer to this.No rational person could possibly think that the answer is B. It's clearly A. And yet every time we have one of those and we present it and we get a lot of participation, it is astoundingly 50/50. In the end, that's a little bit terrible because it means that very frequently, we have to make a choice in which roughly 50% of developers are going to think that's a bad choice.
Eric Meyer: And not understand how anyone could have possibly made that choice.
Brian Kardell: Exactly. Exactly. That's exactly what I'm saying. Now take that and mentally reverse it. If you're a developer and say, how do these standards bodies get consensus? What does it mean and how do they work? This is very, very tricky because for standards, there are not a lot of AB questions, complex questions. And lots of people from lots of perspectives. It's unsurprising that to build consensus, we make compromises.We know we need to get a thing and everybody's coming from a slightly different perspective and very frequently, nobody gets exactly what they want. We wind up I think often agreeing that reasonable people could disagree on something. I don't know. Do you have any thoughts on any of that?
Eric Meyer: No, you said it pretty much. It often comes down to a decision has to be made, and there's no clear consensus and you just, you do have to accept that. Some percentage of people are not only going to dislike your decision, but not even understand how you could have arrived at it. That's a thing that you basically have to accept if you're going to do this kind of work. Which I imagine is rough for lots of people.
Brian Kardell: But at the same time, I do feel like if we did better at communication on both those ends, if we could engage more developers, we could get feedback earlier, this is one of the very first things in the extensible with manifesto is, we need to tighten this feedback loop. This is a real problem because sometimes it takes like a decade to get to where we're going to ship a thing and only then do we learn, well, that's not what we wanted. That thing is terrible.That's way too late. We can't start over now. We got to fix that. I do think that if we could somehow do better with the communication and help people understand why a thing was, it would be easier to have the kind of like, I don't like it, but I can understand reasonable people could disagree on this reaction.
Eric Meyer: I think there's also the challenge that getting people involved earlier in the conversation sounds like a solution. But thinking ahead and trying to think through all of the side effects and the permutations is very much a skill, and it's not common, and it's certainly not easy. Even if we'd had a whole lot of people involved in the discussion over alert prompt confirm, there would end up being a whole lot of, we'll just do this. Then somebody explains all the reasons why that doesn't work. Then, okay, we'll then do this other thing. And then someone else explains all the reasons why that isn't going to work and that's very frustrating.
Brian Kardell: This is the thing that you bump into that also makes communication on these committees, even the public stuff really, really hard, is that you will frequently see somebody show up and be like, 'I have a big idea.'
Eric Meyer: It'll fix everything.
Brian Kardell: But you're not the first person to have that idea a lot of times. And you don't know the history or the reasons why that thing isn't being done, or the things that are being done instead. If that's one person every now and then, it's easy to fill them in. But here too, you can't expect somebody joins a working group, for example, to know the entire 30-year history of every CSS decision has ever been made. It's hard to participate without bumping up against that.
Eric Meyer: See the long history of people proposing a parent selector in CSS, which we might actually be getting soon or something very close to it. But it's taken a very long time to even get to the point of coming up with an idea that might be workable. The reasons why previous ideas weren't workable were often only obvious to people who have literally written browser engines, and understand deeply the entire pipeline of how things happen in browsers.
Brian Kardell: This is also really interesting, is that your perspective shifts. I know my own perspective has shifted. I see it differently. Some of the challenges that you're talking about, they're only obvious if you're an implementer. And sometimes the data that you have to work with about what you should and shouldn't work on is difficult too. Here too, reasonable people can disagree. We run these polls all the time. Like, if you could do only one thing, what would it be? At the top of this list is like container queries has all kinds of stuff.But we also did this really large survey, this MDN survey, and it was big and scientific and the thing that it turned up that was most universally wanted really, and painful, was not new stuff, so much as Compat. What's interesting about that is we were able to identify through that, that actually on a bunch of things that are relatively new-ish and people are excited about, there are still places in there where things are under specified and we bump up against the edges of it.Once we have the tests, it seems that no browser, they were all in the 60s basically, at the beginning of the year, and so there's this effort we've been working on this year with others and in the past six months, we've all upped that really, really significantly and I think they're all in the 90s now or high 80s and 90s. But that takes time because really strictly specifying and finding out where the edges are that we didn't even expect. But nobody asked for that really.
Eric Meyer: Yeah. If you ask people, what would you like to see done in browsers, they're going to, like you said, container queries, like cool new stuff. But then if you actually go and ask more in depth, eventually they're going to start saying, what really hurts me is that I do a thing and it works in two out of three browsers. I have to dump it because the third browser is important.
Brian Kardell: That's actually a really great segue into how I think maybe we could wrap this up and tie it back together with the beginning of this. A couple of weeks ago, our friend, Jen Simmons, who's now a developer relations person at Apple. She was formerly at Mozilla and before that for a really long time, everybody in the community knew Jen. She had a podcast and she did a lot of speaking and stuff.But she asked this question that was like, 'Hey, you know I work for Apple and WebKit now, and what can we do to make WebKit better? What would you focus on? If you had the power to call a shot and say, here's one thing we're going to do, what would it be?' That actually generated a lot of not very productive responses.
Eric Meyer: In fairness, there were some productive responses, but there was also a lot of, the best thing Safari could do is just die already, effectively. I don't know if anyone said that in those exact words, but there was a whole lot of unhelpfulness. Because that doesn't help. Well, first of all, Jen is a woman on Twitter and the web in general. She's had to develop a very thick hide for that to ignore that sort of thing, because that happens a lot regardless of whether she's asking things on behalf of Apple or not.When you have someone who's saying, how can we make this better telling them something else, not answering the question is rarely ever helpful. I admit, I used to do things like this. I hope I wasn't as hostile as that. But the thing where someone asks a question and you answer it in some technically correct, but not at all relevant way. I think we would all do a lot better to be more helpful.
Brian Kardell: One interesting bit of helpful feedback that I thought, Dave Rupert tried to respond to this. And he said, 'I think that Safari as the new IE is a tired take. It's not really helpful. Hear how a person who is genuinely asking. I want to try and give them some feedback, so I sat down and thought about it and I wrote this post.'He said, 'I think a helpful way to answer this would be to tell you the things that I'm frustrated with, and they're largely, where I have to do something to appease one browser God. This special way I have to create the sacrifice to make something work in IE6 or whatever browser it happens to be.' I think that's an interesting point actually, that there are things to be unhappy with in every browser and which one is taking the brunt changes, right?
Eric Meyer: Yeah.
Brian Kardell: I don't know, have you experienced that?
Eric Meyer: Yeah. Over the years, there has always been at least one browser that was the most frustrating, furthest behind is maybe not a fair way to put it anymore. But there was a time that IE6 was the best browser on the market. Then there was a time when it wasn't and it gradually became the thing that most people were frustrated by. That's where this whole, is Safari the new IE, is Blog the new IE comes from. But I remember the time when the question was, is IE the new Netscape.
Brian Kardell: I was actually going to say that. I remember when I came along and one of the reasons that it was better is because Netscape had gotten so bloated and slow and-
Eric Meyer: In recent years, there were times when I was most frustrated by Chrome, which most developers will gasp in outrage and at the blasphemy. But it was behind in the areas that I was most interested in. Well, behind Firefox. They're largely a parody now in the areas that I'm interested in, but there was a period of a couple of years where I was just like, I wish Chrome would catch up already.But it goes the other way too occasionally. Safari supports hanging punctuation, which is a property in CSS, and none of the other browsers too. It's not a huge thing, but it does occasionally frustrate me that nobody besides Safari supports hanging punctuation. It makes certain types of graphical things much nicer. It makes certain layouts look cleaner when it's supported.At some point I was doing a thing where I was making extensive use of hanging punctuation to make it look what I thought was better and then when I first loaded it up in, I don't know, Firefox or Chrome or whatever else I was checking it in I was like, 'What the...' All right. I don't support a hanging punctuation. Grr. Shakes fist at sky, and then move on. I don't want to try to say that what Dave had to say can be boiled down to a single sentence, but I think part of what he's getting at there with the, what frustrated me or the things I have to do to appease a single browser god is really, it comes back to like Compat 2021. There're Compat problems. There're compatibility frustrations. I could see where a useful bit of feedback for Jen would be, if I were making the calls, if I were calling the shots on WebKit, I would say, invest everything in catching up with Chrome and Firefox in terms of what they support. So that there are fewer of those frustrations across the board, where people say, all right, I did a thing and it works in these two browsers and then I tried it in the third browser and it didn't work.And I have to figure out how to either do the right incantations to make it work, whether that's a WebKit, prefixed property in CSS or it says some kind of, I have to write a polyfill or I have to find a polyfill and JavaScript to make the thing that I was doing in JavaScript worked for whichever browser isn't supporting that. Less of that I think would make developers on the whole a good deal happier. In a way I think probably the deepest frustration is what you were talking about from the MDN survey and what Dave was getting at, which is compatibility. It's always the biggest frustration, I think.
Brian Kardell: But then also, how do you keep up with that?
Eric Meyer: Right, that part's not easy, certainly.
Brian Kardell: Dave's follow-up podcast on the Shop Talk Show, they talked about his answer to that and the fact that along the way, when he posted that blog, he learned that some of his pains were no longer pains anymore. He was still frustrated.
Eric Meyer: He was still working around things that he didn't have to work around.
Brian Kardell: Exactly. So this is part of the firehose problem. How do you know?
Eric Meyer: He was the driver that knows to go around the pothole and keeps doing it even after the pothole has been fixed.
Brian Kardell: Exactly.
Eric Meyer: And How do you keep up? That gets back to what we were talking about before. It would be great if there were a central news bureau that could keep people informed about this, but there isn't and to some extent, I think that would be very difficult to create.
Brian Kardell: We do this thing with the TC39 has educators group. We have this two-minutes standards, standards in two minutes and it tries to do that. Only very, very high signal to noise. We only write about something and tweet about it when there's some development that becomes serious enough, that really all developers should know about it.We try not to give two years before the thing when it's stage one. We try not to add to the firehose. We say, when it becomes pretty real, then we write one post and that post has to be 500 words or less, or two minutes of video or less. And the idea is to make the firehose manageable. If you're drinking your coffee or tea or whatever, your morning ritual where you scroll through Twitter. If you see one of those tweets, you can open it and you can know, I can consume this because it's going to take two minutes of my time.It's not a 45-minute talk or a blog post that I need to really get in the right space for. It gives you just what you need and then links you to more information so that you can move on with your life for when you actually have that problem, you know where to look and what it is. I think there are opportunities for us to do better here and I'm hopeful that we'll come up with some... I've seen some interesting ideas already.
Eric Meyer: Cool. I'm all for it.
Brian Kardell: Okay, I know we've been going on for a long time and I do want to button this up, but there's one last thing I want to mention here to close this out. We talked about Compat and prioritization and things. There are efforts to find better ways to look at what that is and measure these things and plan better.We have these big Compat tables that are generated and kept up to date. They're not perfect, but we're doing things to improve that too. Some people like Paul Kinlin at Google and Phillip Jägenstedt, I think most people know him as foolip. He's former Opera, now Google, they've been working on some interesting ways to maybe look at this and visualize it.But what's interesting about this is that you can begin to look at this and when you look at, for example, CSS, you can see that things are actually a lot more ragged than this conversation would have implied. There's lots of things that are supported by two of three engines. It's not remotely, exclusively Safari that's lacking them. It's not exclusively WebKit. There is a very non-incident in a number of things with specs and tests and things that are implemented in zero to one browsers too.I mentioned this not just to be fair, but to again, stress just how much of this has to do with the fact that every team is trying to prioritize limited resources and the limits are very different. But when Jen or Una or someone asks, if you could pick one thing that is why: Every team would love to do them all, but actually no browser team is as big as it would like to be. That is one lever that's completely out of their control.
Eric Meyer: Yeah. It strikes me as odd that we talk about resource constraints when it comes to three of the biggest companies in the entire world. For me to even say, hey, what I would do if I were in charge of WebKit is beef up the staff, I would throw more resources at catching up. It's a multi-trillion dollar company. How do they not have those resources already?They don't. Browser teams are not the entirety of their companies, even at Google. Google has a lot more of its business model dependent on the browser than Apple does, or Microsoft for that matter.
Brian Kardell: Also interesting thing here that we blow right past in these discussions often is that as users, we want the investment to be at least as big as the current biggest one. That's really interesting because that's what much of our podcast series has been about, the economics behind it all. It's nice, I guess to say, I wish Apple invested more heavily, and me too, actually.It seems like they could afford to. I'm also willing to admit that this is not their only priority and there are plenty of things - if you examine my own finances, similarly, that you could say, why don't you spend more money on x? You can totally afford to. But isn't this a commons that we're building and wouldn't it be healthy if the system we built to support that made sense for a commons? If you haven't listened to others, I hope you check them out and find them interesting. Anyway, I'm really glad that we got to do one together. I hope we do more. Okay.
Brian Kardell
Eric Meyer