Episode 100: Web Standards at the Web Engines Hackfest
Igalia's Brian Kardell and Eric Meyer chat with W3C interim CEO Dominique Hazael-Massieux about Web Standards, the W3C, the Web Engines Hackfest and the larger web ecosystem
Brian Kardell: All right. Hi, I'm Brian Kardell, developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia. And we have a very special guest today on a very special episode. Dom, please introduce yourself.
Dominique Hazael-Massieux: Hi, I'm Dominique Hazael-Massieux. I'm lucky to be a second time guest on this show. I work for W3C and for now a couple of weeks, I've been appointed interim CEO of the organization and I'm really glad to have the chance of being the guest of this very special episode.
Eric Meyer: Well, congratulations very much.
Brian Kardell: Yes on being a guest of this very special episode.
Eric Meyer: Exactly. Also, the W3C thing. That's nice too. And yeah, this very special episode is the 100th episode of Igalia Chats. So, we thought what better way to mark that than having the new interim CEO of the W3C and friend of the show. So, how'd that happen?
Dominique Hazael-Massieux: Well, the previous CEO resigned and I guess the W3C board needed someone to make sure things kept running smoothly, and I was a wrong person at the wrong time or-
Eric Meyer: You were out of the room?
Dominique Hazael-Massieux: Yeah, exactly.
Eric Meyer: Went to the bathroom, came back as you did what?
Dominique Hazael-Massieux: Yeah. So, I mean I think again, leadership transitions are always a bit of a challenge. And since I've been in this organization for a while, since I had a chance of seeing it through the very many different layers of activities and work in the organization, I guess the board figured out that I should be able to handle that interim transition. So, there we are.
Eric Meyer: Yeah. How long have you been with the W3C?
Dominique Hazael-Massieux: Well, I celebrated my 25-year last October. So, yeah, it's been a ride.
Eric Meyer: Yeah, it's been a while.
Brian Kardell: We very recently, I don't even know, maybe it was two episodes ago or something like that, did an episode on standards organizations. I don't know if you had a chance to catch that or whatever, but if you did, I hope it seemed fair to W3C. We also had suggested like there were some things that W3C probably needed to adjust to. I know W3C has been talking about how to adjust and how to grow and what is its role in this new ... It's now a legal entity. It has new relationships and it's trying to figure out itself in a different world post Tim, like Tim stepped down as a director. Lots of interesting new challenges there. Anyway, one of the things that I think has been talked about is that it like standards relationship to open source and I don't know if you are interested in sharing any of your thoughts on that or ...
Dominique Hazael-Massieux: Sure. I mean it's interesting when you look at the history of W3C, like it started and I think you mentioned that on the show last time, it started as a copycat of the X Consortium. The X Consortium was all about maintaining an open source project with support from the broader community and the early years of the W3C were very much about supporting implementations with the library, for instance. And so, all of this came also with a focus on specifications, but there was a very strong culture around building open source as one way of making the web work for everyone. And since then we've been doing open source in many different ways for many different purposes. But one thing that was striking when my colleagues and I looked at this again a few months ago is that although we have been doing open source for a very long time, it had grown a bit out of our radar that is, we were doing it because open source is a nice way of collaborating with other folks, but we didn't really have a vision around what the role of open source for the web, the role of open source for W3C and how W3C could make better use of this form of collaboration to improve the web as a platform. And so, we looked at that landscape and we tried to look at the various projects that have been developed inside or really close to the W3C over the years and try to understand if there was more that we could do to make that effort more impactful, more structured, also easier to get involved in, easier to make grow. And so, that has led, I think a number of very interesting conversations. We're still figuring out exactly what our role in that space might be, but I think an early realization, and maybe it was obvious to everyone already, but an early realization is that paying more attention to how we can help open source make the web even better for everyone is the thing we need to look at and whether that's by providing better governance structure for things that are already being developed in open source. In the W3C, like I'll mention, for instance, we have this working group, the Web Fonts Working Group developing a technology called Incremental Font Transfer. And the way they are building the spec is by building an implementation, which is an open source project, which is happening in a W3C working group and nobody knows about it. Okay. It's a very important project. It's actually trying the technology that is being developed, it's driving the development of the technology and it can be used to actually try and deploy the technology, but unless you're in the Web Fonts Working Group, you probably didn't know that was even happening. And again, all the good work was happening, so we definitely don't want to disrupt any of that, but conversely, are there opportunities where people would get more involved or would deploy that open source project earlier in the development of the technology if there was more visibility around it, better understanding of the licensing condition and so on? So, anyway, it's a small example, but one of the things we did is try to look throughout our work where open source is already being used, understand the role that you can play for again, enabling a better web and yeah, lots of really interesting opportunities ahead of us. So, we're going to try and see specific projects where we can get a better sense of a role W3C could and should play, but yeah, it's a pretty exciting exploration space we've been opening up.
Brian Kardell: So, bringing back Arena is what I heard.
Eric Meyer: Amaya.
Brian Kardell: Yeah.
Eric Meyer: I was also thinking of Amaya for listeners who maybe don't remember the W3C used to make its own web browser. It was called Amaya. Is that similar to what you were-
Dominique Hazael-Massieux: Yeah, I mean we've identified I think three or four categories of open source projects that can play a role in the W3C. So, the first one and maybe the one that people involved in W3C will be the most immediately familiar with are tools that we use to do standard stuff. Like if you've been involved in developing specs, you will have heard about Respect and Bikeshed, which are two great open source projects that facilitate the life of spec editors by taking care of a lot of the importance but sometimes tedious work of making it all fit together. And that's maybe the two top of mind examples, but we also have work around a project that was involved for instance called WebRef, which also plays a role in bringing a lot of these things together. So, that's the first category, tooling support for our standardization work. Then there are open source projects that help drive some of the spec work. So, I mentioned the work on incremental from transfer. The web assembly spec is also completely driven by a reference implementation in OCaml for what it's worth. And again, there are a number of cases where it's much easier to understand what to say in a spec if you've actually started implementing it in a way that is not necessarily the thing that people will use in the end, but at least makes you able to think about the constraint space you want to deal with. The third category is what I've called adoption projects. So, we make this great technology, but until it gets used and deployed and we discuss this, I think the last time I was on this show. Until it gets adopted, you've really not changed anything. You've just made a nice piece of paper. And so, there is a great need from the ecosystem in making sure this adoption works in line with what was designed for the specification. And maybe the most famous example here would be the validators. I mean people maybe use them less nowadays than they did a few years ago, but the validators, what does it do? It tells you, yes, you are using this markup language or this style sheet the way it was designed to be. It guides you in maybe using this or that alternative when necessary and so on. And so, it's not just about delivering the final word, the specification and say, 'No, you deal with it.' It's also accompanying the community in making sure they understand how to use it best and how to use it in practice. And so, whether you would call it a W3C project or not, but the web features project with the baseline definition is also based on a number of open source tools which are exactly about adoption, I mean giving clarity to the committee about what they can use and how they should use it. And the fourth category which is maybe a derivative of this third one is anything around testing and conformance. And obviously the poster child here, although again, not technically a W3C project, the poster child is a web platform test, which is absolutely amazing piece of work as an open source project which helps get this convergence across broader implementations and that exists for browsers, but like any W3C working group nowadays would be developing a test suite. And when they do that, they would do it as an open source project. But today, like more often than not, they are thought as yeah, it's a thing we have to do while developing the spec to make both happy. But the value in this test suite, and again, as WPT has demonstrated, are that much higher than just checking that particular box. It shouldn't be so just as yes, during this particular time of the life of this technology, we'll be checking whether we get enough implementation experience. It's really throughout the life of deployment and adoption of this technology, let's make sure implementations converge, let's make sure we accompany the deployment of this technology by increasing interoperability over time, not just one time check that the standardization track requires. And so, when you look at this more broadly, this work on test suite, which is fundamentally based on software and open source and collaboration, today is looked at as a side thing. If you look at the charter, it will say footnote, yeah maybe we'll be developing a test fit because we have to. It's not that as a key element of what W3C delivers. And when you put that also in the light of the current AI wave where actually specification and test suites are maybe the most important things that AI agents needs to develop a thing. It's not so much the prompt, it's, 'Well yes, you will develop this code, make sure it follows this set of constraints, which we call a specification and make sure these constraints are validated by running a test suite.' So, again, you see here to me this convergence of interest by looking not just at artifacts of the standardization process as things we can do and then forget, but instead looking at them as key to the whole life cycle of a technology, not just this particular time where it's being developed in our groups.
Brian Kardell: Yeah. So, I was joking about a W3C browser, but you had mentioned that there used to be like Libwww and I think LibHTP, right? Which were, can you just like briefly for people who would be listening, tell them what those were?
Dominique Hazael-Massieux: Yeah, so Libwww was or is, because I think it's still available and probably still even maintained by us gives you basically the basic tooling to interact with HTTP servers. So, it gives you, I mean probably for HTTP/1.0 rather than the latest HTTP/3, but it gives you all the basic infrastructure to build card on top of HTTP interactions. And so, it was at the core of many of the early tools and libraries interacting with web content and yeah, it was a really important role. Nowadays, probably you would be using more and modern libraries like Karl or others. And again, I think that illustrates another point about open source, like there doesn't need to be the one true open source implementation that everyone shall use and adapt. So, understanding when it is useful for us, for instance, to get involved in a project and when it's fine to leave it to the market of projects and ideas is definitely something we need to think about. But yeah, the fact is Libwww was a really important enabler in getting people rapidly adopting HTTP as a critical protocol.
Brian Kardell: Yeah. I did a talk or a article once where I was talking about like the early part of the web and like there was a point where there were like more browsers than known sites because the people who were interested all wanted to build a browser. But of course, the web was like a lot simpler and you could build something like a hobby project, but all those hobby projects used like Tim's libraries to do the real webby stuff. They were mostly implementing stuff on top of that and that's also an interesting thing to think about because even Tim I remember encouraged that like, 'Well, you don't have to build a whole HP stack. Here's a library. You can just use it.' How many is the right number? Is it like, I don't know, like we want more than one in theory, but-
Dominique Hazael-Massieux: Yeah. So, one reflection again on which we don't have a conclusion yet, but in that problem space we put under the label of the risk of monoculture. So, if you have a single project that is basically the one thing on which everyone relies, it creates a risk because if there is like a significant vulnerability or deficient architectural choice in the way that library was designed and it's a whole ecosystem that is at risk. And there are very infamous examples like the issues with open SSL which created this huge worldwide venerability once vulnerability was detected there. And again, I don't think we have the perfect answer. There are a number of situations already in the web stack, where there is this one true library that, for instance, all browsers would use like libWebRTC. If you're doing web RTC in a browser today, I think all the major browsers are relying on this one C++ library libWebRTC. So, I mean so far, nothing has broken, but it creates this point of contention that is always a bit of a risk. One, I mean the way we are trying to think about it is what are the mitigations that could be put in place when that situation happens? And sometimes, it's the right choice because, for instance, web RTC is such a complex stack. Having it implemented three times would be a very significant, if not one that I would push back against of course, but I understand why we landed there, but then it's interesting to ask questions around, well governance, how is that particular block being governed? We have the grantees we need to make sure that this is done in a collaborative fashion, where everyone can help make the library evolve and so on. Can we make it so that it's easier to fork? I mean open source famously the story around monoculture is, yeah if you're not happy, you'll just fork it and it of course never is that easy, right? There's a whole ecosystem around it. There is a whole deployment and adoption discussions. So, it's not just a license I guess is part of where we are landing you need again maybe a simple example, but if your test suite is designed so that it can be easily shared with other projects, it makes it a very different story to be an alternative implementation versus if that test suite is super deeply built around the specificities of your product. So, again, looking at it more from a large ecosystem perspective, how do you ensure that when you have this, I guess what in ecology would be a keystone species, how do you make sure you can preserve that space without creating risk for the broader ecosystem is again part of what this discussion around open source is pushing us to consider.
Eric Meyer: Yeah. You made an interesting point a little bit ago about test suites and AI and how if people are going to vibe code things that have to interact with the web that having a really comprehensive test suite will hopefully at least guide them in the right direction. And we have a colleague who actually as an experiment created a JavaScript engine through AI large language modeling and it now passes more of WPT, the web platform tests than any actual browser engine, but it's also as they were very clear to state, like atrociously slow and you would never actually use it in a browser because like it passes all the tests. It just does so very slowly, like in very sort of naive ways, but it was not to say that that's necessarily an endpoint, somebody could get to that point and then figure out how to refactor the inefficient parts, I suppose. But I wonder if that also points towards should there be more tests that test for performance?
Dominique Hazael-Massieux: So, one thing that was really interesting when we opened up that open source box is that once we did that and started talking to people around, suddenly people were coming up with, 'Oh and by the way, there was this idea that I never knew where to bring because W3C would have been the right place, but you don't do open source. So, why do you bring this up?' And benchmarks is one of the topics that has been brought up and benchmarks come with their own set of complications in terms of how they're used, how they're perceived, how do you get consensus on them.
Eric Meyer: The politics of how they're structured. Do they favor one?
Dominique Hazael-Massieux: Exactly. What do you optimize for? What are the risk of this optimization? But again, all of those politics, as you call them, are bred or butter in W3C. This is what we do. We bring people together, we try and get them to converge toward a shared goal and if we can, then hopefully that helps the overall ecosystem. So, yeah, benchmarks would be I think another interesting angle to explore, again, figuring out the right trade-off between getting the wrong optimizations in.
Brian Kardell: I think there are a lot of things to talk about with regard to testing. I mean, I can't believe we're this far into the podcast and we haven't mentioned that we are recording from the Web Engines Hackfest-
Eric Meyer: That's true.
Brian Kardell: ... which is this year W3C endorsed conference, which is kind of nice.
Eric Meyer: Thank you.
Brian Kardell: Yeah. Thank you for that.
Dominique Hazael-Massieux: Our pleasure.
Brian Kardell: We presented this because it's a lot like an event that W3C does every year that everybody loves TPAC, which is an unfortunately named thing in my opinion, a little bit like ECMA, right? It meant something else but it doesn't really mean that anymore. So, it's just TPAC, I guess. Again, like ECMA, I suppose. So, that event, W3C has two major events. One is the AC meeting, which is more businessy, I guess. It's like supposed to be a little bit like Congress, right? Like this is when your representatives from the different companies come together, but as a result, it's less technical. And then there's TPAC, which is sort of both, but more toward the technical and lots of things that people like about that are we get some nice talks but lots of cool breakout sessions and everything. And Web Engines Hackfest is a lot more like TPAC I would say. Some of the things that we saw yesterday and the first day were things like accessibility testing and web platform tests, which will blow people's minds to find out that we didn't have that. We're 30 plus years into the web and only now we're being able to test the accessibility in many ways. I think there's a lot of stuff like that that people don't realize that we just don't have good ways to test for that stuff. So, yeah, I don't know if you had any thoughts.
Dominique Hazael-Massieux: Yeah. So, first it's my first Web Engines Hackfest and I've been enjoying it a lot so far. I haven't been to the breakouts yet. It's at the top of this hour, but those talks yesterday were really, really good. So, congrats to the organizers. I mean, one thing that I think is striking is like the Web Engines Hackfest is obviously a lot more targeted towards web engine developers and browsers in general whereas TPAC and the way I think of TPAC is really the W3C all hands meeting really. That's to me the way to think about it is the place where the whole community comes together to work as a whole. TPAC obviously covers a much broader scope because we do of course a lot of work in browsers, but we have work around eBooks, around accessibility, around internalization. We have work around a lot of work on data, verifiable credentials, identity and so on. So, the scope that W3C needs to cover in TPAC is much broader, but what's really nice about the Web Engines Hackfest is that you can deep dive into some of these topics in a way that would be, I think probably a bit more challenging in this broader context. I mean in particular, the talks we had yesterday, I think were really good because they could dive to some of this level of understanding and technicality that would be harder in front of 600 people with probably less direct interest or understanding of the way browsers work. But yeah, the talk on accessibility testing to me was fantastic because it shows the power of automation and systematicity. There had been already some testing around accessibility and some of it was being done manually and the groups that this whole started around how the ARIA Working Group wanted to demonstrate they had proper implementation experience. So, they did test that they had this, again, to check the box, make sure that they could assess that they had done the work. But once you push it further, once you move beyond just checking the box but looking at it as, well, let's make sure we know the state not just now or two years ago, but that is something we keep track on a permanent basis on which we can apply constant pressure towards convergence using the internal project, then you change the conversation completely and it's not just that you push for converters, but suddenly you also have visibility about what's broken. It's no longer, yeah, two years ago, we had this status on this subset of things we considered. Now it's from now on, we will be able to know which browsers have gaps in which aspect of the technology and the initial set of tests that were described in the talk yesterday were for limited scope around the role names of the accessibility tree. But once you push that towards testing some of the dynamic states and so on, a lot of the questions that developers are facing when they actually try to make their web applications accessible, but will this work correctly? Do the browsers provide the right hooks for assistive technologies? Well, suddenly that becomes something we can detect automatically, start documenting. I mean the project around the accessibility compare data, which was also mentioned in the discussions after the talk is also looking at this, it's not just looking at what implementations do, but also helping developers understand what implementations do so that they can adapt and adopt the technology in the end.
Brian Kardell: I'm glad that you mentioned this distinction about like the things that W3C does and the things that we do at the Web Engines Hackfest. You also mentioned before some words that sounded like they were talking about evolution. I think you said like keystone species, right? I think like Igalia does a lot of things with embedded web engines. We also have a Wolvic browser and we work on all the engines, but-
Eric Meyer: WPE WebKit.
Brian Kardell: Yeah. But we do a lot of work on embedded and embedded can be a little bit different and people actually mean different things when they talk about embedded too, right? So, I know that there's several things that came up yesterday in different talks where they said like, 'Well, this is maybe not the drive by web or this.' Well, it depends on if you mean the stuff in the web browser or if you're building maybe like a television that's not for general web browsing, the things about the Cyber Resilience Act making distinctions there, Dan and Aki. And I know that today there will be a breakout on some things around embedded and I think we help bring in at Igalia a lot of people who are definitely not going to make a new web browser to try to compete with Chrome or anything, but they use that web technology and they inevitably end up contributing things that they need that have different priorities than maybe the browsers do. I think as the situation around us continues to evolve and we have so many other things using the technology, getting all these different inputs and all these different sort of stakeholders and players to collaborate where you draw that line gets a little bit tricky. So, we say the Web Engines Hackfest, but it is like web engines, not web browsers and where you draw that line gets a little bit tricky. So, yeah, I was just wondering like how do you see better ways for us to bring people together and do you see value in the thing that we do here that values finding pragmatic ways to get people to invest in like find common ground and work together in very practical ways that are not just sort of writing words and do you know what I mean?
Dominique Hazael-Massieux: Yeah. I mean I think one of my core belief about what W3C and our overall ecosystem is, is that it's about bringing people together toward a shared goal. I mean we are a deeply social species and so we need to be together, we need to understand one another to work towards that shared goal. And to me, the hackfest in that sense is a really useful compliment to what happens in TPAC. I mean in TPAC, most of the time and obviously lots of it happen in the hallways, but at least when you're part of the more formal part of the working group meetings, it won't be about implementation architecture or how would you be structuring that particular piece of code? It will be trying to stay at the words level as you were describing it and that comes with a number of advantages because words are more accessible to more people than code would be. But yeah, having this opportunity also for people that need to think through the code, through the architecture discussions, through comparing how the different projects work together in parallel, I think is a critical part of again, building this community towards a shared goal. So, to me, like the hackfest feels like a really interesting complement to what TPAC is more naturally able to achieve. And again, I haven't been to the break yet, so I can't quite tell whether they will be very different or very similar to the way they operate in TPAC. But even in terms of the community, there is both significant overlap between the hackfest and TPAC and also significant differences. I looked at the research and I think it's roughly a quarter of people that are here, whether remotely or physically that were also at TPAC last year. So, a quarter is big, but it also means that three quarters weren't at TPAC. So, again, that means you also draw different people with different interests, for instance, also more clearly involvement, for instance, from people from ECMA than you might maybe get at TPAC. Yeah. And bridging communities I think is also a key thing we need to do more. And so, to me, that's also a role that hackfest seems to be playing.
Brian Kardell: Yeah. You hit on actually the thing that I was trying to think of a way to articulate, but like we'll get a representative sample from Apple, a representative sample from Google, a representative sample from Mozilla, but it's relatively small numbers and like the rest is people who invest in something downstream or who run an upstream kind of text shaper or really, really interesting things. We have people who make alternative JavaScript engines and web browsers and things that come and give talks and presentations and generate new ideas that I would love to figure out how we pull that part into W3C somehow also. Is there anything that you're looking forward to at the hackfest in terms of breakouts?
Dominique Hazael-Massieux: There are a couple that I will actually have to miss because I'm flying back tonight, but maybe building on one of the topics you added to... I think it was four years ago that I helped launch the web use community group, which is trying to look at what, if anything, W3C can do to help make web use a better experience for web developers and a lot of the questions you alluded to around is it part of the web? Is it used for first party content versus for the drive by web and so on? Many of these questions were considered in the community group, and I think we now have a better understanding of that ecosystem. Since then, we've also seen some really interesting overlap with the work happening around EPUB, which is often implementing using web use, the work happening around mini apps, which is the way many applications get deployed in China again based on a WebView ecosystem. We've seen some interesting overlap with what Google has been developing under the name of isolated web apps. So, a way of packaging applications with additional privileges by constraining how they can be accessed and deployed to avoid some of the security challenges again of the drive by web. Interesting overlap perhaps also with web extensions. We've just launched for the first time ever as a web extensions working group, which is looking at standardizing APIs for web extensions again so that developers don't have to recreate extensions across the various engines. But again, web extensions, they use web technologies with a very different security model with very different expectations. So, there is whole ecosystem of technologies that are looking at using web technologies, but outside of the default web security model, which we know I think understand much better than when we started developing it organically, but comes with a number of very interesting properties in terms of facilitating adoption deployment accountability and so on, but also creates fairly systematic constraints in terms of what new technologies can be brought to the web at what speed and as a result, may put the web or broad definition of the web at a disadvantage. So, one of the breakouts would be in this case very specifically around WebView for server, but it's run by the chair of the WebView Community Group, which I know has been having a number of conversations about what can W3C do at this point in time to facilitate and accelerate the conversation for greater convergence in that space. So, yeah, that's one of the topics that I'm-
Brian Kardell: I'm also really looking forward to that one. Yeah.
Eric Meyer: I want to jump in because I think I know what you mean, but I'm not sure. A couple of times you've said drive by web. What is drive by web?
Dominique Hazael-Massieux: Yeah. So, one thing that when you look at WebViews, how they are being used today, one category is I want to build a native app. I have this content I have full control of instead of redoing it in whatever proprietary language each platform requires, I will reuse my content, ship it within a WebView and call this an AT app. So, this comes with a context where the WebView is used in a very controlled environment at least if the WebView is configured correctly versus I need to show any random web content in my native app. So, I will be shipping a WebView as part of it so that I can display a confirmation payment information or whatever. Once you are in that model, the security constraints become completely different because at this point whether you realize it or not, you're actually shipping a browser and you're actually need to cut off all the complex security considerations that browser engineers build into their product. So, that's what I mean by the drive by web is basically one or one where the sky is the limit in terms of the type of content you can have to run the-
Eric Meyer: Okay. Yeah. So, one is a window into a very specific bit and one is a browser for one way or the other. Okay.
Brian Kardell: Yeah. This is actually the topic of our last chat I believe was with Dan Appelquist and we got a lot of compliments on the title card that we created, is this meme with the guy with the butterfly, right? And it's also my last post and I tried to clarify in my last post, I also sent something to the W3C AC list asking about this. It also feels like the kind of question that if you summarize it is the sort of question I typically want to run away from. It feels esoteric and academic in a way, but it's not. It's actually there are really important practical reasons we need to ask these questions, including for something like the CRA, right? So, you have different duties-
Eric Meyer: The Cyber Resilience Act?
Brian Kardell: Yeah. You have different duties depending on if you're building a Netflix app or you're building a television than you do if you're building a web browser. Speaking of like the different evolution and like I was saying, like if you're ... We don't know what people are building. I wouldn't have 10 years ago thought that people were going to be building mini apps to be totally honest, but there's lots of things that seem to change all the time and on that we're constantly talking about is the search deals mainly with Google are the things that are the lifeblood of funding that moves through all of the technologies that we have and with LOMs and chatbots and intelligent assistance and things, it is ... I just want to be really honest, like it is complicated in so many dimensions, but like as a user, an end user, say to my home assistant, 'Hey, home assistant, can dogs eat, blah, blah, blah.' And they say, 'According to the American Kennel Club, yes, dog can eat banana, blah, blah, blah.' I feel pretty confident that that's right. They cited the source and everything as an end user that is honestly a better experience than I was eating, my hands are covered with food. I don't want to go to my laptop, open my laptop, go Google search, go through the ads, find the thing, click it, then somehow in 400 pages of ads, find a thing where it says yes. As an end user, it's just a better experience and we are evolving lots of these things that are going to impact the models that we have today and to your earlier point about like implementations and the risks and things like that, I'm wondering if you see opportunities for us to build some kind of resilience to that and if there's anything that you think that we're not paying attention to, that we should be paying attention to or innovations that you think could be particularly disruptive or great or-
Dominique Hazael-Massieux: Yeah. So, first in terms of the user experience, I agree with you that one thing that LLMs have completely changed is how you interact with your computer, your device, and more broadly speaking, the online ecosystem. I will say if one day your dog gets sick because the answer was hallucinated, you might have regrets about that particular user experience and not having had the chance to confirm that this was on this respectable website and not again, just another hallucination. And to me, from an ecosystem perspective, that's, I guess, my main worry of hiding the source behind this digested answer is that this trust that people put in the system, if it gets broken, it's going to get really hard to rebuild. But to your broader point, I think anyone involved in the web ecosystem will agree that AI is this huge tsunami that is completely changing so many of the assumptions and equilibrium that we had found over the past decade, and the web has known a number of those tsunamis before. I mean, in many ways, mobile and native apps were a very significant change as well. Social media has also created a lot of changes in how we understand the web and its interaction model, the notion of ownership of content and so on. But from my perspective, and I was until a couple of weeks ago, the guy in charge of AI in the W3C, clearly AI is shifting so many things at once in so many different ways and with so much strength that yes, it is a very challenging period to manage to bring stability back to, again, the ecosystem. I like to think of it as if we had this brand new predator coming into-
Brian Kardell: Hundred percent, yeah.
Dominique Hazael-Massieux: ... an ecosystem that had found some kind of equilibrium. Of course, it's never completely imbalanced, but it was, I think, growing fairly reasonably. Now I don't have the silver bullet solution to this. If I was, maybe I would be rich, but I think part of what we do in W3C is convening conversations and bringing people around the table, understanding what are the stakes from the various people, trying to find common ground. So, one of the things we've been actively doing is bringing more of the AI people around the table. Of course, some of the big AI players are already part of the W3C and very active, some aren't or some aren't yet and one things we are planning for September is a workshop around AI agents and e-commerce as a way to understand how AI agents can or could interact with online content in the specific context of e-commerce, because it brings a number of interesting characteristics in the conversation. But again, I don't expect that September 10, the day after the workshop, I'll come back with here is a solution. But if we have the people coming together having again, a structured conversation, a better understanding of what other people on the other side of the table seeing the challenges they are facing, then my hope, and again, my experience so far in W3C is that this is what opens the door to finding the right small next step. It's not going to be the next big day revolution, but the small next steps that get us closer to an ecosystem where again, everyone benefits. Because at the end of the day, I mean, one of the challenges we are seeing obviously with this huge AI tsunami is that we are seeing more and more publishers says, 'Why would I leave my content openly available on the web if it's only going to be feeding money making machines for others?' And while if you're an AI company and the open web shrinks because of that constraint, you're going to lose as well because ultimately they also need that content to bring the answers they think to bring to their end users. Again, getting people around the table, making sure they speak the same language, making sure they understand what's at stake around keeping a thriving ecosystem while that's our job and hopefully, we'll manage to do it well, but again, it's something that needs to be done as a community and a lot of conversations, a lot of connections.
Brian Kardell: So, we will see you this year at TPAC, which will be in Dublin.
Eric Meyer: Dublin, Ireland.
Brian Kardell: Barring any unforeseen world event or something. I think I mentioned that because in my life I've been scheduled to go to Ireland twice, which I always wanted to go to Ireland my whole life and the first time, we had a pandemic and the second time, I had a heart attack. So, let's try to make it to TPAC this year in Dublin.
Eric Meyer: Third time, Charles.
Brian Kardell: Yeah, let's hope.
Dominique Hazael-Massieux: Yeah. So, the conversations you had with Dan during the last episode on what is the web I think was very provoking and to be clear, that question I think I've seen discussed in W3C since when I started. And I guess I get a bit suspicious when there is a very big question that doesn't get an answer and so that episode got me to think why are we asking the question-
Brian Kardell: Exactly, yeah.
Dominique Hazael-Massieux: ... rather than what is the answer? And I think at least from what I recall of the episode, part of it was is this a web as a proxy question of is this something W3C should be working on because we are the worldwide web consortiums, of course we need to work on things that are the web and some of it is the web in terms of does it expose the values that we have grown to expect from web technologies? And I think once you separate those two aspects, then I think maybe some of the questions become clearer. It's no longer is this web, but to me, let's call the web this shared online ecosystem. And yes, we call it the web because it was seeded by this creation that Tim Berners-Lee did in '89 and he called it the worldwide web and so we call it the web. And it has grown and focused a lot on the web browser experience, which is again, clearly a key entry point to that online digital ecosystem. But once you forget maybe that more historical aspect and you look at it as, well we as a society need this shared online ecosystem, then the question becomes What does this need to work on in that space? And I think this then ties it back to the second question, which is what are the values that we want to bring to the technology we bring to that ecosystem and that's where should W3C work and it become in my mind, is this something part of the digital online ecosystem if it's about how to build a chair? It's probably not something W3C should work on. But if it's part of this online digital ecosystem, the question becomes, is the W3C the right place to bring the set of values we want to see in that shared digital ecosystem? And so, it's no longer about, well, is this in a browser? Is this a native app? Is this a WebView? Is this an ebook? It's about, well we have this shared space where we want to bring more interoperability because it brings a set of advantages for end users. We want to make sure it remains accessible, that it can be used across languages, across culture, that it protects people's privacy because that's a value we recognize as important in a world where otherwise everyone knows and tracks everyone else, security and more recently sustainability. And so, then the conversation becomes is that this is the right place to bring the right people around the table to change online shared ecosystem in a way that again, hopefully improves the world in the sense that these values are what we think is needed to make that ecosystem thriving and positive for end users.
Brian Kardell: So, it's on the record that DOM objects to chairs being standardized W3C.
Eric Meyer: But not W3C chairs.
Brian Kardell: Yeah, that's right. I had said in my post that like I don't even think I want to get into what is the web because when you think about it, so many things that W3C are like data formats and data structures and ways to talk about data and metadata and like a lot of them can apply equally well whether you're connected with a URL or you're just processing some data locally and I think that's all fine. To me, the distinction that I mostly care about there is what is the intent of the thing that you're building and that does affect a bit like how we focus on it for all those reasons, like I said about the CRA and like you were saying, it's different. It depends if you mean a thing that you're building an app that is just like rendering some static HTML that you happen to preload onto the device or it's serving from your single domain or something, then if it's a web browser that you expect to be probably your single most trusted piece of software in your life in a way, because you share everything with your web browser. I mean for me the reason I ask is mainly because I think it's useful in those kind of ways and how it comes to prioritization I guess as well. But yeah, I'm interested in the question in purely pragmatic ways I really would like to run away from the question of what is the web personally, but I do think that there's room for us to maybe be clear in what we talk about in some of those ways. Yeah.
Eric Meyer: Yeah. And I like your framing of the metric being where should this conversation happen? Where is the right place to bring the right people together to have whatever the needed conversation is? So, it becomes less about does this thing use angle brackets and more about who is this going to impact and therefore who is the most relevant and is the W3C the right place or is ECMA the right place or is the IETF the right place or is whatever.
Dominique Hazael-Massieux: Yeah. And as I mentioned earlier, I mean one thing that AI is not going to bring to the table is intent like to have an intent you need to have a wheel and I think this is very much an embodied thing that at least today, only humans can properly communicate. And so, to me, building the web is this intensely social process where precisely by bringing all this intent and sometimes very much in opposition, but bringing them together around the table, we get out something that maybe doesn't move as fast as a propriety platform or the ways of bringing technologies out, but we bring something where we can set a new bar as to what we should expect from this shared online ecosystem and when W3C is the right place for bringing people together when the again, values we bring, the process we bring to make sure these values get incorporated in the technology, then yes, we should absolutely push for that to happen. But when other places are better places and typically you mention ECMA in terms of designing JavaScript, there's no question that the process, the culture and so on is that ECMA when it comes to designing protocols on the wire, clearly IETF has a lot more again, cultural process and experience in that space. W3C I think shines in particular for technologies that get exposed to the end users. I mean, that's something where we do have a lot of cultural process and experience, but we also have a lot of it for data format that are again used as a basic infrastructure for this shared ecosystem. And one reason why data formats matter is that if you agree on this base layer of how to format and represent data, then it becomes a lot easier to build on top of it to again, contribute to this broader ecosystem. So, again, to your earlier episode about standard bodies and how they compare and the relevant position, I think at least that's the way I try to think about it and then the questions around prioritization that you often raise and which I agree are critical and extremely challenging to actually settle, but they become prioritization in terms of, again, what impact as a community we can have on this shard ecosystem. Sometimes, it may be a small piece but one where we can do good work rapidly. Sometimes, it's a huge piece that we don't know how to do progress quickly on, but by keeping at it we'll make iterative progress. And so, which of the two is the right approach when a lot of it is again through this social deliberative process that we get to it, but ultimately that's I think what we want to get out of the community, how do we as a community figure out the right investment of our time and resources-
Brian Kardell: Hundred percent.
Dominique Hazael-Massieux: ... to make progress?
Brian Kardell: Yeah.
Eric Meyer: Yeah, yeah. But it is kind of coming to the end. We need to wrap it up so that we can go see these breakout sessions. Dom, thank you so much for joining us for the 100th episode.
Dominique Hazael-Massieux: Well, thank you so much for having me for this again, very special opportunity. I'm really honored.
Eric Meyer: We were all in one place so we figured let's all sit down together and we'll make it happen. It was a beautiful confluence of factors.
Brian Kardell
Eric Meyer
Dominique Hazael-Massieux