Brian Kardell: Okay. Hi, I am Brian Kardell. I am a developer advocate at Igalia. And this week we have very special guests. Guest, do you want to introduce yourself?
Eric Meyer: Hi there. I'm Eric Meyer. I'm a developer advocate at Igalia. Thanks for having me on, Brian.
Brian Kardell: Sure. So that's a little bit confusing since Eric and I are co-hosts, but Eric is on the Interop committee and I'm no longer there. So normally we do one of these shows and we just talk about it together. But actually I'm going to interview Eric because I'm disconnected from that right now. So Eric, tell me what is the state of Interop right now?
Eric Meyer: So yeah, so Interop for those who might not be familiar is a yearly, well, it's an annual project by various browser makers and other involved parties to basically ask the community, what would you like to see that be more interoperable? Okay. So there might be a JavaScript API that only two browsers support, two major browsers, and the third one doesn't. And so someone can propose this JavaScript API is super useful and the problem is that one of the three major browser engines doesn't support it, so we still have to polyfill it and shim it and blah, blah. Anyway.
Brian Kardell: Or all three can support some CSS property and they all support different parts of it so that effectively they line up where almost nothing actually works.
Eric Meyer: Yeah. So it's things like that is what it's meant for so that the browser vendors can, the browser engine makers can come to consensus on what they will focus on in the next year. And there's a graph that shows here's what the Interoperability total score is and how it changes over the year. If you look at the 2026 graph as we're recording this in mid-October.
Brian Kardell: Mid-October.
Eric Meyer: Yeah. Just the things that we're being focused on for the Interop project had an overall Interop score of 39.9% at the beginning of the year. And as I say, as we're recording this, those things have aligned so that the Interoperability score is now 97.2%. And that was over things like CSS Zoom and custom highlights, dialogues and popovers. So maybe at the beginning of the year you might be thinking, I was using dialogues and popovers a year ago, but maybe as Brian was saying, every browser supported a different part of dialogues and popovers and they didn't overlap very much, but now they should overlap a lot and be much more consistent between browsers. So anyway, that's what the Interop project is, broadly speaking. And so where we are with the 2027 Interop process is that there was the window for the open call for proposals, which was the first three weeks of September, more or less, in which there were, I think it was might be 160 proposals. It's over a hundred proposals.
Brian Kardell: That seems to be a pretty consistent-ish rate, like 150 to 170 every year.
Eric Meyer: Yeah, at least for the past couple years or past few years.
Brian Kardell: Yeah.
Eric Meyer: And it might be a little lower. I don't remember the exact, it might be 140, but yeah, somewhere around 150 usually every year is the number of submissions that come in. So now the Interop people involved in that will be going through those proposals. There's a first cut where basically it looks at, okay, this proposal would be interesting, but it has no tests. So there's no way to verify what the Interoperability is now, let alone how much it improves over the course of time. Or maybe this looks very interesting, but the relevant working group has said that they're not done yet. So those are the kinds of projects that as interesting as they might be, tend to get dropped very early in the selection process, which is-
Brian Kardell: Or it's not on a standards track, right?
Eric Meyer: Right. It's not on our standards track at all. If somebody says this thing that a browser did that has never been written down anywhere, all the other browsers should do it too. It's like you might be right, but that is not what the Interop project is for. That's not what we do here. But it goes through a selection process over the course of several weeks where different browser makers might advocate for different proposals, usually heavily weighted towards the things that they support or have proposed, but not always. And then it gets winnowed down and the-
Brian Kardell: So when you say champion, what does it mean to champion it?
Eric Meyer: Present the case so that making the case for proposals is distributed among everybody.
Brian Kardell: Exactly. So championing just means you're the-
Eric Meyer: You're advocating for it and do the research and say, 'Okay, this is how many platform tests there are right now. This is how many tests are in web platform tests and here's how many pass Interoperably as opposed to here's how many don't. Here are the other developer signals that we have, the number of people who commented on the proposal or the kind of conversation it's gotten. Here's what we are getting in our developer outreach efforts, the kind of feedback we're seeing.' Whatever the signals there may be.
Brian Kardell: Exactly. Yeah.
Eric Meyer: You put together a three-minute presentation, just like here's why we think Interop should take this on in 2027. And then that goes through and goes through the process of other browser vendors maybe saying, 'Yeah, awesome.' Or we're going to have to talk to our engineering team about that to see if we have the bandwidth for that. Because the hard reality of this process is that if 150 proposals are made, we might get to pick 15 to 20.
Brian Kardell: Yep. Why is that, that you only-
Eric Meyer: I mean, it's because resource constraints. We'll just say it, even Google who has the best funded browser team by a pretty notable margin only has a certain amount of time in a year and they only have the expertise that they have so that if there's an Interop proposal that requires expertise that they literally do not have, then they might say, 'We don't know if we can do that this year.' And it's not only Google that says that. Every browser team at some point will say, 'As much as we'd like to say yes, the engineering team says that we can't. Given all the other things that we need to be doing in 2027 and the other things that we've already said that we're going to do in Interop, this one is unfortunately just not going to make the cut.' There'll be many proposals like that and from different teams will come me, 'We're sorry, we can't.' Well, that indicates a lack of consensus and so that proposal doesn't move forward.
Brian Kardell: So the one thing that I think is really, really interesting to talk about, and we can talk about it a little bit in the history of this project as well, is how you decide. And you mentioned developer signals. And early in this process, earlier in the history of this project, we didn't discuss them together. It was just like you vote, just like every individual one voted and how or why or what they're basing that off of, why they thought that was a good thing was opaque. There weren't presentations and stuff, but now I think it's been at least three years because I haven't been involved the last two and it was happening then the last time I was there was the presentation idea and discussing these. And then I think last year also a really cool thing happened we can talk about, which is Jake made a stack rank. Jake Archibald joined and made a stack rank thing.
Eric Meyer: Which he has redone. He's done it again for this year. We'll put it in the show notes, but Interop-rank.jakearchibald.com where you sign in via GitHub and then you can drag proposals up and down.
Brian Kardell: I think there's a Mozilla URL for that now as well.
Eric Meyer: Probably is, yeah.
Brian Kardell: It's funny because when we started this, we were talking about, well, these are the signals I'm seeing on Twitter at the time, I think it was, or these are things I hear when I go to conferences and I talk to developers or these are things that people whose blogs I read are talking about a lot. These are the GitHub stars. These are the chromium tracker stars. You know what I mean? There were so many signals and how you put them together. Every year we pick 15 and it's complicated. It's complicated. And I think the nice thing about what is happening now is I see developers blogging about their feature rank choices.
Eric Meyer: Yeah. That has been a little bit of more of a trend this year, it feels like, is people just putting out, 'Hey, I ranked my preferences for Interop and here's a blog post listing them and explaining why I picked what I picked.' Which real strong developer signal. And like you say, Jake's ranking tool, which I think is what a lot of the people who are blogging used to come up their list is also very strong. The more people who participate in that, the stronger that signal becomes because then the Interop team can look at that and say, 'Well, 90% of the people who use the stack ranking tool ranked this particular focus area number one. That's huge.' Or of course we could also get the, 'Well, there's a stew of things that are about the same ranking, but only these seven have that same level of 20% of people said that these would be important and then it tails off, whatever.'
Brian Kardell: So I really like the tool and the thing that it forces you to do because in the committee, that's exactly what we have to do when we're doing it ourselves, when we were the ones doing it. And you have to cast a vote. These are signals, but what I like the most about this is I'm aware of, let's see, six or seven different blog posts with people's picks, right?
Eric Meyer: Yeah, at least.
Brian Kardell: And the thing that I will point to is that nobody has the same first one.
Eric Meyer: Okay. Yeah.
Brian Kardell: So Sara Soueidan has the HTML focus group attribute is her number one thing. Ana Rodrigues has random. There's border shape. There is customizable select. There is targeted SBG improvements. There is ad function. Yeah. I mean, there are just so many takes on this that are not anywhere close to one another. And actually, if you look at even their top three or five, they're not the same. And so it really points to the tension in this problem, right?
Eric Meyer: One of them, yes. A pretty big one. Yeah. One of the tensions being that everyone has a different opinion. So because scrolling through the list on Jake's stack ranking tool here, I happened to fall on CSS gap decorations. There's going to be somebody who's that's their number one thing because they have wanted it for 10 years ever since grid was a thing. They wanted to be able to put decorations in the gaps without having to fake it. And maybe that's me and I might put that up there. And then somebody else is looking at this and says, 'Oh my Lord, single access scroll containers would solve the biggest problem I have with my major project.' So you're going to run into that. There's one about performance long animation frame timing entries in the performance API. I can easily envision somebody who would want that first. One of the ones that I know that I would personally rank highly, even though I would rarely if ever use it, is the temporal API. Now, granted, that is a thing that Igalia did a lot of work for, but that's not why I would pick it. It's just such a great replacement for the date object in JavaScript, which even as someone who doesn't know JavaScript very well, I know that the date object is terrible both from having worked with it and having read people explaining in detail why it's so terrible and temporal is amazing. And I just would like to see that for the web in general. Like I say, I'm probably going to rank it highly when I go through this. And it's not because I'm going to use it every day or even every month. It's just because I think that that's super important.
Brian Kardell: It's because when you do need it and you need something even remotely nontrivial, you don't want to import a giant library or have to figure out all the nuances and flaws of date and locales. And it gets very, very complicated very quickly.
Eric Meyer: Yeah, it does.
Brian Kardell: One of the things that I think is cool is Ana Rodrigues showed maybe another tension, which is she actually gave three different lists. She gave how she actually ended up voting, but then she admitted that there's a tension. She said, 'If I had a rank of things that I want just for pure fun and selfishness, this is what they would be because they're things that give me interesting new powers to do creative things with.' But then if I am honest about what makes my life easier at work and what are our most frequent requests from clients, it's a different list. And so her final vote, I think tried to balance those somehow. But you see, even for a single person, it's very, very, very difficult. And yeah, I don't know how much time people spend really thinking about all of these, if they even know about all of them. Probably you recognize a few things. You're like, 'Oh yeah, I've heard about that. That sounds really important. That sounds really interesting. It grabbed my attention. Let's move that way to the top.' Or like you said, you've wanted gap decorations for a really long time or you have this really great idea of something that you could do with masonry.
Eric Meyer: Yeah. And there's a lot in here that I'm probably not going to rank because either I don't know or I don't know enough or I don't care, which is fine. That's why we want as many people as possible using this tool and tuning about or blogging about what they think is important and why. Because the why is almost as important as the what, because if half the people are saying, 'We want gap decorations because they sound cool.' It's very different than, 'We want gap decorations because in our last three projects, we had to literally construct basically separate grid tracks that were one pixel wide and had a one pixel spacer GIF in them in order to keep them open and have the background. And that's how we created a rule between two columns. And if we didn't have to do that, there would be less demand on the network. You can go through a whole thing.' That's a much stronger signal, at least in my opinion. I do not speak for the entirety of the Interop project here or even anyone besides me, but I think that makes sense to most people. It's the, 'Oh, that would be cool.' versus, 'Oh, that would allow us to reduce the size of our HTML CSS network load, et cetera.' Those are very different arguments and very different signals at least to someone like... Anyway. And yeah, one of the things that interests me this year, there are a lot of CSS functions that are on this list, like literal function values. So just to pick an example from near the top of Jake's list, at least when I loaded it, the CSS random item function, which is you can say value, random item, and then parentheses put in whatever is allowed in the parentheses. A whole lot of CSS now is functional values, which I still continue to feel some kind of way about, but that's a completely different topic. There are many other functions. The CSS ident function, which I don't actually even know what that is exactly. I saw the proposal and I have a half-baked idea of what it is, but I would need to... This is another reason why it's really good to have champions. If one of the teams, let's say the Mozilla team says, 'Yeah, we really want the ident function.' Having a three-minute presentation of here's what it is, here's what it does, here's why it's important, is really useful for people like me who maybe don't know that or the HTML focus group attribute. I have a vague idea of what that probably is, but it's a huge help to know that if somebody's going to champion that, they'll give it the attention to be able to say, 'Here's why you should consider this. You should consider ranking this within the group.' Because there's too much for any one person to know the details of every single one of these. So that does become very useful.
Brian Kardell: I will say that as a voter, I have voted already and my picks were very, very close to Sara's, not necessarily order, but they contain the same things. She has responsive i-frames as number 15. I know mine was higher. She has customizable select as number eight. I know mine was higher. And she has reading order and reading flow as number 12. They're both higher, but the rest is very, very similar. So she has the HTML focus group, ariaNotify, HTML heading offset reset, and the heading pseudo class, interest invokers. And I just want to mention these are all things that are trying to meet developers more where they are to help them get things like accessibility correct. And they're not only about making the window prettier, they're about making it more correctly functional and more semantic and less easy to screw up effectively. So rather than requiring complex ARIA patterns and JavaScript, the focus group says, 'Okay, I'll manage all that stuff that you were using, like roving focus patterns for... I'll just make it easy as declarative attribute.' And headings, we've talked about this, we have a whole show on it. It's the oldest problem in HTML, but also it's impossible because if you pull in some content, you have to know the context it's used in to give it the correct heading. And it's like, 'You know where you are in the page, just figure it out.' So fixing those problems, I think, again, meeting developers where they are, making it harder to screw it up, and paying attention to things like accessibility where... I mean, I'll just mention we're going to be doing a show live from TPAC this year with a panel, and part of the stuff that we want to talk about is this where our ideals meet reality. Everybody says this stuff is really important. MathML was in every year. MathML Core was in every year. I don't think it is in this year because it is getting done, thanks to a sovereign tech fund funding. We proposed that because it couldn't get done in Interop, and the proposal was just like, it's really, really hard to prioritize these things that everybody agrees are important, but they're not... When you stack rank them, when you compare them to other things, they always lose. So it's like these things are things that I think are important that will really help developers. And yeah, so this is my plea to go and read Sara's and vote in a similar way. Put your vote where your ideals are. Vote for the underdogs that won't probably make the cut otherwise.
Eric Meyer: Yeah. I mean, I haven't done my ranking yet, like I said, on Jake's tool, but just of my first very quick pass going through and just clicking on things to put them in my actual stack to rank, I have almost 20. I have already triggered a warning from the site itself saying, 'Whoa, that's a little too much.'
Brian Kardell: Yeah, I did too. I did as well. Yeah.
Eric Meyer: They'll still use the data like they say when it's like, 'Yeah, that's maybe the meme, pick your battles. Okay, that's too many battles. Put some battles back, still too many battles.' Anyway. Yeah. Another thing that interested me this year is there are quite a few proposals around Shadow DOM and not just Shadow DOM, but this specific thing about Shadow DOM. So as an example, there's a-
Brian Kardell: You're about to say one that's on my list that isn't on Sara's list actually.
Eric Meyer: Well, maybe because there are several, like I said, there's a CSS has slotted pseudo class, which is, I'm going to say not on my list, but that's in here. There's also... What are the other ones? One of the things that I wish is that these also had tags, so a Shadow DOM tag for everything that's involved in Shadow DOM and then a CSS or selectors for every CSS selector. Anyway, anchor positioning across shadow roots is another one where I guess the idea is that an element in a shadow tree can reference anchor names that are outside the shadow tree, which okay, I can envision why some people would want that.
Brian Kardell: I mean, this is a big problem with Shadow DOM, and I've said a number of times that I think that the... I don't know if I said it on here, but I've definitely said it on social media, that I think somebody's going to be mad that I say this, but I think that closed Shadow DOM was ultimately a mistake and I think that the design decisions... And to be clear, I was totally supportive of it, but I didn't know that vendors would really demand that they're basically identical and that the design implications that that imposes mean that it is so hard to do really common seeming things like to be able to anchor to something across the Shadow DOM or the one that I thought you were going to say was the reference target, Shadow DOM reference target, which is there are things that you make like a custom input or something and you have a label that's outside it and they need to connect, you know what I mean? They need to. The label is for the thing inside the Shadow DOM or vice versa. And crossing the Shadow DOM is either difficult or impossible depending on which direction you're going in. And so yeah, that is also on my list, the Shadow DOM reference target.
Eric Meyer: Yeah, which sounds absolutely reasonable to me. But I mean, that's the thing. Pretty much all of these are reasonable at some level. Some of them might be less personally relevant to me. I might not be as up on why they might be interesting, but I don't think I've seen a single one that I say, 'What is this? Why is this here? What are you doing this for?' There might be some that going into it, we discover, like we said before, 'Oh, there's no specification for this.' or, 'Oh, there are no tests for this.' So we can't pick those. Those things need to exist before they can be part of this project. But that's not the same as this is unreasonable. It's just this isn't ready yet. It might be totally reasonable and just not ready, things like that. So yeah, I like the fact that people are blogging it and I'm looking forward to actually having all of those compiled in the show notes because in the list that we've shared, you had a couple that I didn't know were out there. I had one that you hadn't seen, stuff like that. And I think there are at least a couple more that I've seen float through my feed reader, but I haven't tracked them down yet. But yeah, these are all really good signals. And so that's where Interop 2027 is right now is in that compiling what the signals are and helping figure out when the team gets to the end of the process, which is the okay, we've it down to these 50 that have tests and have specifications and have clear Interoperability concerns and have interest that nobody said, 'No, we're not going to do that.' We still have to narrow them down, like 50 is too many. That's when the team itself gets a little banner that says, 'Whoa, that's a lot, maybe fewer.' And yeah, that's when it starts to come down to, 'Well, we've seen a lot of developer interest in this one, but we haven't seen a lot in this one, so we're going to go with the one that probably that has a lot of developer interest and then the one that seems to have less developer interest.' Even if it doesn't make the cut this year, it's not like things go onto a deny list if they haven't been picked. In fact, JPEG XL, which is a 2026 investigation area, was proposed for several years in a row and did not make the cut until Interop 2026 when it did, like I say, I think if I remember correctly, it was called an investigation area, which is where sometimes things get put if, wow, this does seem very interesting and there does seem to be a lot of signal around it, but we're not entirely certain what we can do. So an example of another investigation area is accessibility testing. It's very difficult to do automated accessibility testing. Lola Odelola actually just has launched a project to make that better with the accessibility compatibility data project, but it's also testing mobile is very difficult to do in an automated, measurable way, especially when it comes to things like there's a proposal in the Interop process this year for, what's it called? The device posture API, I think. Yeah, reflects the posture of a device such as whether a foldable device is folded in both CSS and in script. So you can have a test for whether or not that API is recognized by a browser, but how are you going to do an automated test on whether or not it's properly dealing with the way that a foldable device is folded. A lot of things that are investigation areas are like that, but sometimes there's a lot of signal and we're interested, but we don't know what kind of engineering it's going to take to make it happen in the browsers that don't support it. Or sometimes it can be a, let's put a pin in that. Anyway, JPEG XL ended up in active investigations and has a 78.3% Interoperability rating right now. And I think if I click on it it'll tell me where we... No, it doesn't do that. No. But there was a lot of progress this year. In fact, this morning, just before we recorded, I saw that Firefox had posted on social media that the latest release of Firefox has, I think, progressive JPEG XL rendering their shipping, which they didn't have before. I guess they had JPEG XL support, but not progressive rendering of JPEG XL. So that could get counted in this look. So anyway, point being-
Brian Kardell: It's interesting because part of this is we're voting and anytime you have voting, it's somewhat of a popularity contest. Part of the challenge is just getting people to vote. And so here I am saying, 'Here's why I think you should vote for these things because nobody else will and they're important.' Everybody wants to vote for the tax cut, but nobody wants to vote for the thing that's hard or whatever, but that we really need. The thing that surprises me is that because of that, you do get these almost like outliers in the data sometimes, like JPEG XL, where I really do not believe that JPEG XL is that demanded, I guess, as it appears. It is just that the group is very passionate. So basically all of the people in that community who want it are like, 'Go poke it.' And I mean, the data that I have to hold that up is that MathML was in the top few, and I 100% don't believe that MathML is in the forefront of people's minds. It just is that the MathML community is pretty strong and they all, we told them, 'Go vote.' So we had better get out the vote effort basically. And I wonder if there's anything in here that strikes you as you think it could be a thing like that. To me, I wonder if WebUSB will be like that. I don't know that that many people... I've never heard anybody be like, 'Why can't we have the WebUSB except for a pretty small group of people?' But you might also have a noisy group. And so I guess that is another challenge to this. It makes it very difficult. How does the committee identify those kind of things and account for them somehow? Or do we not? Do we just say, 'Well, you had the opportunity to vote and this was your vote and thank you so much. That's what we're going to do. Next time you should work harder to get out the vote.'
Eric Meyer: I mean, I don't think anyone will put it that way, but I would imagine that there will be things that will not rank as highly because they don't have a committed community coming to vote for them. And there will be some, you're right. It was clearly visible in the GitHub issues in past Interops that JPEG XL, I think Chris Coyier published data and it was like JPEG XL had 10 times more likes than the number two. Not because JPEG XL was 10 times more popular than the number two, but they had very committed fan group. Nothing against that, just they do or did, probably still do. So are there things in here that might benefit from that? Maybe the couple of SVG related things possibly. I don't think it would be on the same scale, but people who are in SVG tend to be pretty into SVG.
Brian Kardell: That's true. That's true. Yeah.
Eric Meyer: Which is what it takes. It's like people who are into JPEG XL are really into JPEG XL and people who are really into other stuff, MathML, like you said, people who are into MathML are typically really into MathML. So there might be a few like that. And is there a huge WebVTT community or a passionate WebVTT community? There might be. That's one of the proposals.
Brian Kardell: WebDriver BiDi is another one. It is important if you don't know BiDi is bidirectional, so you can communicate bidirectionally.
Eric Meyer: Between?
Brian Kardell: Between Web Driver, which is the way that you write tests to script the browser. So they're privileged. You need to have installed a separate thing and you access it via Python or Java or whatever. But yeah, anyway, it's not something that you can use on the regular web. It's used by web platform tests or what is the one that Microsoft has that's for testing? Playwright. But it's not for use in just the browser. So if that gets a lot of votes, I would expect that that's a community of people rather than a representation of web developers at large. You know what I mean? Because web developers at large by and large won't use that. It will improve their quality by making more things testable and so on. But yeah, anyway, BiDi is a thing that I really dislike because we have two things that are coming about at more or less the same time. There's bidirectional text. So we talk about BiDi in terms of text and then you talk about BiDi in terms of web driver and they're completely different.
Eric Meyer: Yeah. This is why I often have to ask for clarifications. 'Hey, let's talk about BiDi.' It's like, 'Okay, which one? Because I'm used to the CSS one a little bit, but not the other one.' Oh, color gamut mapping.
Brian Kardell: I was just about to say that one is another one.
Eric Meyer: That's one that, again, people who are into color gamut mapping are really into color gamut mapping. And so that might get a little bit of a push, but there's nothing wrong with that. I think the Interop team is very aware of the dictum that the results of a poll tell you what the people who took the poll think.
Brian Kardell: Yeah. I don't know if we make the results of this public, but I know when I was there, I argued, and I think we said on this podcast in other ones that the reason why we chose the ones that we chose is it's complicated because people were like, 'Share the voting sheet.' And it's like, I don't know what you could tell from that, honestly. Why you voted for any of these things is complicated. Why this one got chosen and that one is like, we have to consider so many things. These are all just individual inputs. And so it's totally possible that the number four thing that people vote for might not get chosen. That's what happened with JPEG Excel for a couple of years. And that's what happened with MathML. MathML was also very high up there and didn't get chosen either. And it's like, why not? I guess that gets to the thing I was asking. Is it a democracy? And the answer is no, right?
Eric Meyer: No.
Brian Kardell: Because it's full of complications in that it's not even just about what we pick, but it's about who has the work to do and who has the people to do it. We're trying to pick a set of things where the engineering teams we think can get these things done in a year. So we want to get as big a list of things as we can that people are asking for, that are ranked highest, that we also can have the people to hopefully get it done.
Eric Meyer: Yeah. And like I said before, something not being picked does not mean that it can never be submitted again. Things can be submitted year after year and that in itself is a signal. If a given thing, let's say, because I happen to be looking at it at this moment, the connection allow list header, let's say it doesn't get picked this year, but it gets submitted again next year and it doesn't get picked next year, but it gets submitted the year after and every year it gets submitted, it gets proposed. There's-
Brian Kardell: It's a bigger signal.
Eric Meyer: There's a bigger signal and maybe in each subsequent year, there's more information in the proposal. Okay, well, it was just one browser, now it's two, but they're not very interoperable for, I don't know how that would go, but these problems are showing up and here are the things that people have written about it and that developers have tried to do and this Polyfill came out recently. Those are all signals and they might help in each year. It's like, okay, well, now there's more information about why this would be important. Now here's more information in the next year why this is important. That is the kind of thing that leads to an increasing signal. I can understand someone who really wants connection allow list header interoperability today would be very frustrated by the idea that they might have to propose it for three to five years and then wait another year for it to become more interoperable. But sometimes that is how it goes because there's-
Brian Kardell: Frequently. In fact, if you're waiting for something because of a project that you're working on right now, that means don't hold your breath. Find another way because it's probably not going to happen. And by the time that thing gets delivered, you might not even work in this industry anymore.
Eric Meyer: But we'll say, if you-
Brian Kardell: Every time you're getting more raw materials.
Eric Meyer: And I will say, if you're in a situation like that, and I know you agree, where you really want to use a thing on a project right now and you realize you can't because it's only supported in one of three browsers or it's supported in three, three browsers, but very inconsistently, whatever it is, blog about it. I'm not kidding. Or do a YouTube video. That's fine too. Whatever it is, talk about this is why I wanted to use this thing and this is why I couldn't.
Brian Kardell: Yeah, totally.
Eric Meyer: That's a developer signal.
Brian Kardell: Totally. Yeah. And if it's something that's getting submitted for Interop and it gets chosen and you have a year left on your project, then maybe if it's an internal project and you can dictate what browsers get used and all that kind of stuff, then sure, that's doable. But I wanted to say too that the value in this project that I don't know that anybody talks about is bigger than Interop itself because collecting all... I don't know that there ever has been an effort to actually collect so many signals and so much data from developers on a regular basis. And I think that all of the vendors getting together to discuss not only what things there are, but also signals about their own plans and their own availability and developer signals, I think totally plays into their planning. And even if it's not chosen for Interop, if there's few things that just didn't make the cut or that were a surprise that people went, 'I didn't realize people need that so much.' they're still going to internally try to get that stuff done.
Eric Meyer: That has happened.
Brian Kardell: Yeah.
Eric Meyer: I think with anchor positioning, I think I might be misremembering, but I feel like with anchor positioning, it was not picked in a year because the working group was still talking about it, was still discussing how it should behave. And they were down to the last bits, but those last bits were being difficult to resolve and the timing was such that it couldn't get picked for Interop for the next year. But then those things were figured out and browsers started implementing it so that by the next year, the proposal wasn't let's do anchor positioning. It was, let's clean up anchor positioning. Here are the tests that are failing. If it hadn't had that strong signal and hadn't been talked about between the different browser teams as part of the Interop process where they said, 'Yeah, we know developers want this. We've seen the signals, but it's just not ready yet. We wish we could pick it, but it's just not ready for this year.' Yeah, I'm sure that helped with their planning to say, 'Hey, we need to block out time for doing this, because even though it's not an Interop, it's still something the developers and designers really want.' So yeah, there is that. And I will say there are quite a few decisions like that in my experience over the years where literally there will be this moment of heavy silence where everyone's just like, 'We really wish we could pick this thing, but it's not ready. We can't.' If we do it where we're opening up the possibility that we pick something that ends up in working group rewrites for a year and at the end of the year, we can't have improved that score. Maybe things will have even gotten worse and we don't want to pick things that are unknowable in a sense. We don't want to pick things that are so unsure. The ideal Interop focus area, which is not all of them, but the ideal one, at least in my opinion, is one that has a specification, it has implementations, but they're not interoperable yet and it has tests. It's one of those, 'Yeah, we've said for years we should all get around to doing this. This year we're going to commit to actually doing it.' To me, that's the ideal Interop. Like I say, there are others. Sure. There are ones that are like, 'One browser has implemented this, but it's got the standard nailed down. It's got the test. It's ready to go. Everyone else is interested in doing it. We're going to put that on the list.' That's fine. But one of the ones on here that to me is an ideal project is a CSS box-decoration-break, remove the vendor prefix. That's it. That's the whole proposal is just to make it so that we don't have to say -webkit-box-decoration-break. We can just say box decoration break and that's fine. Because again, it's one of those... It's a small project probably. It's a relatively minor thing to unprefix the CSS property. And probably the various browser teams, people inside those at various points have been like, 'Yeah, this is one of the last things we have with this prefix. It's been there for a decade and a half. We are not even webkit, but we still have to support it. It would be really nice to unprefix this. We should get around to doing that, but there's always something that has a higher priority.'
Brian Kardell: Line clamp is removing a webkit prefix as well. I mean, it's getting rid of a thing that currently required webkit prefix, right?
Eric Meyer: Yeah. It's replacing it with something that's actually more featureful. So that's also a good one because it does say we don't have to prefix this anymore. And also the thing that is unprefixed is even better. But yeah, so that's another good one. That's just to me personally, again, speaking for myself, I like Interop best when it's cleaning up the detritus of the past and making things a little cleaner and simpler, but it is for much more than that. One of the ones in here, one of the proposals is for grid lanes, display grid lanes, which creates 'masonry layouts' or waterfall layouts if you prefer, and I do. Yeah, that's in here. That's pretty new. It's not like we have five years of display grid lanes and there's still some weirdness around the edges that makes it hard to rely on and it needs to be cleaned up. That's a proposal people can vote for.
Brian Kardell: Also the reading order thing, again, I don't know the status of that currently, so I'm not sure if it's ready, but here too, it goes to what are your priorities? And I mean, I really want the grid lanes masonry thing to ship, just like I really wanted grid and Flexbox to ship. But with those, I suggested let's just not ship the thing where it can reorder because we don't know how to do that accessibly yet. And if you're like, 'Here's the coolest feature that you can possibly imagine, but also don't use it because it's a foot gun.' nobody's going to not use it. Everybody's going to use it. And so yeah, I would, again, just encourage you to go put that reorder thing much, much higher so that those things, we have accessible ways to deal with things like masonry, which is going to reorder your DOM. I should probably wrap it up, huh?
Eric Meyer: Oh, yeah. It does look like we've gone for a while on that, but yeah, I encourage people to go rank the things that they think are important. And it is a long list, but it's nice in that the way it's set up, just to try to lure people in as you scroll through it and you see something that you want to put in your rank and you're like, oh okay, you click a plus button and it goes up into the place where you actually do your sort ranking. And then like I said, if you're like me, you get up there and it says, 'Whoa, maybe too many.' I mean, you can still rank all 27 that you picked if you want, but that's a lot.
Brian Kardell: We didn't even get into the challenges of taking this data and figuring out how to use it in terms of counting the votes because there are and different ways to count votes in stack ranks and they yield different results and some of them, the first, second, third, they're worth so much more than everything else. I would just say that focus on a good top five. Force yourself to make hard choices and get the top five in the order that you think those really go. And then you can get a little bit less accurate as you go. Don't belabor it past five, I would say. Pick another six or seven, but I would say the order is really going to matter the most in the top five probably.
Eric Meyer: Yeah, I think that's probably true. All right. Well, everyone go stack rank.
Brian Kardell
Eric Meyer