Igalia's Brian Kardell and Eric Meyer chat with Mozillan and HTML editor Simon Pieters, and fellow Igalian/engine contributor Luke Warlow about getting started in web standards.
Eric Meyer: This episode of Igalia Chats is brought to you by… Igalia! And our brand-new Servo Colelctive, a community funding drive to support development of Servo, the only web engine to be written in a memory-safe programming language with modularity, embeddability, and parallel computing in mind. Visit servo dot org to learn more, and opencollective.com/servo to lend your support.
Brian Kardell: Hi, welcome to Igalia Chats. I am Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer, also a developer advocate at Igalia.
Brian Kardell: And today, we have two guests.
Luke Warlow: Hi, I'm Luke. I'm a web platform engineer at Igalia.
Simon Pieters: Hi, I'm Simon. I'm a standards engineer at Mozilla.
Brian Kardell: Today, on the show, we're going to talk about getting started in standards. Everybody here is somehow involved in standards, and maybe we took even different paths to it. At least one of us has helped write a guide to help other people get involved, which is pretty nice. We'll talk about. So yeah, let me just ask, I think two people have worked for browsers. So Eric, you used to work for Netscape back in the day, right?
Eric Meyer: Oh, a long time ago, yeah, like 2001 to 2003.
Brian Kardell: And Simon, you worked for Mozilla now, but you worked for opera back in the day, right?
Simon Pieters: Yeah, that's correct. I started at opera in 2007. That was my first job really. And I worked there for 10 years. And then, after that, I worked five years at Bocoup, which is a consulting company, and now, I'm at Mozilla.
Brian Kardell: Yeah, you and Eric both sort of got your start in standards through writing tests, right?
Simon Pieters: Yeah, writing tests was, I think, my entry, although I started to contribute to standards, at the same time basically. I joined the WHATWG mailing list in 2005, which was two years prior working at opera, and made various proposals or pointing out bugs in the spec.
Eric Meyer: Was it the pointing out bugs in the spec that led you to start writing the tests? Or was it the test that helped you find the bugs? I'm just curious.
Simon Pieters: Probably a bit of both.
Eric Meyer: Yeah. Okay.
Simon Pieters: Yeah.
Eric Meyer: I asked, because when I started out, I started writing CSS tests because I kept... Okay, so this is a long time ago. It's when CSS was first starting to ship, and I would take things from the specification and try them in browsers, and it wouldn't always work the way I thought it would, or maybe it would work in one browser the way I thought it would and not the other. So I started writing sort of very basic tests to say, 'Is this actually working the way it's supposed to in browsers?' And that's actually how I started reporting bugs was because I, in some cases, ran into bugs, but in some cases, was running into my own lack of understanding of the standard at the time.
Brian Kardell: So Simon, do you do any implementation work?
Simon Pieters: Not really. I think I've done two patches to Gecko in my life, and they both were with a user-agent style sheets related. So it's no C++ almost.
Brian Kardell: Yeah, I think that makes Luke unique among us, because Luke does the implementation work as well. Luke, do you want to talk about how you got involved?
Luke Warlow: Yeah, so it is kind of interesting you talk about the tests, because I come from the web application development background. So the thing that got me into standards was more trying to do something in an actual application, finding edge cases that maybe didn't behave how I expected or didn't behave consistently. And then, kind of went through MDM, which is kind of the entry point into the web for most web developers, and finding either the data there is wrong or the data have notes that explained the issue. And MDM articles have really useful links out to specs. So that was kind of the next progression there was to jump to the specs. And often, I'd read the spec, and it would make perfect sense or I'd read it and go, 'Okay, I don't understand this.' And to start with, part of it was kind of learning how to read the specs and part of it was just having the belief of, 'Oh no, I think I understand this,' or, 'I think this spec is wrong here' sort of thing. And then, raising issues and browser bugs from there. So lots of what I did originally was just loading up JSFiddle and basically writing a web platform test inside of that, which then made going to the actual writing test bit quite a bit easier. But because of that, because my past is development, I guess that kind of led me down the implementation path more so than the spec path.
Brian Kardell: But Luke, did you have C++ or C experience?
Luke Warlow: No, I didn't.
Brian Kardell: How did you manage getting into that? Do you know what I mean?
Luke Warlow: Yeah, so I learned to code in Java at the same time as Visual Basic and Java, which were obviously quite different to C++, but there are similarities. The underlying the knowledge is the same across most programming languages. C++ is a bit more complicated with the memory management, but it was surprisingly easy. It's one of those things that it's quite daunting, but then, I think all three of the browsers really make it quite easy to get started to download the code and poke around with it. And then, from there, you kind of pick things up, following what's already there. So you don't necessarily actually need to have brilliant C++ knowledge beforehand. But the WebKit team and the Chromium team were brilliant, in terms of helping out, answering questions, when I have them.
Brian Kardell: So I think one of the things that I see people want to get involved with standards is because of things like bugs and incompatibilities or a feature that is in two browsers isn't in the third one or something. But also, I think there's people who think they have ideas about how to make something better and they want to know how to make that real, I guess. I don't know. Does anybody have advice for people who have those kind of thoughts? Or what are good reasons to get involved? What are good ways to get involved? Who has some comments on that?
Simon Pieters: So it's easy to have ideas like, 'I want to add a new element or a new API to do foobar,' and that's great.
Brian Kardell: You will do foobar probably.
Simon Pieters: Yeah. But then, how do you get it across the finish line? And what is required? A few years ago, when I worked at Bocoup, we created this guidebook called Web Platform Contribution Guide, which tries to answer some of these questions. So it's at wpc.guide, it's a free guidebook, and it tries to give a high level overview of how standards are being worked on and what goes into changing them. So there's a section called How to Fix a Spec Bug, which is sort of similar. The process rather is similar for, 'How do I introduce a new feature for the web platform?' So if you go from an idea, you then need to do some research to, 'Has this been discussed before? What are the use cases, what I'm actually trying to solve?' And try to convince the browser vendors or other parties that the use case is important to solve and that your idea is a good way to solve it.
Eric Meyer: And my experience certainly is that use cases are kind of king these days, at least in the CSS Working Group. You can have a great idea, but if you have no use cases, it tends to be lower on the priority list. Whereas if you have a use case of, 'Hey, this feature would be great, because we tried to do this and we couldn't do it or we had to script our way around it,' those sorts of things, those get higher priority for discussion.
Simon Pieters: Yeah, exactly.
Luke Warlow: I think another key thing with use cases as well is it helps to make sure that the API design you come up with is actually the best, because if you come up with solutions, then it might be perfect for what you're trying to do, but you might be able to do it in quite a different way, that achieves even more and there's an even better design. And we have this even at my previous role with the web application development as, oftentimes, we'd have people come up with solutions without giving us the use case. And that makes it quite hard for us to evaluate actually what it's trying to do. Whereas if they come to us and go, 'We want to do this. Here's an idea we've got as to how to go about doing it,' then we can have a discussion about what's the best way of doing it. And I think the same applies in web standards.
Simon Pieters: Yeah, it does. And in fact, if you file an issue and only present a solution without explaining what the problem is, then the first pushback you will get is, 'What's the use case? What are you trying to do?' And if you're not able to explain that, then it's like the issue will be closed probably.
Eric Meyer: Yeah, most likely. Yeah. There's definitely an attitude there of, 'We need to know why. You can tell us what you want to do and how you want to do it, but we really need to understand why you want to do it.' And I think that's good design practice for any standard, right? Because you can make up whatever, but if you haven't been able to think through, as a group, why a thing needs to be done, then you're much more likely to create something that's too limited or just not future robust.
Brian Kardell: I think this is true in all software development, that you need good use cases and the more you can kind of zoom out and look at it, are you coming up with too general, too specific a solution, that frequently is only something that you know with a lot of eyeballs and probably even some experience. And that is a problem, because on the web platform, you don't really get that opportunity. We have to get it pretty good out of the gate, because we can probably improve it a little bit. But once it's in, we can't then say, 'Oh, well, that was a mistake. Let's try again.'
Eric Meyer: 'Let's take it out.' You can't do that.
Brian Kardell: Yeah. It's not that we totally can't. Occasionally, we have done things like that, with App Cash or something, but yeah, it's much harder. And also, it's difficult to get people through the process, because one thing that we haven't talked about really is that there are too many, we talk about it on the show all the time, there are too many asks of this platform that powers almost everything in the modern world at this point and just not enough resources to do it all. And so, we can't afford a lot of misses, because then, we lose the momentum toward getting it actually done in the first place. There are some maybe other examples of that too, like the document outline.
Simon Pieters: Yeah, so a bit of context, I guess, if we go enough back in history, the XHTML 2 spec back in the day had an H element for a heading and a section element for a sections. So that was a really nice way to nest sections within sections and be able to compose your document into another document and not have to worry about the numbers in your heading tags.
Brian Kardell: Proposed by Tim Berners-Lee in 1991.
Simon Pieters: Yeah, it even goes before XHTML 2, but it didn't become a reality in that way. And when HTML5 became the thing that had momentum, Hixie made a proposal to use the h1 element as the H element basically and introduced section and other sectioning elements. So the idea was then that you would use h1 elements and have the heading level be computed based on what came earlier in the document.
Brian Kardell: And the reason for that though is because why, Simon? Why not just put an H element?
Simon Pieters: Because it would mean nothing in older browsers, so it's had a worse backwards compatibility behavior. A new element is an unknown element for existing browsers. So the thought was that, 'Okay, if, within h1, users still perceive that it's a heading, it just has the wrong heading level,' and that was more acceptable than not being able to navigate by headings at all.
Brian Kardell: Yeah, it kind of makes sense, especially given that, if you look at it, most of the web doesn't have good headings already. We just know that they are headings and there's some kind of relative importance weight to them. So the big difference with the backward compatibility story is at least it's a heading, and you can get a list of all the headings and things.
Simon Pieters: Right. But yeah, the outline algorithm, as it was referred to, was, I think, too complicated and wasn't implemented in browsers, even though it was in the spec for, I don't know, over a decade. And a few years ago, I think Firefox tried to implement it, but then, the experience for AT or assistive technology users would regress with it, as heading elements are actually used on the web with the outline algorithm.
Brian Kardell: I guess that we should say that there's two pieces to this. So one is, what does this mean? What is the semantic meaning of this? But the other is, what does it look like, right? And the proposal allowed that, basically, the size, we all know, if you put an h1 in a markdown document or whatever, just simple bare HTML document, you put in h1, it's this ginormous times square letters. The algorithm implemented, that it would manage the size of those h1s for you. And that part was implemented by browsers, but only that part.
Simon Pieters: Yes. Yeah. So that's just a style rule in the user-agent style sheet, so that was easy to implement. However, it doesn't affect what is exposed to screen reader users. So in a screen reader user navigates to a heading, the screen reader will announce, 'Oh, this is a level one heading,' or, 'This is a level five heading.' And that computation, based on the outline algorithm, was never implemented.
Brian Kardell: It's kind of worse, right? It's worse, because it looks like it worked.
Simon Pieters: Yeah, visually, it had an effect, but the more important aspect was exposing it to assistive technology correctly. When that didn't work, that's been a bad situation.
Brian Kardell: It feels like you could just sort of track the level through the CSS, that makes that work, and it should not be that hard to compute. But I don't know. But yeah, that's been really difficult. And I think, even recently, you've been trying to get the style sheet part removed, because we finally, it took many years to just admit that the document outline isn't a thing and take it out of the HTML specification. And now, you're trying to get it out of the UA sheets, right?
Simon Pieters: Yeah. So I managed to remove the h1 styling in H group. So there was style rules that would make, or maybe it was h2 and others, but there were H group styles that weren't implemented in browsers, so that was just easy to rip out of the spec, but the specs still has h1 in section default styles. So the problem or the confusing behavior still exists, even though we admitted defeat on the outline algorithm. And the challenge is, how do we remove the default user-agent styles without breaking websites? Any change to the user-agent style sheets has a web compat risk to it. And so, I asked some Chromium developers to implement a use counter a couple of years ago to figure out, how common is it for sites to depend on the default styles for such headings? Obviously, if you have author level CSS, that overrides the font size, then there's no problem. But some sites can leave the default styles as is and then have other styles surrounding it. So what I did recently was to write a patch for Firefox to remove the user-agent styles behind the pref. So it's on by default in nightly, but not on release. So we do that as an experiment to see how many bug reports do we get. We know it potentially affects a lot of websites, based on the use counter in Chromium. Actually, before I did the patch, I did a manual analysis of I think it was 30 websites to see, what is the actual visual change with the removed default style sheets? And mostly, for those sites, there was either no visual change or just minor changes or just acceptable, in my opinion, changes.
Brian Kardell: But you can see, we're way down in the rabbit hole on this, and that is what standards are, right? You should be prepared to go way, way down a lot of rabbit holes if you want to get involved with web standards, probably. I'll just mention to that particular one that we were just talking about, on the very last episode, we were asked, 'If you could sort of go back in time and change one thing, what would it be?' And my answer was, in 1991, I would have made section and hit NH work, because just thousands and thousands and thousands of hours of people's time, that could be spent doing something other than this, other than going down these rabbit holes for years and years and years. Simon, I would like to also mention really quickly that, since we're talking about things that get burnt into the platform and then, we can't really undo, there's no takebacks, the HTML parser. Simon is the author of a book about the HTML parser. Is really interesting.
Simon Pieters: So it's a book that I started to write in I think it was 2018. And then, I haven't finished writing it, but I still intend to do so. The book is called Idiosyncrasies of the HTML Parser. It's freely available as a web book at HTMLparser.info. You can also buy an ebook if you prefer that. And yeah, I go over the history of what preceded the specified HTML parser, how did browsers work before then, and Ian Hickson's work with figuring out what the behavior should be and specifying that, and going over all of the different aspects of the HTML parser and what the result is for different kinds of inputs.
Brian Kardell: Yeah. And a lot of the rationale at the end of the day is practical, because it's like, 'Well, two of three browsers or four of five browsers did this, and so, the web relies on that now and we can't change it, even if we think it's not a great idea.'
Simon Pieters: Yeah, absolutely.
Eric Meyer: Yeah. So you said you've had a couple of patches merge to the user styles, which is very cool. I'm feeling a little envious. I don't think I've ever had a patch merged to browser user style sheets. Maybe that's a thing I should start looking into. But what I'm curious about, and Luke, I know that you've contributed many patches to browsers, what is that like, if someone were interested in actually helping optimize something in a browser or submitting code patches? How does one get started? And what should one expect?
Luke Warlow: Yeah, so as someone who's done that, started on that relatively recently, it was only about a year ago, I would say, that I properly started contributing to browsers, I was surprised at how it was actually quite simple. And I think part of that is that things have got much simpler over time. WebKit, for example, nowadays, it is just a pull request on GitHub, and you can get your change merged. Whereas I think, back in the day, it was a bit in patches manually through their bug interface. The first thing, I guess, is just kind of working out what it is you want to work on. If it's something small, then great. If it's something larger, trying to think on how you can split that up. So as an example, I found that the spec for inverted colors and the implementation inside of WebKit, the UA style sheet didn't match, which I found was quite odd, because WebKit was the only one who actually implements that media query. And I think what's happened is that WebKit's implemented this a while back, it's been added to the spec, and then, the spec's been updated years later and it's just not fed back in. So that's a relatively easy change. You're finding the bit in the WebKit code base, so the problem is make the change. And it's fairly self-explanatory for reviewers. You just point them to the bit in the spec and go, 'Look, here's what the spec says, here's what your code says, here's the difference.' And then, oftentimes, you'll be told how to go about testing it. Some things are easy to test. A lot of the time, if you are implementing something that's already implemented in other browsers, there's already quite good test coverage for you. Other times, you have to write it yourself. I think web platform tests especially are very well documented. There's quite a good website that explains how to go about doing certain things. And then, I think the other part is the web platform is massive. It's unlikely that what you are doing is so new that there's not an example of it already done. So that's another great example. If you want to look at how to, for example, the scrollbar styling, I was like, 'Oh, I wonder how to parse the CSS for this.' And then, well, you just go and have a look at the CSS parser in WebKit and you'll probably find something that's the same or very similar. And you can kind of copy that, especially because you just play around with these things locally. You can't just git clone the repository. WebKit and Firefox build relatively quickly, at least on macOS. Chrome is a bit slower.
Eric Meyer: How fast or slow are we talking about here?
Luke Warlow: So Chrome is in the region of ours. WebKit is, I had a Mac mini, which is still quite a high end machine, but that did it in about 40 minutes for the clean build. And then, for the subsequent build, it's much faster. And then, Firefox weirdly is quite a bit faster than even that.
Eric Meyer: But still, to build an engine, you're looking at it probably half an hour or so just to do a build, unless it's Chrome, in which case you run it overnight. That seems like a challenge. I'm so used to the kinds of updates that I do are on webpages and I save it and I tab and I reload and the change is there and either I broke it or I didn't. So that is a big difference.
Brian Kardell: You can build Chromium to help supplement your heating.
Luke Warlow: It very much is kind of like that. On my old machine, it was I run a building overnight, wake up in the morning, and hope that Chrome is launched and I don't get a little sad red error box that says, 'You've made a typo here.'
Brian Kardell: I wanted to really quickly mention that I do these blog posts a couple of times a year maybe, that look at our Igalia's commits to a lot of significant open source projects. And I published my last one, it was called Mid-season Power Rankings for 2023. It was in maybe July or August last year. And I just wanted to say that I remember distinctly that Luke, all by himself, was showing up in there in the top 10 or 15 contributors to both Chromium and WebKit. And I was like, 'Wow, that's a lot of commits.' So good work. I guess you got into it.
Luke Warlow: Yeah, I spotted that, at the time, I thought, 'There must be a mistake here,' because I guess it didn't make sense. Because I've done a fair amount, but I wouldn't say I've done loads.
Brian Kardell: In fairness, generally speaking, I think it falls off fast. So you have, let's say, Apple, for example, they contribute 75, 80% of all of the work for WebKit is done by Apple, something like that. And then, Igalia is number two, and we do 15%. And then, maybe the next percent is 5% and the next percent is 2%. And when you get to individual committers, there's not that many companies that are involved in we're counting groups. And when you get to individual committers, I don't think it does take that much to show up in that list, but it does take a pretty significant. I imagine that was a considerable amount of your time and effort that you were doing there to show up. So still nice work.
Luke Warlow: Yeah, it really was just finding things that I wanted to fix. So I spent quite a bit of time last summer looking at the media queries, specifically the user preference ones, and this is something I'll come onto in a bit. But I've always found stuff like dark mode really nice, but I've always found that they're harder to utilize than they kind of could be. And as part of that, I realized that Linux, for example, has a high contrast setting, and Chrome just wasn't reflecting that in the preference media queries. Even though all of the wiring was there, it was just not piped through for whatever reason. So that was one of the fixes. And then, there was a fix for, there isn't a contrast setting on Android, but there is a high contrast text setting. So we ended up using that and wiring that through, just doing these minor, well, to me, minor fixes. But I'm sure to the people who rely on those kind of preferences, it's probably quite nice changes. And that's actually some of the changes I've done to Firefox has been doing similar things, because the Android platform for both Chrome and Firefox is quite a lot of Java, rather than C++, which makes sense, because Android development is Java. And that's how I learned to code. So I'm quite comfortable in Java. So one of the other things, in terms of the getting into standard side, that I've worked on, the first, or I guess the second standard that I've come up with, proposal wise, is the web preferences API. And that's currently in the Web Platform Incubator Group, I think it's called.
Eric Meyer: This actually brings up something that's kind of important, which is there are a lot of organizations, there are a lot of standards bodies, a lot of committees, a lot of interest groups, a lot of community groups, that sort of thing. Any of us really, what would we recommend to somebody who's thinking of getting started and then, looks at the landscape and says, 'Wait, where do I even go? How do I figure out who I should talk to about this?'
Luke Warlow: Yeah, I would say, as a newcomer, that's probably one of the most daunting parts, especially because from an outside perspective, at least in my case, there's this idea that the W3C is kind of pay to play. And I know that's not necessarily true, but there's that perception. But then, obviously, all of the community groups are W3C, but anyone can come along and join them. So it's hard from that front, but I guess it's just a thing. I've always been interested in styling of formulae. Again, I've worked on web applications for five years. It's something we've all built a multi-select input and tried to make it decent. And then, I heard, 'oh, they're trying to do that, actually fix it at the web platform level.' And I think this is probably a presentation that Greg Whitworth made, who, at the time, was a Microsoft Edge, and I think this was probably all the way back when they were picking up Chromium as their engine. And so, they were putting a lot of work into that. And then, that kind of got me interested in following along what OpenUI were doing. So that's something I spent quite a bit of my time doing was the OpenUI Community Group. But then, yeah, so if you want to contribute to HTML, then it's what WHATWG, which don't have the membership requirements in the same way that the W3C do. So it's certainly an interesting landscape. I think the key takeaway is it's not as hard to get involved as it might seem. Open an issue somewhere with your idea, and if it's the wrong place, they'll tell you where to go.
Eric Meyer: Usually politely.
Luke Warlow: Yeah.
Brian Kardell: Yeah, they'll try to be helpful, because tell you where to go could be understood two different ways.
Eric Meyer: Yeah, yeah, generally speaking. Of course, everything depends on how you come in. There are always the stories of someone who comes in and basically opens an issue that says, 'You're all wrong and you're all stupid and this is how you should do it.' And that doesn't usually get anywhere. And maybe, even at that, I think people still try to be helpful in the sense of, 'Well, really, you want to be over here.' Although I guess, if someone's abrasive enough, they don't do that, because they don't want to subject another group to the same thing they just got subjected to. But if you come in and say, 'Hey, this is a thing that I've identified that would be good, and here's why,' and you appear to be trying to make the case and do it right, you might get a, 'I see what you're saying, but you actually want to be in the CSS Working Group or at the WICG.' So Simon, what are your thoughts about all of this sort of thing?
Simon Pieters: Yeah, so I think it's, even for someone who has been doing this for a long time, knowing where to go to file an issue is not always obvious. And there are several standards organizations. We've mentioned W3C, WHATWG, there's also IETF for some network stuff, like TCP, HTP, and then, Kronos for WebGL. I'm probably forgetting some that are relevant for web standards. And then, within each org, they have a different patent policy or membership agreement or what you want to call it, and different kinds of groups. I think W3C has probably the most different kinds of groups and different group or a number of groups overall. But I think, as a newcomer, if you want to figure out where to go with your idea, my advice would be to find a nearby or adjacent existing feature and look it up on MDM, and that will point you to the right spec for that thing. And then, that spec has at the top, maybe it has a status of this document or so where it says which group is maintaining that spec or where to file issues. So that's my general approach to figuring out how to or where to file issues. Find a similar thing, and then, see which spec covers the thing that I want or something similar to what I want.
Brian Kardell: And frequently, it's not even just one in the end, right? Frequently, you have to touch multiple things, because there's a little bit over here in CSS in this spec and there's a little bit over here in HTML and maybe there's...
Simon Pieters: Yeah, that makes it even more interesting to contribute also, because you get cross dependencies. And things don't build, because your patch will depend on your other patch and the terms don't exist. So that's also interesting, if you need to update the fetch spec and the HTML spec and some other spec.
Brian Kardell: Yeah, I think there are also lots of degrees in which people get involved. There are people who ultimately end up doing some of this for a living, dedicating all of their time to it. And then, there are people who are invited experts, for example, in W3C, who maybe they're not doing spec work or implementation work, but they're dedicating their life to this field maybe, and they come to meetings for those purposes. So it's maybe a chunk of their actual time. And then, there's people who get involved in, they want to be involved in discussion, they want to make suggestions, they want to critique suggestions. I don't know. There's all different kinds of ways and reasons that you can be involved. Another one that we didn't talk about, I think, that is useful is, to circle us back all the way to where we began, is testing. There's the web-platform-tests project, which I think is one of the more important things that we have. And it is a little bit intimidating, I'm not going to lie, if you've never contributed to it, but it's not hard to get it running, to check it out, and to start writing some tests. And I think developers write tests and share them all the time. They're just not web platform tests.
Eric Meyer: Yeah, a lot of them show up in CodePen and JSFiddle and that sort of thing, where somebody just puts up a, 'Hey, I'm trying to do this thing, and here's what I discovered.'
Brian Kardell: Microsoft made an interface for that. I think François REMY, who's on CSS Working Group and worked at Microsoft, while he was there, he made a thing where he could do that through a website. I don't know if that's still running, but it was pretty neat. We should have something like that. Somebody should fund it, if it's not already there, because I do think that web developers can contribute in that way. It's a low friction. You don't have to boil the whole ocean. You don't have to commit gobs and gobs and gobs of time to say, 'Gee, this doesn't work this way. Shouldn't it work this way according to the spec? And if so, then I would like to contribute that as a test.'
Luke Warlow: Well, I think that circles back to what I said in the beginning, which is, when I got started, it was writing JSFiddle minimal reproductions and making browser bug reports with them, because that's the language I knew. It was JavaScript and it was HTML and it was CSS, and that is just what web platform tests are. There's some helper functions, but at the end of the day, it is just HTML, JavaScript, and CSS. So it's a good way to get started, but to even bring it back a higher level than that, just raising browser bugs is a big start. I know lots of people, they're quite busy in their day job. They don't necessarily have time to make minimal reproductions, but just doing that is a brilliant start. And that's also how quite a lot of spec discussion earlier on, that I've started out on, actually ended up happening is I went and raised some browser bugs, and maybe it didn't behave the same across all three browsers. I couldn't work out which one was correct, so I'd just go and create a bug in all three and go, 'Here's each other's bugs, go and work out who's correct,' sort of thing. And normally, if it's an interop bug, it will end up going back to the standards body. And then, that's recently actually there to the change in the spec and the implementation. Because that's another thing, if you don't know where to go necessarily, they'll know which standards body to go to, and then, you can kind of follow the discussion along there, which is exactly what I did with the outline color one. And then, changes do end up happening.
Brian Kardell: That's a really simple sounding thing, but to be honest, do you think that most developers know where to report books? Simon, I think this is in the wpc.guide, right?
Simon Pieters: Yes. It's covered in the guide for How to Fix W3C or WHATWG bug. The last step is report bugs for browser engines, and that has links for Gecko and WebKit and Chromium and some high level advice.
Brian Kardell: Awesome. So definitely check out WPC Guide, because it will have lots of handy dandy pointers to things if you have questions after the show.
Luke Warlow: Yeah, it's interesting. I never knew this existed, and having read through it, there's lots of things on here that are very useful.
Brian Kardell: And the interesting thing that you can do, for example, to get involved is one of the ways that I know Luke from, as he mentioned, is OpenUI. OpenUI is trying to do a lot of things. And if you have the time, you can go to meetings. You don't have to go to all the meetings, but they're Thursdays. Look up OpenUI on X or on Mastodon, and you can go to meetings and see what they're like. And they're very open to the developers showing up, but there will be implementers there. There will be people from multiple engines, and you can kind of get a taste for that. You don't have to actively comment or you can, if you want to. And you'll see what being in one of those is like. I think that's a nice sort of introduction, if you want to check that out. Good things are happening there. I think it's a really good way to see what it's like, if you haven't. So that's my suggestion. And GitHub, I think, is great. So you can go to github.com/WHATWG, W3C, and just poke around and explore and see what's interesting to you.
Luke Warlow: For me, I think the great thing with community groups is, if there's a topic you're interested in, there will be a community group for it. And if there isn't, you can set one up. They are very approachable to anyone to join. To OpenUI, for example, we actively want web developers to come along to, because they're the ones providing us information on what exactly we need to be focusing on. Because like you say, there's so many things we want to work on and not necessarily that much time to be able to focus on them. And we might think that things are important. And they probably are, but maybe they're not as important as certain other things that the developers might want.
Simon Pieters: I will add also that, if listeners think that attending meetings feels too intimidating, there are also chat rooms, where a lot of discussion happens. Different standards groups have a room on Matrix or IRC that you can join, anyone can join, and ask questions or just lurk. That's also a way to participate in text.
Brian Kardell: And following GitHub, RePOSE is a similar way that you can do that. That sort of seems to have replaced the mailing list route that I think Eric and Simon and I probably all took, where you would follow a mailing list and lurk for a long time before you got involved maybe.
Eric Meyer: Yeah.
Simon Pieters: Yeah. It's interesting how we collectively all used mailing lists for all of the technical discussion and then, at some point, moved to GitHub Issues. Or I guess there was a Bugzilla step in between also. We used W3C Bugzilla for a while.
Brian Kardell: Yeah. What were you saying, Luke?
Luke Warlow: I think a big part of that's the discoverability. GitHub Issues, they're indexable, like Google will surface them. One example, OpenUI wasn't actually the first community group I joined. There was the web extensions one that I joined, because I, for a while, have done, plus my implementation work on the web applications was credential related, implementing stuff like passkeys. And I just kept hitting the same thought that we should be handling these better in the browser. It's brilliant. The browsers have built in password managers, but realistically, no one uses them. We all use third party ones, and they just don't have the integration with the browsers that they should do, in my opinion. So I had that as a thought, and I went along to the web extension community group. But now, if you go and search for something like Credential Manager, Web Extension API, the issue will probably show up. So it's a good way to find, if you're interested in ideas, being able to just search GitHub for previous discussions.
Brian Kardell: The mailing lists that we were talking about were public and the rooms are public as well, and they both Matrix and IRC can be, they can have long logs, like permanent logs. So you don't discover them too much anymore via search. But they would show up in search, you would find it if you went and looked at some of these really old topics, where all the discussion was on mailing lists instead of GitHub, you would still find them. I think the bigger problem there, how long will those actually live? So some of them have disappeared, because it's maintained by whatever, even some college that was maintaining them that, well, the college doesn't exist anymore. That happens, believe it or not. So a bunch of the early things from the web have been mirrored in other places, archived somewhere, but, but it all was indexed and it all is searchable, in theory, as long as those things remain. But some of them are a little bit hard to find these days, and W3C actually has a pretty nice mechanism for searching the mailing list and stuff. So is there anything that you want to say in closing that you think we should have covered that maybe we didn't?
Simon Pieters: I can add that, knowing that discussion happened on IRC or mailing lists or W3C Bugzilla, it's useful for spec archeology, as I call it, finding all of the prior discussion for a particular issue.
Brian Kardell: Definitely.
Simon Pieters: If you only look at GitHub for finding all of the prior discussions, you will miss the era that came before GitHub. So if you want to find all of the prior discussions, you need to look at the mailing lists and the other places as well.
Brian Kardell: A thing that I found that is interesting and also maybe frustrating is that, sometimes, that archeology that you do, you can find, 'Well, we abandoned this idea,' or, 'We changed this, we did something a different way because of this rationale.' And if you wait long enough, somebody might change their mind about whether that rationale is good or bad and then, change all of the outcomes and discussions that come after, that were based on that. So almost nothing is written in stone forever as an infallible principle that we can't change.
Simon Pieters: Yeah, absolutely.
Luke Warlow: I think a good thing with that, again, is, if you come with your use cases, even if someone's previously proposed exactly what you're proposing, it doesn't mean it's just going to get thrown out. Because as you say, the rationale and the reasoning does change. It may been previously, performance wise, we couldn't do it, but nowadays, you've got container queries. And now, that means that suddenly all these things are actually capable.
Brian Kardell: I guess there's one last thing that I would like to add if we can, which is, what should people expect? I know that some people are like, 'Well, if I could just get in the room, if I could just just show people this proposal, this would happen,' and maybe even an expectation about how quickly it can happen or anything.
Simon Pieters: Yeah, I would say, first, there's probably relatively low likelihood that whatever solution you had in mind, it's going to end up in browsers in the short term. As we said earlier, there are a lot of ideas, and it's so many people working on the web platform and on specs. So not everything gets properly considered, unfortunately. And then, the timeline, it takes time to first to get consensus between all of the browser vendors on how exactly something should work. And then, when it gets prioritized for implementation, the timeline can be years in some cases. Obviously, if you step up to work on the implementation yourself, you can speed it up.
Brian Kardell: I think even implementers bring proposals. Google especially, they throw a lot of stuff at the wall, and a whole bunch of it doesn't stick, right?
Simon Pieters: Yeah.
Brian Kardell: So it's not like anybody, even companies with people who have a lot of expertise in this area, a lot of credibility, the promise of, 'We will implement this,' or maybe we even have implemented it as a prototype or something, can make something happen really quickly or even at all. And so, you have to follow the same rules and probably you don't have those other advantages as well. So keep your expectations realistic, understand those things, and be patient, be kind, and yeah.
Luke Warlow: That's not to say to expect failure, though. I think that's one thing to make clear is don't expect guaranteed success, but things do happen.
Brian Kardell: Absolutely. Yeah.
Luke Warlow: It can look like things are moving slowly, and then, suddenly, everything happens overnight. Yeah.
Brian Kardell: Definitely. Eric, anything from you as a last parting?
Eric Meyer: Listen to these people. They know of what they speak.
Brian Kardell: Okay. Thanks for coming on as guests, guys. It was a fun talk.
Brian Kardell
Eric Meyer
Luke Warlow
Simon Pieters