Igalia's Brian Kardell and Eric Meyer chat with the W3C's Dominique Hazaël-Massieux about ways that we try to involve developers and developer input into standards
Brian Kardell: Hey, hi. I'm Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer. I'm also a developer advocate at Igalia. And welcome to today's episode of Igalia Chats. We're going to be talking about, oh, just dev stuff. And for that, we have a special guest we've invited on. Special guest, please introduce yourself and let us know what you do.
Dominique Hazaël-Massieux: Hi, everyone. I'm Dominique Hazaël-Massieux. I'm a member of the W3C staff. So, most of you will know that W3C develops standards for the web. Not many of you may know that W3C is operated by permanent staff that helps working group work together, keep a consistent architecture of our technologies. And so I'm one of those technical staff. I'm involved in a number of working groups as a web real-time communication, WebRTC, which we are using right now to record this episode. Also in the work around bringing machine learning to web browsers, and more generally speaking, looking over how AI is impacting the web, both in good and bad ways. But on top of this role in developing specification, technical specification, I've also been in charge of our developer relationship effort for the past few years with the idea that as we develop these technologies, a key part of how they actually change the world is based on whether and how well developers are actually able to make use of those technologies.
Brian Kardell: I have a couple of talks that I gave years ago that had this meme in it of the Avengers when there's this scene where they're like, 'We have a Hulk.' The developers are the Hulk in this because you can have the W3C and every company in the world working on something, agreeing to something, moving forward, but if developers don't adopt it, then it doesn't happen. It has to be this thing that gets accepted and adopted. And that's really, really tricky to prognosticate. I think it's interesting, the DevRel position at W3C, and I've worked with you a number of times over the years to try to do interesting things. Some of them I guess we'll talk about here, but we just recently talked about XSLT on the show. Eric, maybe you could recap the-
Eric Meyer: Yeah. We had Liam Quinn actually come and talk to us about it. So, anyone listening, if you want to hear that conversation, we'll have a link to it in our show notes. Or you could subscribe to Igalia Chats if you haven't already, and it'll be on the list.
Brian Kardell: Don't forget to smash that like and subscribe.
Eric Meyer: Like and subscribe. Anyway. Yeah, so an issue got opened with the what WG basically say by Mason Freed at Google basically saying, 'Should we just remove XSLT support from browsers?' And he opened it because other browser vendors had also, and members of the teams at other browser vendors had said, 'Maybe should we just remove XSLT? There are these security problems that have been discovered and our implementations are based on all libraries, and it's a more of an attack surface. And we don't think anybody really uses it, so maybe we should.' So, that conversation was opened and was immediately taken as Google is single-handedly destroying parts of the open web because they can, which was not what was happening. But anyway, we talked about it. I also wrote a blog post, whatever. But the interesting thing about that is that, at least to me, well, there's many interesting things, but one of the interesting things is that this was an example of something we see from time to time where a process that the people who are part of the process understand had context escape. It got out into the wider world where people who did not understand that process interpreted it according to what they expect, which is what all of us ever does, but they maybe expect Google to just do things unilaterally with no real community input or maybe the veneer of community input. And they're-
Brian Kardell: So, specifically, that's the thing that the context that is escaping is WHATWG stages model. People didn't understand this as stage one, and that in order for it to even advance to stage two, it needs to have these actions move forward. And so they were interpreting this as Google just acting unilaterally.
Eric Meyer: Right. Doing a thing, pretending to care, but not really caring, which is not at all the case in this case. I'm actually curious, do you have that problem as well with the W3C where processes get exposed to the wider world and the wider world doesn't understand them and there's a lot of misunderstanding as a result?
Dominique Hazaël-Massieux: Yeah, first at the high level, a lot of our processes are not just in DALCC or WHATWG, but in any places with standardization, a lot of these processes feel arcane from the outside. They are a combination of making sure the T got crossed and the I dotted. They are also taking care of intellectual property rights, which matter if you are in a certain ecosystem, but doesn't matter for most people most of the time. So, a lot of it is hard to comprehend if you are not fully dived into it. And conversely, I think again, something that is true both in DALCC, WHATWG, and other organizations of the sort, we want to operate in as transparent manner as possible just to make sure that there are as few barriers to hearing directly from developers about their needs, about their feedback about the specifications. And so naturally, these two somewhat contradictory situations can create frictions. And very regularly in our own GitHub repository, we get strong expression of dissatisfaction exposed, and sometimes for good reasons and sometimes just because there was a misunderstanding about the real nature of the situation.
Brian Kardell: When you were saying that, I had a few things that popped into my mind about things that I've seen confusion about at W3C. Early CSS had a lot of specifications that, and not just CSS, MathML is another example or SVG, that where specs were written more aspirationally and the process was a little bit different. And so things like even some things reached rec that today wouldn't. I think people assumed that because it was in a spec, if you could... I have a good quote from Mark Nottingham that I could link to, which I'm sure that these people come into standards and they think, 'If I can just get in the specs, that will be real.' I think people misunderstand what it means for a spec to be written in the W3C or where it's at. Is it in a community group or is it in a working group? How specs are written, how things evolve. Do you find that that's still the case? It's certainly changed over the years.
Dominique Hazaël-Massieux: Yeah, so you were quoting Mark Nottingham. I'll quote Robin Bergeron, who said one of the most typical typo about the world specification is when it's written specifiction, which also matches indeed the state of specifications either at the start of their life or sometimes until the end. And the reality is we write specifications to describe these technologies because we believe that by writing them in enough detail, they will bring an interoperable and transparent platform that we can rely on for a long time, not just something that one team can ship and no longer think about a year later, but something on which there is a real long-term investment that we all love to rely on. The notion that we can open webpages that were returned 30 years ago without a second doubt, try and do that with any native ecosystem. You can't. You won't. So, there is a lot of value in investing in this approach around specifications, but they're not a silver bullet either. We can have the best ideas of the world, put them on paper. If they don't get taken up by implementers, they are fiction. Or if they are implemented everywhere but nobody use them, they are still fiction. So, at the end of the day, I think the real challenge is to have enough of this feedback loop, enough of these iteration cycles around this idea that we put on paper or on electronic paper to make sure that they match the real-world needs, the real-world constraints so that in the end, we actually get to see them used, adopted on a wide scale, which again, at the end of the day is what justified putting so much effort into this abstract approach to creating technology.
Eric Meyer: Yeah, specification has been a very useful term. And I know that as an example, the CSS Working Group is constantly paranoid about creating specification, either by neglect or by being too speculative. It's also interesting, specification can happen because the spec gets implemented wrong, but it gets implemented wrong consistently, where the working group or whoever wrote the specification or part of the specification thought that it would be interpreted one way and then all the implementers interpret it differently, but they did interpret it differently consistently. And in those cases, the spec has to get updated to say, 'This is what this means.' Maybe you rewrite the thing so that it actually means what the world is doing. We have a situation like that actually with anchor positioning, where I was messing around with anchor positioning and I discovered that in specific situations with anchor positioning fallbacks, the two implementations that we have so far at Chrome and Safari handle it differently. And I could see arguments for either. And so I even threw up a poll, and actually people who responded to my poll preferred one of the behaviors in our margin of five to one. It turns out that that's not what the spec actually calls for. So, I opened a conversation on the CSS Working Group to say, 'Here's what this is looking like. Here's what the community seems to prefer. What should we do?' And that hasn't been resolved yet. But yeah, sometimes there's disagreement just on the basis of, oh, two different people read the spec differently. And it used to be that that would happen, and then browsers would ship to millions of people and then it would come to the working group and both sides would say, 'Well, we can't change it because then we'll break stuff for users.' So, it is really nice that we can avoid that now.
Brian Kardell: I think this points to a tricky thing. It's a lot of people, but there's specializations in there too. So, maybe you get 20 or 30 people who are really paying particular attention to a thing and having some active conversation, if you're lucky. And there's frequently disagreement. A lot of the discussions that we end up having are somewhat arbitrary. They're like, 'Hey, this is what I think developers would understand,' and we don't agree. And then as we say here, well, we can run a poll, but if Eric ran a poll and the Avira ran a poll, they could get completely opposite results, right?
Eric Meyer: Absolutely.
Brian Kardell: So yeah, it's tricky. How do we get better about this? And do you want to talk about any things that we've tried or we thought of, or?
Dominique Hazaël-Massieux: Yeah. I guess we've tried a number of approaches there. And to your point, I don't think there is, again, a silver bullet solution that gets us the right answer all of the times. The real trick, I think, is to open up as many possibilities to get feedback over the duration of the development of the technology so that we fix things as best and as much as we can, taking into account that we also don't want to break things that people have started relying on. It's a lot of a balancing act between trying to find the best, most economic, most effective solution and also recognizing that we are building the plane as it is flying, and so sometimes we will take shortcuts. But to your question about how can we do, first, even if you take polls, like you were saying, so we have this set of answer and a mismatch, a different set of answers, that's already information. That means it's probably the case that you're on a spectrum of possibilities. It's not like it's a slam dunk type of situation. Well, that probably means you should go with the arbitrary solution based on your best possible ID or you run a team A, team B type of approach to it, as was done in the Masonry layout case, which actually led to a third type of approach.
Eric Meyer: Can you talk about that a little more?
Dominique Hazaël-Massieux: Sure. Very quickly, Masonry layout is this situation, well, it's a way of creating a CSS layout that has been requested for a long time by a lot of people, both in the CSS Working Group and the broader community. And there were two competing proposals that emerged in the CSS Working Group, one I guess suggested by the Chrome team, the other by the WebKit team. And there were good aspects to both proposals, good reactions from the committee on both proposals to the point that it was becoming hard to determine which path to take. So, in this particular case, they did run a bunch of polls, which, again, gave different perspectives. I think what actually helped unlock the situation in this case was their calling to the W3C Technical Architect Group, which is this group overseeing architectural that is broader design questions across technologies. So, they called on that group to give input and they suggested yet another lens-based, directly inspired by the two proposals, but taking it at a different level of granularity basically. And that actually, I think, is likely there's a path forward at this point. That's at least what I've seen being implemented and evangelized. So, what the tag helps other groups do is sometime take that step back or take into account lessons from other technology development efforts to make sure that they are informed as well and as accurately as possible. Another thing that the tag has done and keeps doing is documenting some of these design principles that can help groups themselves take that step back and review their proposals under that light. One of the principles that I found the most impactful in guiding groups has been the so-called priority of consistencies, which is when you develop technologies, you take first into account the needs of end users. If two proposals are equivalent from an end user perspective, then you consider the needs from developers. And again, if at the end of that there is still equivalence, then you would look at the need for implementers because you, again, want your technology to get implemented if you want to have impact. The last thing you should take into account is so-called architectural purity or how neat or pretty the solution is. And that may seem very abstract, but when you get into some of these challenging issues with competing proposals, you are forcing basically the conversation to actually explain how do they differ from an end user perspective and from a developer perspective, and finally from an implementer perspective. And that really changes a lot of how these conversations go because they actually give you a fairly clear rating system to evaluate some of those distinct proposals.
Eric Meyer: Yeah, it reminds me a lot of CSS specificity, to be honest.
Dominique Hazaël-Massieux: Yeah, exactly.
Brian Kardell: It's difficult for developers to make the time on the timeframes that these take to really be involved. We have plenty of examples that we've talked about. Even simple, we add an attribute, and it takes seven years from inception to when it's actually just shipped in all browsers. And by the time it's widely available, it's close to 10 years. People have a problem today. They're not like, 'Hey, I have a problem and I need to solve this in roughly 10 years.' They have a problem, they need it solved this week. And so they can get involved with it, and maybe they think that maybe I'll get this done for my next project, but it's really tough to be involved and you have no belonging to, W3C even isn't a lever to get something done. Ultimately, it's who's going to show up and do the work and who's going to maintain it and who's going to build it and who's going to pay for it. And I don't know, that's a few practical sets of gate that seems to sit on top of that priority of constituencies idea, where it's like, one, frequently developers are judging the high level as opposed to, let me understand what is it deeply? Why does it have this shape? What are the other use cases that this enables? What security constraints went into this? What accessibility constraints went into it? There's a lot of deep thought that goes into something, and maybe it is a meandering set of observations, I guess, but how do we do better at marrying these things?
Dominique Hazaël-Massieux: I'll interpret it I guess in a couple of ways. If we're saying developers are the second-most important people in what we take into account when developing standards, yet it is near impossible for most developers to get involved on a long-term basis, which is pretty much a requirement for standardization. How do we square that circle and... Well, first, yes, we should do better in both reducing the time needed to go from idea to shipping and to wait available. We should also make it easier for developers to keep track of what's happening and where. And again, I think we've made some significant progress with precisely efforts, such as baseline or interop, which are ways of signaling when things are getting ready or are ready or ready available, and so on. Interop, making it easier for developers to also signal when something ought to be ready but isn't quite up to their quality expectation. So, the fact that we are bringing more opportunities for more feedback groups I think is, to me, a key part in ensuring that all these issues that developers have get a better hearing. You mentioned earlier the community group program, which I also manage in W3C and which basically allows anyone to start a group in the context of the W3C framework, get ideas flowing. Once the ideas start converging, turn that into a specification. And if there is enough traction behind the specifications, that actually can go to the full standardization process. And again, none of this is a silver bullet. It's not because you've done a committee group and that you produce a specification that it will shape ever. It puts you in a better position, but it's absolutely not a guarantee. But again, we are dealing here with a platform, a digital platform of a scale that we can barely comprehend. Four or five billion people using this platform to do stuff, some that we are exposed to, some that we aren't. Managing such a system necessarily requires making trade-off in how you build it, how you develop it, and how you maintain it. And I think the accessibility case is illustrating one of these particularly challenging situations around deprecation. As I said, you can run web pages that were created 30 years ago for the most part. In some cases actually, some pieces of some technologies have been deprecated either because they created security risk or they were more costly than they were worse, or they had so little usage that they were not worth keeping in those huge piece of software that web browsers are. And so figuring out the right way of handling these situations where we feel that the web would be better off with a little bit of breakage, rather than by keeping everything forever. I have no clue on accessibility whether that's going to be the decision. I don't have an opinion on whether that will be the right decision or not, but just to say that at the end of the day, the thing we develop, they have to be maintained. They have to ship. If you're dealing with six billion users platform, at some time, there are occasions where you have to make choices that won't necessarily please six billion of them or the 20 million web developers out there. Some choices are hard to make, but doesn't mean they don't need to be made.
Eric Meyer: Yeah. The CSS visited styling and how that had to be completely nerfed, as the gamers say, to not leak private information. And basically for that matter, the blink tag is no longer natively supported.
Dominique Hazaël-Massieux: Exactly.
Eric Meyer: It was for a long time. You could still do it with CSS, but please don't. But yeah, for a real long time, blink, blink, and then it got taken away. Even though there are lots and lots of pages that were using the blink tag, still took it away. The process of listening to the community is always, it's different for everyone and it's crucial and yet can be difficult because everybody in the community who speaks up speaks. But if you're the person who's receiving all of the speech, it can become a cacophony. It can just become a hugely overwhelming tidal wave. And every time I've ever been involved in a process that had community input, it's basically a given that whatever question you ask, you will get completely contradictory answers from the community, possibly also from the people who are part of the process. But Brian has basically, I call it Kardell's Law of Polls, which is if you do a poll where it is completely obvious to you which answer is correct, your results will be basically statistically 50/50. And I actually have a corollary to that, which is if you ask a poll where you're pretty sure that the responses are going to be 50/50, you'll be surprised at how unbalanced they are. In fact, the one that I did about the anchor positioning, I figured it would be close to 50/50. It was 80/20. Even though I was like, 'Yeah, there's going to be a lot of disagreement on this one,' no, there actually wasn't as much as I thought. But the people who actually were in the 20% result I thought made some very strong arguments as to why their preference was good, was a good idea in general. But then, of course, there were good arguments the other way. Anyway, we see that with interop. We get people asking for things, and sometimes what they're asking for is a thing that browser-makers have already said for whatever reason they're not going to do. It might be for security reasons, it might be for resource reasons, it might be for whatever, but they've already said, 'We oppose doing that thing,' whatever the thing is, while you have other browser vendors saying, 'Yeah, no, that would be awesome. We'd love to do that.' Or you'll get people saying... Or you'll get two proposals for interoperability that are basically contradictory. They're mutually exclusive. It's always a challenge. And then at the end of that, a choice has to be made. The choice could be we're going to do this and not this or the other way around, or the choice could be we're not going to do either of these. But a lot of times, that gets interpreted as they ask for our input and then ignored it. It's like, unfortunately, I know that it feels that way when input was solicited but then whatever was done did not conform to that input, but it's not a question of ignoring. It's a question of listening and then having... You got to make a decision. We can't do literally everything that people ask for because, like I say, sometimes they're mutually contradictory. Sometimes they seem like really good ideas, and then one of the implementers says, 'To do that, we would literally have to rewrite our rendering engine, the entire thing top to bottom.' Or they say, 'Yes, people keep asking for that, and it would open a huge privacy leak,' or whatever. I feel like I wish there were a standard for these kinds of conversations where we had all these predefined levels and statuses and responses so we could say we didn't do it because of section 7.1.3 is a rationale, like RFC 2119 or whatever it is, the must-should stuff.
Dominique Hazaël-Massieux: I agree, this is a challenge. And to me, there are several aspects to that challenge too. So, first, if it looks like a democratic process, but it isn't. Sure, 80% of people say this was the right approach, yet you'll be taking the minority approach. If the minority voice is actually the one that propose the solution that is accessible and privacy-sensitive and secure, well, it might be in the minority, but at least the way we think of the platform as needing to expose a number of important values, important stable characteristics in variants, then sometimes we'll take unpopular decision, not because we don't like people, but just because we think the value of the platform emerges also from that consistency in terms of values and variants. And also, let's be honest, for interop, one way to look at it is, would the world be better with or without interop? Interop right now is, I think, a really nice conduit to have, a very strong influence on how engineering team in significant browser vendors would be prioritizing their work. And of course, it would be maybe some of it would be better if this was a more open process where you could classify anything on that short list of priorities. But between having no structured input and having a limited structured input, I think we are probably better off with the latter. And again, that doesn't mean we can't or shouldn't improve the interop process itself, but at the end of the day, to me, this is providing this new opportunity to, again, create structured input to this complex iteration on the platform. And so interop is not, again, the silver bullet that will get magically all wishes from all developers adopted, if only because some of them are self-contradictory, but even beyond that, at the end of the day, priorities have to be made and there are a number of constraints that operate on these priorities. And I think having an opportunity where we can have a common voice across the vendors I think is really interesting.
Eric Meyer: Yeah.
Brian Kardell: I think, to take a somewhat controversial statement, the value of interop is largely not the developer input. It's largely the fact that we're getting the browser engines to coordinate and fix the same things at the same time. A lot of standards lag, and pain has to do with the fact that everybody is organizing their own things, and so you have to wait until all of the stars align. And interop is a way to make all the stars align. And that's the primary benefit of interop, in my mind. Those teams know what the task lists are. They have the task lists, and they have some kind of idea because they all have DevRels what's a bead on the needs. They have their own issue trackers. We're part of interop, and the developer input that we seek when we ask for issues is like, let's make that part of it. Let's see what people submit. And let's look at the stars and let's look at what people are saying on Mastodon and Bluesky and Twitter. Let's see. But you expect that somebody's going to ask for everything, and then people are going to share. And in their own community, they're going to get a lot of stars. For example, MathML is on there every year, and every year it gets a whole bunch of stars from all the people who are interested in MathML. It's really tough to balance all these things and to do it... That's what interop, I think, has been really, really successful at, is trying to balance all of those things as best we can. It is very imperfect still. People are like, 'Why did my thing not get picked?' And it's like the best answer is often there are eight trillion open issues and there's 12 people working them. And the way that all of the budgets and the stars align is we can't even process all of them, so it's hard to say why.
Eric Meyer: I suppose maybe we need to adopt an unofficial slogan of interop is not a genie. You can't just rub the lamp and get your wish. It's way more complicated than that. And I think that's true of any process. Any process at all, there are going to be things that people propose that don't happen for whatever reason, because these processes aren't genies. They don't just grant wishes. They are structured ways of figuring out what to do.
Brian Kardell: But how can we do better at these things, though? Is it even-
Eric Meyer: Yeah, I would be interested to hear from the W3C perspective. What could we be doing better? And I don't mean interop. I mean we as the generic DevRel/standards interested people interfacing with the rest of the world. What are ways that we could better both solicit input in a way that sets expectations and also at the end communicate gently, I guess, the results?
Dominique Hazaël-Massieux: Yeah, again, I wish I had the perfect answer to that. My approach to this all has always been to nudge towards more iteration, more feedback loops, more opportunities to make sure developers, and end user for that matter, get a chance to express their needs, their opinions. And as new platforms get available, we are trying new things out. Clearly, the fact that GitHub arrived maybe 10 or 12 years ago was a big factor in bringing more transparency, making it easier for developers to see what was happening, comment on the discussion. That was, to me, a significant shift, the fact that we have all these data that we automatically collect from what is implemented, where what is not implemented yet, how we even define the platforms through the web features project, where we try to bring a consistent picture of what is it that we provide with browsers as a technology platform. All of that is trying to bring a way for getting more structure around these interactions. And as we see new tools coming, as we see new platforms, social media, and so on, we will try new things out. Some will fail. I've tried a number of things that have failed over other years. Some of them I think end up providing exactly the right kind of incentive that we need to get people to pay attention, to feel that they can have a voice, even if that doesn't mean that everything will be always taken into account, but at least that they get a chance to at the very least influence and sometimes even shape a lot of the discussions.
Brian Kardell: We have this expression, pave the cow paths. And if we have ways to build something that's very, very close to the native thing that we want, maybe it would be super simple to just then write it down to make the W3C act more like dictionary editors who don't invent new words, don't sit around and debate new words. They study the vernacular. It's in the wild. I have advocated this in W3C for a while that I feel like there should be a way to do this better, to look at custom elements and the trends. Have we ever had any attempt to study what developers are doing so that we're looking at what they're selecting? I'm just curious, have you been involved in anything like that, or?
Dominique Hazaël-Massieux: So, I've tried a number of times to take measure of adoption, not so much in this stage of ideas being incubated, although I have seen customer elements being quoted as evidence that there is indeed a need that the platform doesn't address. But again, I don't think that we have great infrastructure at the moment to really have a very systematic approach about measuring which customer elements are used, where, for what, how often, but that could be one new infrastructure project to be worth investigating. But in general, I had developed this small tool that looked at, say, stock overflow to see whether a given new technology got a lot of questions with a lot of answers, or a lot of questions but no answers, or no question at all. And obviously stock overflow nowadays has a different weight in the developer ecosystem, but that was an interesting way of determining whether technology had awareness among developers, had understanding among developers. If there are lots of questions, very few answers, that's probably not a good sign in terms of how easy it is to adopt the technology. And so ideally, we would have more tools that would let us detect this real-world signals. One of the challenge that I think we alluded to earlier, but asking people. More often than not, people don't really know what they need. Maybe they know what they want, but whether that matches what they actually need is unclear. And even when they do in a platform that is as open as a web, what you'll hear is what people know or think they need and know that they are being asked about it. And so you'll get huge amount of bias on the type of answers you get because it's basically the people that are already aware that they have a voice at the table that will be able to bring that voice. So, inversing that by looking not at what people express, but also looking at what's out there as a signal of what's missing, what's not working correctly I believe is really important. Conversely, again, because of the scale of this platform is really challenging. I know that there are regularly really interesting efforts around the HP archive and around the Web Almanac every year that look at some of these large trends on the platform, which, again, I think ends up informing how we develop these technologies. But if someone were to come with me with a proposal to have more tooling, more infrastructure, more transparency around this infrastructure, I think that would be terrific.
Brian Kardell: Yeah, so you mentioned the HP archive and looking at some of those things. I've been obsessed with this for a long time, and I have something that Eric and I are working on, which is a write up, a study of some of this. I helped in 2018 or 2019 to actually add the instrumentation to record the element names and everything so that we can do these reports. We now have 44 months of snapshots and we have to stop counting at 10,000 unknown elements every month. And across 44 months, we have 71,151 unique custom elements. And there is an extreme bias in that data because it is only homepages and one random link that will... Not random. One link that will follow, which represents the hopefully largest visually reported same origin link. That doesn't cover intranets, it doesn't cover applications, it doesn't cover anything you have to log into. If you think about that, that's like Twitter or even this application that we're using here or Gmail, their home page and one random link are going to be like three buttons, a heading, and 12 footer links or something. They're not going to be representative of what those apps really are. It's really, really interesting how much stuff there is out there. And I'll just add that that's only about half of the elements because then there's almost as many where people are just using non-dasherized elements. They just like using blink or their own thing that they made up that doesn't have any dashes in it, isn't a custom element, it's just more or less like an XML element but served as HTML. Anyway, I think that would be really compelling to a thing that the W3C could do or that governments could fund or something. I don't know why we're not actually studying this other than the fact that it is actually really hard to study because there isn't even a data source. And a data source for it is quite expensive. It costs quite a lot of money to run the HP archive.
Dominique Hazaël-Massieux: And also, you were mentioning, so you wouldn't get anything out of the Gmail or Twitter. At some level, if you operate a really big web app, you probably already know how to get your cow paths paved. So, in a way, what would be more interesting I think is getting data out of the long tail, and so how does that correlates with what's available through this sampling mechanism of the HP archive I think is also a fair question to ask. But I guess what I mean by that is what we don't need is, or at least what we mostly don't need, is more channels for people that have already the channels to get their ideas listened to. It is important as we consider this additional infrastructure to make sure that actually enable voices we don't hear from either at all or very little. And one thing that I personally always find striking in our communities is how biased we are towards some countries and geographies and how little we hear from other countries and geographies, so if there was infrastructure to be set up, I think it would also be really interesting to make sure I understand how they enable those other communities to actually start being listened to, rather than just reinforce existing biases.
Eric Meyer: So, what are some other things we could do? What do you think of the idea of a town hall?
Brian Kardell: I do get the sense that developers feel like they're not being listened to. I wonder if there isn't something to the let's go out and listen in a concerted way. Maybe that's a thing that the WebDX group should do or W3C, or maybe just DevRel should host the open town halls where you can come and discuss with us. But I think it has to be a two-way street where it can be like you can yell at me, but you have to be prepared for the realities of the situation. That means the answer might not be super gratifying.
Dominique Hazaël-Massieux: Yeah, I think that's certainly worth experimenting with. One of the issues with anything that is synchronous is that, again, only the people that have the time to attend at the time that was selected in the timezone that was selected for the meeting will get a chance to participate. The loudest voice will be heard more than the more quiet people. But again, as a way of getting more input, building more engagement, relationship, I think it's worth trying. The WebDX groups you were alluding to is evaluating taking a more open-ended approach in gathering signals from developers on features that aren't quite baseline yet, just to also measure the temperature of the appetite. And again, we know this will be biased because some people have very strong opinions, tightly-knit communities around their opinions, and so you can't treat that as an actual thermometer, just as another signal to take into account. But overall, I think, I may be repeating myself, my sense is that for a platform of this scale, the real goal is to identify and collect as many of these signals as possible and through the magic of discussion, argumentation, and so on get as good a result as we can. And good doesn't mean that it's necessarily actually good, but hopefully better than not having it at all or having it in a different way. Again, my main life lesson on working on that platform is that you have to approach it with a lot of humility because it's so big, so complex, and there are so many constraints that your best hope is to move the needle hopefully in the right direction and by making sure that if actually you went in the wrong direction, you will know that it was the wrong direction, so you can adjust and step by step advance the platform in the hopefully best direction possible. And to do that, it's a lot of discussions, a lot of argumentation, a lot of structure around these conversations to make sure that we don't fall too much for our own bias or our own echo chamber so that at the end, what we deliver fulfill as wide a set of needs as possible and as really the web requires because... And the reason for which certainly I, but I think many in our web standard community, the reason we spend so much time and efforts on this is because we really think the web is needed as the one interoperable digital platform that human societies can work with, work on, so that we have this open space for discussion, for delivering services, for delivering ideas. And unless we put the efforts in making sure that platform remains, remains open, remains transparent, and also remains useful to the world out there, then we lose it, and we lose it to alternative proprietary platforms, which have, to me, a lot of risk for us as a society overall.
Brian Kardell: So, one of the things that I like that has happened over the years, and I don't think that it happens enough, but we have, for example, OpenUI publishes some research about the things that it's doing, and then it creates an explainer. That's a practice that the tag helped popularize because it explains what is the problem space that... You start describing the problem space, and then you talk about not only the solutions that you chose, but the alternatives that you considered and the factors that you considered. And maybe there's a history of turns in that document as well. I wonder if other people find that useful or if there should be a repository of those things that you can point people to, because sometimes the feedback that you get is like any idiot would not do that. No, but there are real reasons for that, and having those explainers I think is maybe a way to help people feel better about it. But then again, maybe not. Maybe that's just time that we're burning doing that instead of doing something else. I don't know. Do you think that it's a useful thing to spend more efforts trying to explain why things are the way they are, or?
Dominique Hazaël-Massieux: So, one of the ideas I tried to pitch a few years ago on resurfacing explainers, but not maybe with the systematicity that I wish it got, there is this design pattern, but designed for software or technology, rather than for layout or anything like that, called architectural decision records, which basically ask people that make decisions about the shape of a technology to formally record why the decision has been taken and documented very explicitly about the process. And one of the benefit of that is not just that you let other people know why things are the way they are, you let your future self know why things are the way they are. Because my experience in working groups is that some of these technologies get developed for literally over a decade. The decision you took in April 2013, you don't have it at the back of your mind when you are revisiting the problem space in 2025. And so if you are forced of documenting why you took that approach, and since then the world has changed, the platform has changed, expectations have changed, then you can much more easily reconsider it possibly or build on it, if it turned out this was actually the right decision tree than if you just have to recollect from vague memories. And so we have that through issue management and through explainers in the early life of specifications. But my hunch, one that I haven't quite managed to sell to the community yet, but my hunch is that a more systematic approach in documenting these decisions with very structured file format might actually help, again, not just outside reviewers or even implementers as they go through the specification, but also working groups themselves as they have to revisit problems they have encountered in the past.
Brian Kardell: Cool. Thanks for making time to discuss this stuff with us. I think we can agree it's not easy because we want to listen as much as we can, we want to advocate for you, we want to try to understand, but we also need to communicate in the other direction as well that we don't control the budgets. There are other constraints. It's an interesting set of challenges, and we haven't completely figured it out yet. Thanks for continuing to struggle through with us and try to do better.
Dominique Hazaël-Massieux: Yeah, thanks a lot for having me, and thanks a lot for all the work you guys have been doing also in that space, because as you say, it's a very complex, very rich one, but a very complex space to navigate and to make sure we bring the impact people expect from us.
Brian Kardell
Eric Meyer
Dominique Hazaël-Massieux